- Samsung Galaxy S23 Ultra - non plus ultra
- Milyen okostelefont vegyek?
- Xiaomi 15T Pro - a téma nincs lezárva
- Apple iPhone 17 Pro Max – fennsík
- Motorola Edge 50 Pro - több Moto-erő kéne bele
- Fotók, videók mobillal
- Bemutatkozott a Poco X7 és X7 Pro
- One mobilszolgáltatások
- Samsung Galaxy Z Fold6 - ugyanaz, sarkosan fogalmazva
- Poco F7 – bajnokesélyes
Hirdetés
(használd a CYBSEC25PH kuponkódot további 20 ezer ft kedvezményért!)
-
Mobilarena
Mikrotik routerekkel foglalkozó téma. Mikrotik router típusok, hardverek, router beállítások, programozás (scriptek írása), frissítés, és minden Mikrotik routerrel kapcsolatos beszélgetés helye.
Új hozzászólás Aktív témák
-
bacus
őstag
válasz
Zwodkassy
#4069
üzenetére
A regexp-re van sok jó leírás, sőt találsz rá appot ami wizard szerüen össze rakja neked. például
A layer7 lényege, hogy az egész csomagot megvizsgálja, és mintákat keres, azaz nem csak a fejlécet nézi, hogy ki a címzett, vagy melyik porton jött, vagy milyen típus, hanem fogja és a teljes csomagot összerakja és abban keresel, mint mondjuk a saját számítógépen egy fájlt a totál commanderrel (ott is van regexp), és persze jobb szövegszerkesztők is ismerik*. Ez rettenetesen erőforrás igényes feladat, nem véletlen próbálnak minél alacsonyabb szinten forgalom irányítani, mert kevesebb számítási igény, kevesebb idő, több csomag..., amivel normál esetben dolgozunk itt, az a layer2 illetve layer3, vagy a kettő között elhelyezkedő pl. bgp protokoll (ha internet szolgáltatónál dolgozol/tál biztos használtál már ilyet is)
*a regexp egy intelligens módja egyébként a keresésnek, pl keresem azokat a részeket, ahol megtalálható "win", ezt a buta keresők is tudják, de regexpben megmondhatod, hogy csak azok érdekelnek, ahol a következő betü nem "d" és "t" igy pl kiejted a windows és winter szavakat, stb., és a következő betű sem lehet numerikus kiejtve a win7, win8 szavakat.
Érdemes foglalkozni a regexp-el, nagyon hasznos tud lenni.
A layer7 persze csak akkor működhet, ha nem titkosított a csomag.Nyugodtan pontosítsatok, nem sértődöm meg, ha tanulhatok belőle.
-
cszolee79
tag
válasz
Zwodkassy
#4061
üzenetére
Itt egy példa, valamikor régen nagyon púposkodott ez a szar aztán beállítottam rá szűrést, elvileg ez semmit sem enged amiben a "bslrpg" szöveg szerepel.
Lehet finomhangolni meg szépíteni persze./ip firewall layer7-protocol
add name=bslrpg.com regexp="'bslrpg.com'"/ip firewall mangle
add action=mark-packet chain=prerouting comment="L7 Torrent Packet" disabled=\
yes layer7-protocol=*3 new-packet-mark=p2pl7 passthrough=yes
add action=mark-connection chain=prerouting comment="L7 Torrent Connection" \
disabled=yes layer7-protocol=*3 new-connection-mark=p2pl7 passthrough=yes/ip firewall filter
add action=drop chain=input comment="Drop Layer7 marked packet" packet-mark=p2pl7
add action=drop chain=input comment="Drop Layer7 marked connection" connection-mark=p2pl7 -
#3901
Core2duo6600
veterán
Zwodkassy
#3887
-
válasz
Zwodkassy
#3881
üzenetére
Például :
add action=masquerade chain=srcnat comment="Digi Net" out-interface=Digi-Gtw src-address=192.168.0.11-192.168.0.22 to-addresses=0.0.0.0
add action=masquerade chain=srcnat comment="Telekom Net" out-interface=Tele-Gtw src-address=192.168.0.33-192.168.0.44 to-addresses=0.0.0.0
-
csusza`
senior tag
válasz
Zwodkassy
#3880
üzenetére
Köszi szépen.
Ezek alapján eddig én capsman forwardoltam... Bár, a cap-ok hardveréből kiindulva ez nem olyan nagy gond...
Ehhez nem kell bridge-t felhúzni az AP-kon ugye? Egyébként ennek van valami előnye - mármint a bridge-nek, ha csak egy ether interfész van?Egyébként az úgy helyes config, ha két wifit szóratok az AP-kel (master & slave config), az egyik datapath a hotspot bridge-re mutat, a másik pedig egy office bridge-re? Két külön tartomány. Pont a bridge miatt kérdezem.
-
-
bakonyip95
tag
válasz
Zwodkassy
#3538
üzenetére
1, Csatorna belövés még nem történt meg, csak beüzemeltem, de a 7-es csatornára állt rá automatán, ami úgy nézem, hogy a legtisztább, szóval ezzel elvieleg nincs gond.
2, RoutesOs: 6.35.4, Capsmann: wireless-cm2.
3, Local forwarding és Clint to Client Formwarding van most bekapcsolva, eddig ki volt kapcsolva a Client to Client, de semmi változás.
Valamikor 1-2 magára is leesik, ami már tényleg használhatatlan és nem értem miért lehet ez.. :S
-
bakonyip95
tag
válasz
Zwodkassy
#3492
üzenetére
Pontosan erre a két típusra még nem volt válasz és mivel ez van számunkra a megfizethető kategóriába, emiatt tettem fel a kérdést.
A héten be is szerzem az eszközöket és megkezdem a konfigurálgatásukat, végleges beüzemelés csak a nyár elején várható, de remélem minden rendben lesz!
Köszönöm a válaszokat és segítésget!
-
#3427
E.Kaufmann
veterán
Zwodkassy
#3426
válasz
Zwodkassy
#3426
üzenetére
Windowsupdate esetén lehet jobban járnál egy WSUS-al vagy egy inteligensebb proxy-val. Esetleg olyan QoS szabályt létrehozni, ami a nagyobb letöltéseknél lassítja az adott kapcsolatot Connection Bytes rész
Én azt csináltam, hogy külön vettem a webes forgalmat, azt egy külön proxy/tűzfal disztribúció kezeli (virtuális gépen), ami a netről tud frissíteni kategóriák szerint rendezett címadatbázist és a reklám kategóriát alapból blokkolom, de tud még különféle frissítéseket begyűjteni és továbbítani a kliensek felé helyi gyorsítótárból.Ha nincs sok kliens és nem akarsz sokat pöcsölni, nézz utánna jobban a QoS-nek és ahelyett, hogy a webes forgalmat szednéd szét oldalak szerint, inkább adnál nagyobb prioritást pl a DNS szolgáltatásnak, valamint az ACK-kat priorizálod, valamint még esetleg az elsőnek említett connection-bytes házatáján nézelődsz, hogy a nagy letöltések ne lassítsanak sokat és az oldalak hamar elkezdjenek betöltődni még nagyobb terhelésnél is.
Valamint Windows 10 esetén a csoportházirendben vissza lehet fogni a Delivery Optimalization-t (Kézbesítés optimalizációt), hogy csak a helyi gépek között osztozzanak meg a letöltésen, valamint korlátozzák a le (és esetleg fel)töltések sebességét.
-
#3402
E.Kaufmann
veterán
Zwodkassy
#3401
válasz
Zwodkassy
#3401
üzenetére
Azért pl a 2011-esnél a gigabites portoknál nem is az a gond, hogy terheli a procit, hanem, hogy a switch chip 1 darab gigabites kapcsolaton van a CPU-val. Tehát míg a switch chip-en belül jóval gyorsabban kapcsolódnak össze a portok egy magas sebességű háttérbuszon, addig ha a RouterOS bridgel, minden forgalomnak át kell mennie a cpu-switch közötti 1 gigabites kapcsolaton, ami szűk keresztmetszet, pláne ha éppen több szerver és több kliens kommunikálna egymással.
-
#3389
E.Kaufmann
veterán
Zwodkassy
#3388
válasz
Zwodkassy
#3388
üzenetére
Mobilnet (4G) mindkét oldalon és VPN.
Amúgy az a 300m nem tűnik még rossz rálátás mellett sem olyan eszeveszett soknak. 450MHz környékén lévő adókat nézegettem régebben, de max soros porti adatátvitelt tudtak. 2.4GHz-n lehetne irányított (esetleg szektor) antennával és esetleg kisebb (5MHz, régebben támogatta pár RB, most passz) csatornával. Legalább is ha jól értelmeztem, kisebb sávszéllel jobb az energiaeloszlás, mert ugyan ugyanaz a max teljesítmény, ami hivatalosan használható, de kisebb spektrumon oszlik el. Már ha tényleg jól értelmeztem annak idején az erről szóló fórumokat. -
#3386
E.Kaufmann
veterán
Zwodkassy
#3385
-
-
-
#3337
E.Kaufmann
veterán
Zwodkassy
#3336
-
bacus
őstag
válasz
Zwodkassy
#3123
üzenetére
Olyat írtam volna, hogy nem tetszik? Egyszerűen nem értem, hogy működik.
Először is klónozni kell a dmz porta rakott MAC addresst, majd beírni a vigorba, reboot után a vigor wan ip megjelenik a dmz hoston..
El se tudom képzelni, hogy hogy csinálja a vigor. De most komolyan, valamit kitaláltak a fiuk, remélem Bambano megfejti..
, mert nekem nem megy. -
#3124
E.Kaufmann
veterán
Zwodkassy
#3123
-
poli27
veterán
válasz
Zwodkassy
#3012
üzenetére
nincs dhcpv6 szerver, anélkül megy az ipv6. amúgy ez a 6.38.1 et nagyon megbántam, ez egy búghalmaz, azóta nem megy a dhcp se rendesen, folyamatosan ez a dhcp offer üzenet van, és nem tudnak az eszközök ipcímet kérni... meg ez is érdekes :
Komolyan azóta csak xopok mióta frissítettem a boardokat... lehet kéne egy teljes reset és újra beállítani? nah ennek nem akarok nekiállni...
-
-
mgy
senior tag
válasz
Zwodkassy
#2997
üzenetére
Azt hiszem a géppel lesz valami "gond", lehet céges biztonsági beállítás nem engedi a winboxot (se a dude-ot) futni (McAffee tűzfal). Viszont ugyanezen a gépen futó virtuális gépen (XP) simán megnyílt a legfrissebb winbox is. Ahogy mondtam új vagyok, nem ment elsőre a frissítések letöltése, mármint hogy hol keressem, de végül meglett a packages alatt (nyilván, ugye
).
Szóval most, azon kívül, hogy kicsit kényelmetlen a vm alóli használat, úgy látszik minden ok. -
poli27
veterán
válasz
Zwodkassy
#2988
üzenetére
Ez a beállítás a Telekom szerint... valaki aki jobban vágja ezt meg tudná nekem nézni?
pmbe adok temawiever elérést délután,csak hogy lássam én is mi a titok .A Magyar Telekom által használt allokált IPv6-os címtartományok, melyekből előfizetőink IPv6 címet kaphatnak:
2001:4c48::/32 (vezetékes)
2a00:1110::/32 (mobil)
DNS (Domain Name System) szerver címei technológiától függetlenül:2001:4c48:1::1
2001:4c48:2::1
Windows esetén, ha ide kattint itt talál segítséget a TCP/IP protokoll beállításokhoz. (jellemzően az IPv6 engedélyezve van alapbeállítás szerint)Vezetékes digitális elosztók (kábelmodem vagy home gatewayek (HGW) működése DOCSIS hálózaton:
A HGW Internet felőli oldalára egy /64-es IP subnetből 1 db. IPv6 címet kap
A HGW 1db /56 IPv6 prefixet is kap, melyből az első /64 prefix a LAN oldalon kerül felhasználásra. A /56 prefix többi részét az ügyfeleink által telepített plusz routerek használhatják (kérhetik DHCP-vel) prefix delegálás keretében további interfészeik IP címmel ellátására
A kiosztott /56 prefixek általában változatlanok hosszú ideig egy adott végponton, de bármilyen Telekom oldali hálózati átalakítás vagy HGW csere esetén a delegált /56 prefix megváltozhat
HGW-ekben van DHCPv6 (Dynamic Host Configuration Protocol) szerver és SLAAC (Stateless Address Auto Configuration) támogatás is az ügyfeleink helyi hálózata számára
HGW-ekben alapértelmezetten az IPv6 tűzfal úgy van konfigurálva, hogy Internet felől ne lehessen IPv6 kapcsolatot létrehozni az ügyfeleink helyi hálózatai felé. Ez a funkció a HGW beállításaiban, jellemzően a http://192.168.0.1/ címen kikapcsolható
Kábelmodem vagy bridge módban használt HGW esetén a modemre kapcsolódó ügyfél eszköznek kötelezően DHCPv6-ot kell használnia, ott az SLAAC nem támogatott -
#2973
Bile Demon
őstag
Zwodkassy
#2972
Bile Demon
őstag
válasz
Zwodkassy
#2972
üzenetére
Frissítettem a 6.38.1 verzióra, de továbbra sem megy át az IPv6 forgalom a Mikrotiken.
Látsz valami olyat az utolsó képemen, ami problémát okozhat?
Az IPv6 Route List nálad is hasonlóan néz ki? (3. és 4. bejegyzést nem értem, ugyan az a cím, mégis kettő van belőle és az egyik nem elérhető) -
bacus
őstag
-
-
#2963
Bile Demon
őstag
Zwodkassy
#2962
Bile Demon
őstag
válasz
Zwodkassy
#2962
üzenetére
Miután beállítottam a LAN oldalra a ::81/64 címet (a poolbol) automatikusan kap címet és Default Gateway-t a PC.
A PC-ről a Default Gateway-t tudom pingelni, mégse működik!Kell e még bármit konfigurálni a Mikrotiken, hogy routolja az IPv6 forgalmat az interfészei között, vagy ez automatikusan megtörténik? Mert én csak annyit állítottam, be, hogy:
WAN interfész DHCPv6 kliens (prefix + address kérés)
LAN interfész manuális címkiosztás a poolbol (a kapott prefix van az elején).
Minden más dinamikusan létrejött.
-
#2960
Bile Demon
őstag
Zwodkassy
#2955
Bile Demon
őstag
válasz
Zwodkassy
#2955
üzenetére
Megadtam a ::81/64 címet a pool-ból.
Lett is egy értelmes, globális címe a LAN oldali interfésznek.Ez után, már kapott is IPv6 címet a Mikrotik mögötti PC.
(Már akkor, amikor még a DHCPv6 szervert nem is engedélyeztem a LAN oldalon.)
A felső 64 bit megegyezik a router LAN interfész címével, az alsó 64 bit, meg valami random (vagy MAC address alapján generált).
Ennek ellenére nem működik.
ping -6 google.com, a név feloldás működik (IPv4-en keresztül gondolom), de nincs válasz...A DHCPv6 szerver engedélyezése után, nem történik semmi. (bindingsnél semmi), mondjuk ha jobban belegondolok, a pool, amit a WAN oldalon kapott a Ciscotool egy /64-es tartományt már teljesen el van használva, a LAN interfész címére (poolnál used prefixes: ether2-masterhez a teljes /64 tartomány).
Vagy ez nem gond, ebből kellene egyedi címeket osztania? (már ha működne)
A Mikrotiken belül a Tools / Ping-nél jön válasz az IPv6 szerverektől a pingre.
A PC-ről is tudom pingelni a Mikrotik LAN és WAN interfész címét (válaszolnak), de az interneten lévő szerverektől nem jön válasz.
Már csak arra tudok gondolni, hogy a gateway beállítás nem jó, vagy a routolás, mert LAN-ról és netről is el lehet érni a Mikrotik interfészeit...
Rosszat kereteztem be, de a két alsó cím megegyezik, a kék sorra mégis azt mondja, hogy "unreachable".
-
#2953
Bile Demon
őstag
Zwodkassy
#2947
Bile Demon
őstag
válasz
Zwodkassy
#2947
üzenetére
"Nekem Digi van, cask erről tudok nyilatkozni:
- Wan iterfész: ezen DhcpClientv6, Address és Prefix pipa (igénylés), megadtam egy Pool-t, és a PoolPrefixLength=64 (a Diginél 64 bit). UsePeerDns és AddDefault Route pipa.
- Lan oldal: itt a Bridge interfészre definiáltam egy Dhcp-Server-v6-t, ahol is a előzőleg megadott IpV6Pool-t használom, adom meg. A gond akkor van, ha ez nem jön neked létre."Megpróbáltam pontosan így, ahogy írtad.
WAN interfész kap egy címet ami így néz ki:
2001:xxxx:xxxx:9500:aaaa:bbbb:cccc:dddd:eeee:ffff/64
Ez szerintem jó, internetről tudom pingelni a Mikrotik WAN interfészét, tehát odáig routol a Cisco.És létrejön egy pool, benne egy /64-es címtartománnyal:
2001:xxxx:xxxx:9580::/64Ebből hogy lehet értelmesen tovább osztani?
Van egyáltalán lehetőség így, arra, hogy a Mikrotik mögül elérjem az IPv6-os szervereket?LAN interfészre (nálam ether2 switch master) beállítottam a DHCPv6 szervert, megadtam a poolt, engedélyeztem. A kliens PC-k NEM kapnak IPv6 címet ettől a szervertől.
Amiről sejtem, hogy gond lehet: a LAN interfésznek nem állítottam be IPv6 címet, csak egy link local címe van. (Jó az úgy, vagy mit állítsak be?) -
bambano
titán
válasz
Zwodkassy
#2947
üzenetére
"/64-es prefix 1db subnet. /63-as 2db subnet, /62-es 4db subnet lehetséges. Még nem egészen vágom miért": azért, mert az okosok úgy gondolták, hogy a helyi hálózaton úgy osztanak ipv6-os ip címet, hogy az ethernet kártya mac címéből, ami 48 bit, fix módszerrel csinálnak 64 bitet, az lesz a v6-os cím egyik fele. a másik felét kapod a szolgáltatótól.
szerintem pazarlás, de ez van, ezt kell szeretni.
-
#2946
Bile Demon
őstag
Zwodkassy
#2945
Bile Demon
őstag
válasz
Zwodkassy
#2945
üzenetére
És mi lett a megoldás?
Nekem egyelőre még működik.
Más:
Már csak az IPv6-al vagyok elakadva.
(Telekomos kábelneten van IPv6, ami működik is, ha a PC a Cisco EPC3925-be van dugva közvetlenül.)Mikrotikben beállítottam a DHCPv6 klienst. (Request és Prefix pipa)
WAN port kap egy címet, ami kintről elérhető és az IPv6 poolba egy /64 címtartományt kapok. Sehogy sem tudok /62 /60 vagy /56 tartományt igényelni. Ennek nem tudom mi az oka?
A poolbol kiosztok címtartományt (/64-et jobb híján) a belső hálózatra.Belülről tudom pingelni a belső és külső interfészt is, de az internetet nem éri el. Az internet felől is tudom pingelni a külső interfészt, de nem lát be.
IPv6 tűzfalnál minden üres. -
bacus
őstag
válasz
Zwodkassy
#2773
üzenetére
Valamit keversz szerintem.
Ma már nincsenek hubok, csak switchek, és te abból indulsz ki, hogy ha a switch két portja kommunikál, akkor az nem lassitja a többit. A wifi ebből a szempontból inkább úgy működik mint a hub. Egy csatornán egyszerre egy pofázik, a manager ezt vezérli, hogy ki. (azt is tudja, ha elég messze vannak egymástól az ap-k és fizikai átfedés nincs), akkor nincs lassulás, nem zavar, ha van átfedés akkor nyilván lassul.
(és épp ezért sok sok kliensnél több ap-t és több csatornát sem bün használni)De ez nem a zavarás, ami sztem inkább az amikor mondjuk két független ap ugyanazon a csatornán két klienssel művel ...
Ott akár egyszerre is pofázhatnak, ami után mindenki kussba vágja magát, majd kivár egy random időt és újra pofázni kezd. Ha nincs mázli, akkor újból összeakadnak, és kezdődik előlről. Ez a zavarás! Itt a kliensek növekedésével exponenciálisan nő az ütközés, és látványos a lassulás. (és igy működtek a régi még 93 ohmos koax vezetékkel még bnc dugókkal szerelt arcnet hálózatok. Uhh de sokat szereltem még olyat.)Capsmannal a másolásnál a max átviteli sebességen osztoznak a kliensek! De itt a lassulás mondjuk közel lineáris a kliensekkel.
De kérem, aki ezt jobban tudja nálam, nem sértődöm meg, ha kijavit és alátámasztja pár linkkel.
-
bacus
őstag
válasz
Zwodkassy
#2770
üzenetére
valamit nagyon benézel. Még közös ssid sem kell, nemhogy közös csatorna - a jó zavarásért.
Naná, hogy kimarad ping. Egy jol beállitott capsmannál nincs vesztés!
Én több irodában, lakásban csináltam, nincs ma különbség, hogy otthonra minek, mindenki voipol (skype, whatsapp, messanger, rendes voip) 100 ft/hó egy vezetékes szám, egymást ingyen hivják, kinek nincs még otthon voip telefonja?Lakótelep, 80 ap, mindenki zavar mindenkit, vasbeton falak, naná, hogy több ap, kell a capsman! És mivel capsman vezérli, nem zavarják egymást közös csatornán, sőt!
-
bacus
őstag
válasz
Zwodkassy
#2102
üzenetére
egy kicsit zavaros még, hogy van nálad bekötve.
Ha mögötte vannak gépek, nat nélkül, hogy megy a net?
Ha mellette lenne, mondjuk csak úgy switchként beteszem egy hálózatba, akkor a mikin nem tudsz mit konfigolni, mert a redirect szabály jó lenne, de visszafele a valódi ntp szerver már nem a mikin keresztül küld választ, ezért nem fog menni.
lehet félre értettelek, de lehet egy egyszerü rajz nem ártana, hogy van nálad ez bekötve..
-
bacus
őstag
válasz
Zwodkassy
#200
üzenetére
jó gyors volt.
a burst lényege, hogy nem egyenletes eloszlást is enged. Ha azt mondom 10 kérés percenként, akkor az 6mp-ként egy. Ez az egyenletes eloszlás, ez elég ritkán van a való életben.*** A burst azt mondja, hogy mennyi ideig engedje túl és mennyivel a limitet.
Ez a queue-knél is nagyon fontos. Mert lekorlátozol valakit 32 kbitre, egy web oldalt nem tud betölteni normálisan, de ha a burstel azt mondod, hogy 5mp -re 50Mbit, majd utána 32 kbit, akkor a böngészés élmény megvan, csak letölteni nem tud.
*** sajnos aki nem tanult felsőoktatásban, valószínűleg nem igen találkozott az eloszlás (mint fogalom), eloszlás függvényekkel, pedig eléggé fontos pl. a "pro" konfigoláshoz..
Azért nem kell nagyon belemászni a matekba, elég megérteni, hogy ha megeszek 1 nap 1 zsemlét, az ritkán jelenti azt, hogy minden fél órában eszem egy falatot... -
bacus
őstag
válasz
Zwodkassy
#1391
üzenetére
Akinek több kell, az két dolgot tehet
-vagy vesz egy erősebb mikrotiket (a 3011 nem vészes)
-vagy vesz egy hardver natos soho routert és lemond a miki extráiról. Esetleg beteszi a mikrotiket és mint egy hálózatos szervert továbbra is használhatja, oszthat ip cimeket dhcpn, lehet vpn szerver, stb. Ekkor sincs dupla nat. A port forwardokat a hardver natos routerek is tudják, hairpin is mind alapból ott van. -
bacus
őstag
válasz
Zwodkassy
#1371
üzenetére
"Ugye itt már többször is szó volt arról, hogy a kis Miki routerek (pl. Rb951G sorozat) megtérdelnek a PPPoE kapcsolattól (nem túl gyosak ezen a téren :-)."
Ez azért relativ, ki mire mondja, hogy megtérdel, mert a 200Mbitet átviszi, az meg már nem rossz.
A hardver natos egyéb routerek custom firmwarrel is kb ennyit tudnak.
Aki meg ennél nagyobb sávszélességet akar, az ne egy kis soho eszközt vegyen.Én nemrégen cseréltem le az irodai routerem, most egy 3011-re, mert az előd 493G-t nem "csak" pppoe -vel tudtam megfektetni
-
bacus
őstag
válasz
Zwodkassy
#1077
üzenetére
"márpedig csak addig élsz"
egy dologról beszélünk, de a wds mesh nem csak és kizárólag wifin kommunikált, hiszen az útvonalakat ott tudtad súlyozni, akinek volt esze, az pont nem a wifinek adta az előnyt. Amennyiben csak wifi kapcsolatot használtál, akkor teljesen igazad van, de én wds meshez is mindig használtam egy gerincet.
Kiindulási alap: wifi roaming, wifi hatósugár növelés.
Szerintem ha az eszköz frekit is vált, (vagy más az ssid), stb, akkor nem lesz folyamatos a kapcsolat, azaz a váltásnál újból kap pl dhcp-n ip-t. Ez szerintem még capsmannel is igy van, mert maga az eszköz fogja kezdeményezni ezt, neki az a hálózat NEM ugyanaz. Bár ezt nem próbáltam.
Capsmanban azonos profilt használva, az én eszközeim úgy váltanak a cap-ok között, hogy nem szakad meg a kapcsolat, pl. ping folyamatos, stb. Sőt, nem is látszik több eszköznek sem windows, sem android alól.
/saját panel lakásomban rb493g wifi+capsmanager, mellette egy hap, és egy rb951, itt 80 wifit látok, ezért kellett minden szobába egy ap/És itt el is érkeztünk a hatósugár növeléshez, több cap használatával sokszoros terület lefedhető wififel az eszközök felé teljesen transparens módon, pl. egy ügyfelemnél budaörsi 3 szintes ház minden szintjén maxhoz közeli térerő még a spájzban is, whatsapp beszélgetés nem szakad meg, miközben a kertből lemegy a pincébe, majd a házon belül fel az emeletre. Mindeközben minden wifi eszköz szabályosan működik, max 100mW.
-
bacus
őstag
válasz
Zwodkassy
#1066
üzenetére
Miért kellene mást? Szerintem pont ez a lényege, hogy nem csak központilag van menedzselve, de teljesen transparensen vált, stb. Egy freki, naná, több ilyet is csináltam, remekül megy.
Régebben (capsman előtt) erre egy wds mesh hálót kellett csinálni, az is működött, de tény, hogy a capsman sokkal megbizhatóbb. A wds mesh is ugyanazon a frekvencián ment.
-
-
SimLockS
tag
válasz
Zwodkassy
#988
üzenetére
Jaja, ez is igaz...
Tehát ez mindenképpen szívás...A queue-nél megszoktam, hogy kismillió sor van. A tűzfalnál talán szerencsésebb, ha minél egyszerűbb. Próbálok rágyúrni az interfész alapú szabályozásra.
Az IP alapú szabályozás nem megfelelő, mert akkor elveszik az a minimális szimmetria is, ha egy helyen tíz, a másik AP-n meg 1 user lóg.
-
SimLockS
tag
válasz
Zwodkassy
#984
üzenetére
Ez igaz, de a szemléletesség kedvéért egy példa: van egy bérház, ahol van 50 lakás. WiFi hálót akar bele a tulajdonos, de csak 30-ba kell tenni, mert az egy tulaj kezében van. Régi ház, így egy lakás, egy AP módszerrel mindenhova kerül egy AP. Mindenhol azonos SSID kell, azonos IP tartomány is mehet. Azért 30-szoros tűzfal/szűrő stb elég húzós...
Amúgy igen, ott a virtuális interfész, a queue-ben ki is lehet választani, de erre nem úgy látszik, mintha illeszkedne a szabály. Még felmerült bennem, hogy interfészenként másik vlan legyen, picit egyszerűbbnek tűnik, aztán taggeletlenül átfolyatom a tűzfalon, de nem próbáltam még ki, igaz ez sem túl "elegáns"...
-
vgergo
aktív tag
válasz
Zwodkassy
#920
üzenetére
Valami más lesz, mert www tiltva van, csak ssh-t használok.
Mikrotik wiki akapján próbálom beállítani a hairpin-t, de valamit félreérthettem, mert nem sikerült.
Így próbáltam:
5 ;;; hairpin
chain=srcnat action=masquerade protocol=tcp src-address=192.168.88.0/24 dst-address=192.168.88.254
out-interface=bridge-local dst-port=80, 443 log=no log-prefix="" -
válasz
Zwodkassy
#902
üzenetére
6 chain=forward action=accept protocol=tcp dst-port=80 log=no
log-prefix="filter"7 chain=forward action=accept protocol=udp dst-port=80 log=no log-prefix=""
8 chain=forward action=accept protocol=tcp dst-port=443 log=no
log-prefix=""9 chain=forward action=accept protocol=udp dst-port=443 log=no
log-prefix=""Ezekre miért is van szükség? Én használok "port-forward"-ot, de ilyen szabályok nélkül, és műxik.
Üdv,
z -
#805
vitezlejszlo
őstag
Zwodkassy
#803
vitezlejszlo
őstag
válasz
Zwodkassy
#803
üzenetére
Az nem lehet, hogy túlságosan az antenna alatt álsz? Emlékeim szerint a rúdantennák nem szórnak nagyon maguk alá. Esetleg próbáld meg kicsit megdönteni az udvar fele ahol jobb vétel kell, vagy ha nem lehet, akkor próbáld ki távolabbról, hogy nem-e jobb a vétel úgy (mármint hogy "belemenj" a sugárzási profiljába)
-
bacus
őstag
válasz
Zwodkassy
#639
üzenetére
Nem, a tűzfal kiértékelése leáll az első illeszkedő szabálynál.
Nekem az az érzésem, hogy a fastrack kapcsolatok előre sorolódnak és ha lehet, akkor már nem is vesznek részt a tűzfal szabályokban. Ettől lesz fast.
Mivel megvan az illeszkedő szabály, ezért utána már nem értékelődik ki semmi, acceptot kapott ráadásnak.
-
bacus
őstag
válasz
Zwodkassy
#637
üzenetére
Mi a kérdés?
Gondolom amikor már a content vizsgálat menne, akkor az már rég related, established csomag, igy ignorálódik az a tűzfal szabály.
Bár a sorrend szerint nem kellene, de ha aktiv a fasttrack akkor az egy különleges "mangle" jelet kap utána, és gyanítom felborul a sorrend.
A 443-as portba eddig sem láthattál bele, zárd ki ha a 80-as port a dst, akkor nem lehet fasttrack.
).
)
majd kipróbálom...
Új hozzászólás Aktív témák
ekkold
- Lenovo Thinkpad L13, 13,3" FHD IPS, I5-10310U, 16GB DDR4, 512 GB SSD, W11, Számla, 1 év garancia ( o
- Lenovo Thinkpad L15, 15,6" FHD IPS, Ryzen 7 Pro 4750U , 16GB DDR4, 256GB SSD, W11, Számla, 1 év gara
- SAMSUNG 27" Odyssey OLED G6 G60SD QHD 360Hz 0.03ms Gaming Monitor - MediaMarkt garancia 2027.11.25.
- ASUS PRIME GeForce RTX 5070 OC 12GB hibátlan, garanciás, személyes átvétel
- Eladó Kukirin M4 MAX garanciális CSERE IS!
- GYÖNYÖRŰ iPhone 13 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3573, 99% Akkumulátor
- GYÖNYÖRŰ iPhone 14 128GB Purple -1 ÉV GARANCIA -Kártyafüggetlen, MS3676
- Samsung Galaxy S21+ / 8/128GB / Kártyafüggetlen / 12Hó Garancia
- GYÖNYÖRŰ iPhone 12 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS2113, 100% Akkumulátor
- Apple iPhone 16 256GB,Kábel,12 hónap garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest