- iPhone topik
- Mobil flották
- Honor 400 Pro - Gép a képben
- Íme az új Android Auto!
- Sony Xperia 1 VII - Látod-e, esteledik
- Xiaomi 14 - párátlanul jó lehetne
- Honor Magic V5 - méret a kamera mögött
- Samsung Galaxy Watch7 - kötelező kör
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- iPhone 16e - ellenvetésem lenne
Hirdetés
-
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
-
adika4444
addikt
válasz
ekkold
#22793
üzenetére
A system routerboard menüben megvolt az upgrade? Anno Mr Dini kollégával kerestük egy darabig a memóriaszivárgás okát vagy három éve és végül ez a firmware upgrade volt a megoldás. Azóta - bár sokan nem tanácsolják - minden ROS frissítés után a board fw-nek is tolok frissítést, ezzel a hAP ac2 hibátlan.
-
adika4444
addikt
válasz
Shkiz0
#22576
üzenetére
Már nagyon apró feszingadozás is képes ilyen problémát okozni. Egy hap ac2 gyári PoE táppal van bekötve, egy kb. 5 méteres CAT5E-vel. Van valahol egy pont a kábelben, ahol sérült lehet, mert ha rosszul áll, akkor néhány tíz percenként lemegy egyik-másik ethernet, majd 100 megán linkel, majd újra és gigán és ezt loop-olja.
Nem tudom, más gyártó eszközei érzékenyek-e ilyen szinten, az biztos, hogy ami mikrotik-et láttam, annak ez mind vesszőparipája, komplett 24 portos CRS tud baromságokat csinálni, ha már egy porton áramgond van... -
adika4444
addikt
válasz
kammler
#22445
üzenetére
Hol vetted? Mennyire masszív az eszköz és az USB TypeC rajta?
Powerbankkal mifit varázsolnék belőle időnként a hátizsákban, de sokszor hálózatról menne. Most egy hatodik évét töltő ZyXEL-t használok, de ha az aksi tönkremegy, jobb lenne vlmi univerzálisabb megoldás. Az USB modem sajnos csak CAT4-es.
-
adika4444
addikt
Hali!
Azt mi okozhatja, hogy OSPF-en olyan route-ök is közlekednek, amik le vannak szűrve a routing filter-nél?
Ez a konfig vonatkozó része:
```
/routing ospf instance
add disabled=no in-filter-chain=ospf-in name=ospf-instance-1 originate-default=never out-filter-chain=ospf-out \
redistribute=connected,static
/routing ospf area
add disabled=no instance=ospf-instance-1 name=backbone
/routing filter rule
add chain=ospf-out disabled=no rule="if (dst in 10.0.0.0/8) { accept; }"
add chain=ospf-in disabled=no rule="if (dst in 10.0.0.0/8) { accept; }"
add chain=ospf-out disabled=no rule="reject;"
add chain=ospf-in disabled=no rule="reject;"
/routing ospf interface-template
add area=backbone disabled=no interfaces=\
loopback,vpn-r1,vpn-r2 type=ptp
```A konfig szerint a 10.0.0.0/8-at kéne küldenie és fogadnia, ennek ellenére vígan közlekednek 172.16.0.0/12-ből is subnetek, illetve minden más, ami connected a túloldalt valamelyik interfészen. Ilyen szűrést első körben csak a fő routeren szeretnék, erről másoltam be a konfigot. Nem az lenne ezeknek a lényege, hogy ami reject, azokból a subnet-ekből ne fogadjon semmit? Vagy is a 10.0.0.0/8 kivételével sehonnan semmit...
Azért is gond ez mert több helyen van backup vonal és nyilván így teljesen megkuszálja azt is...Vagy én értem félre nagyon? Hogy kéne szűrni a subnet-eket?
-
-
adika4444
addikt
Hali!
Az normális, hogy egy valamilyen Xeon procis Debian-on virtualizált X86-os RouterOS CHR egy WireGuard-on át indított speedtest-től 100%-ra járatja az egyik magot és a sebesség maximum 50 Mbps?
Egy Pentium N3540-es laptopot használtam régen WG szervernek, de megeröltetés nélkül átment rajta 300 Mbps (biztosan többet is bírt volna, csak ez a netem teteje).
-
#21487
adika4444
addikt
E.Kaufmann
#21479
adika4444
addikt
válasz
E.Kaufmann
#21479
üzenetére
Gondolom valami rádiós linken van átlőve a PPPoE. Nálunk is van egy ilyen, bridge-vel teljesen stabil. Viszont fura, amit írsz, ha kirántom a kábelt és visszadugom, azonnal visszacsatlakozik a DIGI. Vagy is ez így történt még néhány napja
Akkor van csak gond, ha másik eszköz próbál csatlakozni ilyen szakadás után. -
adika4444
addikt
válasz
adika4444
#21197
üzenetére
Megoldva. A felállás, hogy van több WAN és DHCP-n kap IP-t, ami miatt a routing rule-ök megírása nem egyszerű. Végül a dhcp kliens kapott egy scriptet, ami bind esetén beállítja az új IP-t. Így hibátlanul megy, a forgalmat tudom irányítani mi, hol menjen és hová legyen NAT-olva.
-
adika4444
addikt
Hali!
Hogy tudom azt megoldani, hogy van vrf-ben felvéve egy külön tábla egy interfészre, látszólag megy is, de nem tudom ráNAT-olni a forgalmat?
Több WAN-ja van a routernek és az a gond, hogy hiába van a lista elején az out-interface=ether3 chain=srcnat action=masquerade src-address=<belso_pool>, a NAT-ot későbbi szabály alapján végzi, így ennek a számlálója nem nő 0-ról.
Routing rule-nál kell valami, hogy ne a main table-ön át menjen, hanem a wan2-n át?
Köszi! -
adika4444
addikt
válasz
Tamarel
#21071
üzenetére
ezt így most elsőre nem értem
Ha nem rakok dst address-t a routing rule-hoz, honnan tudja, hol kell kezelnie a yeti-s címre érkező packeteket?
Ráadásul ha a dst-t dobom is, az src még marad, de dinamikus DHCP mellett nem tudom, van-e jobb mód lekezelni a váltásokat, mint a netwatch + scripting, csak ha nem érhető el a pl. bix.hu, vagy one.one.one.one, akkor lehet azzal gond, hogy rendszeresen újrafuttatja a scriptet, vagy épp egyszer és utána nem tér észhez, ha feléled a net.
Nehéz ez nem tudom elhinni, hogy erre nincs valami MikroTik okosság, pl. ha új címet kap, vagy valamit, akkor futtathasson scriptet. PPP kapcsolatoknál az on-up tök jó, ide is elkélne. -
adika4444
addikt
Hali!
routing kérdésem lenne.
A routing table részen fel van véve egy tábla, amin az yettel-es forgalom közlekedik. Van két routing rule, src és dst address-nek megadva a belső IP amit a yeti router ad a MikroTik-nek (és fixálva is van). Az action lookup-only-in-table.
Mivel sebesség gondok vannak vele, átraknánk a yeti dobozát bridged módba, de így a router fogja megkapni a dinamikus IP-t a szolgáltatótól.
Milyen módszerrel tudnám, a PPPoE on-up-hoz hasonlóan követni az újracímzést?
Gondoltam arra, hogy pingelni 1 vagy több távoli hosztot az yeti interfészen át, aztán ha nem válaszol, DHCP restart majd az új cím beállítása a routing-nál. Ez vajon működhet? -
adika4444
addikt
Hali!
Adott egy CCR két L2TP klienssel egy távoli gateway-re.
A távoli GW-nek van két publikus IPv4 címe, a CCR-en routing table + rule kombókkal van megoldva, hogy a kábeles neten épüljön fel az egyik L2TP és a backup LTE-en át a másik. Ennek oka, hogy management célból mindig minden irány működjön. Ez így működik is rendben. Van 1--2 kliens, amiken tesztből azt is meg tudom így tenni, hogy a LTE-n át, a kábeles neten vagy a VPN-en át menjen ki, szóval itt teljes az öröm.
A kábeles L2TP-n OSPF-fel megy át elég sok routing szabály. Miként tudnám azt kivitelezni, hogy ha a kábeles L2TP down állapotba kerül, akkor, de csak is akkor, a LTE-n felhúzott L2TP-n át menjen az OSPF, azaz azon át hirdesse magát? Addig megvan, hogy fel van véve két routing rule, egyik 1-es distance-szel a kábeles L2TP-re tolja a forgalmat, egy magasabb distance pedig a LTE-re.
Gondolom az OSPF-nél a két L2TP interface-t kéne rangsorolni, de itt elakadtam. Miként tudnám ezt megtenni? Ha az első IF megáll, az OSPF másszon át a másikra, de ha az első feléled, térjen is vissza. Egy lehetséges opció on-up és on-down script-ek implementálása, de próbálok bízni benne, van egyszerűbb út
Köszi! -
adika4444
addikt
Hali!
Adott egy hAP ac^2 egy Telekom-os végponton, ahol van IPv6, illetve NAT-olt v4. A DIGI külföld ma sem az igazi, így eddig mindig a Telekom-on át használtam ilyen esetekben, most viszont ez IPv4-en akadályokba ütközött. Ezért átraktam IPv6-ra a Windows-os WG klienst és így is megy. Na, ez nem túl meglepő, az már igen, hogy 200/200 Mbps-t pont úgy hozza Speedtest-tel, mint IPv4-es tunnel esetén. Azt hittem, nem fogja bírni, de nagyon kellemesen csalódtam. A teszt a tunnelben már v4-en történt, bekapcsolt fasttrack mellett.
-
adika4444
addikt
-
adika4444
addikt
Hali!
Jó néhány hete (lehet, már van az pár hónapja is) írtam, hogy megállt az IPv6 RA, nem hajlandó osztani a klienseknek címet 7.11.2-re történő frissítés után a hAP ac^2.
Tegnap teljesen lereseteltem, majd a run-after-reset-tel a flash-ről behúztam az export-ot. Naggyából a felét mondjuk nem állította vissza, azt kézzel megcsináltam (bemásoltam a parancsokat).
A lényeg, hogy ugyanazzal a konfiggal hibátlan a v6, osztja a címeket. Miután visszamásoltam mindent, ráraktam a 7.12-t és ennél a frissítésnél már nem futott hibára, rendben hasít minden.
Szóval érdekes, mi okozhatta, hogy reset után, ugyanazok a beállítások mentek, előtte meg sehogy nem volt hajlandó címet adni...
-
adika4444
addikt
-
adika4444
addikt
Hali!
Hogy tudnám elrejteni a port forward-ot egy kliens elől a belső hálón?
A probléma: Adott a Yeti-től egy ZTE 5G router, amit egy CCR 3-as LAN portjával összekötöttünk. ZTE LAN tartománya a 192.168.6.1/24, innen a CCR eth3 192.168.6.2.
A ZTE elérése egészen addig okés is, amíg a CCR-ről tenném ezt meg, vagy is a tool-nál lévő fetch-csel. Visszajön a HTML.
A probléma, hogy egy elég komplex hálózat része a CCR, több telephely van összefogva és én remote adminisztrálom. Épp emiatt én egy másik eszközbe lépek be WireGuard VPN-en, ami magával hozza azt, hogy nem tudok a ZTE alhálójában lenni.
Emiatt nem tudom se pingelni a ZTE eszközt, sem az admin GUI-t elérni. Ennek oka, hogy hiába van beállítva megfelelően a routing, a source IP (nekem 10.50.50.20) olyan tartomány, amit a ZTE a WAN oldala felé routolna, hisz LAN-ra neki csak a 192.168.6.0/24 van.
Emiatt szeretnék csinálni klasszikus NAT-olást a CCR-en. Felvettem két szabályt. Az egyik az egy masquerade, ezzel kifelé NAT-olom a forgalmát a ZTE-es tartománynak, míg egy DSTNAT-tal a 443-as portot beengedem egy külön szabályban.
Ez viszont így nem működik. Rövid nyomozásom miatt azért, mert a ZTE tiltja az admin GUI elérését akkor, ha nem a LAN subnet-ből történik.
Emiatt a kérdés: Hogy tudnám megoldani, hogy egy dstnat-nál a source IP ne az én WG endpoint-om legyen (10.50.50.20), hanem a router IP-je a ZTE alhálójában (192.168.6.2)?
Kicsit káoszos, de remélem, sikerült leírnom a lényeget.
Köszi előre is!
-
adika4444
addikt
Hali!
Mit tudok tenni, ha egyik napról a másikra megállt az IPv6 RA címkioztás? Van prefix, a routeren megy is az IPv6, de a kliensek egyike sem kap címet. RouterOS 10.11.2, routerboard is friss.
Megpróbáltam újrakonfigurálni mindent, megy is, tényleg csak a címeket nem veszik fel a kliensek...
-
adika4444
addikt
válasz
dombila
#20341
üzenetére
A WG működési elvéből adódóan nem logol. Amíg az L2TP esetén kiépül egy fix alagút IP-címmel, meg minden, a WG-nél csak azt nézi mindkét oldal, hogy a kulcspár rendben van-e, kb. minden packet-nél történik egy teljes auth. Emiatt tud roamingolni, ha az L2TP alatt változik az IP, pl. vált a backup vonalra, egy szakadás mindenképp történik és ez zárja a TCP kapcsolatokat. Egy WG alagút simán túléli a váltásokat, nekem az SSH úgy bírja szakadás nélkül, hogy a laptopot alvóban mozgatom akár hálózatok közt (más wi-fi, más uplink) a WG miatt meg sem érzem.
-
adika4444
addikt
válasz
Shkiz0
#20215
üzenetére
Óvatosan költs a kétgigás netet kihajtani képes infrára, mert a Telekom hajlamos visszaszabályozni a profilt, hogy később újra elengedje. Elég hektikus ez. Az a legutóbbi konklúzió, hogy új eszköznél az első 1--2 hét ilyen, utána fixen visszaáll.
Egyébként mindenképp ragaszkodsz a RouterOS-hoz? Üzemeltetek egy vállalati network-öt, ott MT-k vannak, illetve itthon is az adja a Wi-Fi-t (hAP ac3), de a fő routerem egy MT7621-es Ubiquiti ER-X OpenWRT-vel. Ez tudja kihajtani lazán az IPv4 és IPv6 gigabitet, utóbbi pedig kell, a low-cost szerveremre csak így van gigabites elérés
Én, ha fenntebbváltok gigabitről, szerintem inkább OpenWRT irányba fogok elmenni. Otthoni környezetben sokkal flexibilisebb, mint a RouterOS. Jó a ROS is, de vannak korlátai, főleg ez az IPv6 téma nem megy úgy nekik, ahogyan kéne. OWRT-tel is van szívás, pl. a frissítés az egy kész tortúra (bár lehet script-elni), de ár/érték/teljesítmény arányban egy ezt támogató HW-rel most drasztikusan jobban járnék, mint ROS eszközzel.
Szerintem.
-
adika4444
addikt
válasz
ratkaics
#20183
üzenetére
Nekem Huawei E3372H van rajta (a H ellenére nem Hi-Link-es).
Backup-nak jó. Van itt egy B3 cella azthiszem, azzal a Yeti tud a routerben stabilan 20--30 Mbps-t. Egy jobb mifi-ben ez azért 50--60-ra is fel tud menni, szóval villámgyorsnak nem mondanám. De működik.Az E3372-nek van sok típusa, szóval csak akkor ugorj bele, ha az esetleges nem működés, csere belefér. HA nem és esetleg belefér egy nagyobb kiadás, jobb lenne egy másik LTE eszköz bridged móddal, LAN csatlakozóval.
-
adika4444
addikt
Nem tudom mi lehet ez, de én is tapasztaltam. A felállás egy OVH szerver a franciáknál és én Pesten, a DIGI netemen. A WG-t IPv6-on üzemeltetem. Néha nekem is eldobja magát és csak a wg if újraindítása segít. Más irányba nem csinálja. Nem sikerült rájönni, mi a hiba, most heti egy alkalommal csinálja, de volt, hogy hibamentes fél óra maga volt a csoda. Most pár napja Telekom WG tunnelben van az OVH-s felépítve, így még nem szakadt. Érthetetlen. MikroTik-kel belföldön tapasztaltam, DIGI és Atw végpontok közt. Megoldani nem sikerült, átálltunk L2TP-re.
-
adika4444
addikt
Hali!
Van egy elég komplex hálózat, ahol a netet egy hAP ac^2 építi fel, PPPoE-vel és ez össze van kötve egy CRS-sel CAT5E-vel.
Az ac2-n van egy bridge a 2--5 portokkal, 1-esen jön be a net, sima NAT-olás van a bridge felől a net felé.
A problémám: IP-kapcsolat híján, mivel nem vagyok a helyszínen, mac-telnet-tel közlekedek az eszközök közt. Ez teljesen jól működik. Az ac2-n elérek bármit ami a CRS-re van kötve, kivéve magát a CRS-t. A CRS mögötti eszközökről ugyancsak elérem a CRS-t és az ac2-t és ha a CRS-be belépek, abból is az ac2-t. Az egyetlen nem működő út tehát az ac2-CRS kapcsolat.
A CRS-en az összes port egy bridge-ben van. Az ac2 az ő 16-os portjára van téve, ahol a bridge port konfignál a pvid be van állítva 12-re, hogy a CRS-en már a 12-es VLAN-ban legyen a NAT-olt, működő internetkapcsolat.
A kérdés: Ez alapján van ötletetek, miért nem megy az ac2--CRS mac-telnet? Egyáltalán fogadó oldalon lehet ezt a mac-telnet témát korlátozni? Eddig nem találtam. A neighbors-nál rendben látszik az eszköz.
-
adika4444
addikt
Hali!
Adott egy hAP ac2, utána két 60 GHz Mikrotik eszköz (adó és vevő oldalon). PPPoE-s DIGI net van az ac2 mögött.
A probléma az lenne, hogy a túloldalt lévő MikroTik-nek kéne ipip tunnel-hez csatlakoznia. A PPPoE-t a hAP ac2-n szeretném felépíteni, hogy a 60G esetleges szakadása miatt ne ragadjon be a session. Így tehát a NAT-olást nem tudom elkerülni a hAP ac2-n.
Hogyan tudnék az általa NAT-olt hálón az ipip tunnel-hez csatlakozni a 60G túloldalán lévő MikroTik-kel? A DIGI net fixIP-t ad.
Köszi!
-
adika4444
addikt
válasz
ekkold
#19391
üzenetére
Simán szűrheti. Én OVH szerveren lőttem fel UDP123-ra a WireGuard-ot, DIGI-ről nagyon lassú, amint felrakom valami jó 10000 feletti portra begyorsul.
jerry311
+1. Nagyon nehéz az embereket kizökkenteni az L2TP IPSEC OpenVPN hármas bűvköréből.Pedig a WG önmagában veri mindet, noha vannak apróságok ahol célszerűbb lehet egyik vagy másik, de legtöbbször ezek nem állnak fent, csak a megszokás. Egy ismerősöm is nagyon tartózkodik a WG-től, otthoni hálójában OpenVPN van tap interfésszel, az L2 hálózat tényleges előnyét talán egy év alatt tudta egy részfeladaton prezentálni
-
#19279
adika4444
addikt
E.Kaufmann
#19276
adika4444
addikt
válasz
E.Kaufmann
#19276
üzenetére
Az IPV6 NAT-olás témával nekem egy nagy gondom van, mégpedig az, hogy ha UlA címet kapnak az eszközök, azt nem tudom rábírni, hogy DGW-ként használják, tehát force-olni kell az IPv6 kapcsolatot.
#19277XENISETE
Erőforráshasználat miatt jobb, ha a forward szabályok elől vannak, révén legtöbbet routol a router, tehát kisebb az input-output jellegű forgalom. -
#19271
adika4444
addikt
E.Kaufmann
#19270
adika4444
addikt
válasz
E.Kaufmann
#19270
üzenetére
Nem NAT-ol v6-on a Telekom. Értelme sem lenne
az persze lehet, hogy szűrik a bejövő kapcsolatokat, de ezt is kétlem, révén perpill is működik rendben a távoli elérés.A prefixcserés dolog örömteli, már csak suffix-re alkalmazható tűzfalszabály és IPv6 offload kellene. Nem állnak, csak lassan vacakolnak, 2030-ra talán a RouterOS is birtokában lesz ezeknek a képességeknek
Szerk: Az is kérdés, a ROS7.9-be érkező újítás vajon letudja-e kezelni a PPPoE újraépülést ami új IPv6 prefix-et ad DIGI és Telekom esetében, viszont ehhez a DHCPv6 klienst újra kell indítani.
-
adika4444
addikt
válasz
MaCS_70
#19239
üzenetére
Ha a passtrough az első porton megy, szerintem a 2. port IP-címezhető, azon tehát eléred. HA pedig ezt rákötöd a mögöttes ASUS egyik LAN portjára, olyan címet adsz a MikroTik-nek ami beleesik az ASUS LAN-ba (de a DHCP pool-ba nem), akkor akár a VPN-en át is kezelheted a MikroTik-et , ha hozzáférsz az ASUS LAN-hoz.
-
#19171
adika4444
addikt
E.Kaufmann
#19165
adika4444
addikt
válasz
E.Kaufmann
#19165
üzenetére
Jó dolog az IPv6, főleg a tartomány miatt, ha a túloldal is támogatja, nem kell azon vacakolni, hogy most az egyik gépre irányítom a 80-as portot, akkor a másikra a 8080-at, vagy ha nem, fel kell húzni egy nginx-proxy-t.
Csaptam jó áron Kimsufi dedikált szervert SSD-vel, IPv4-en elég gyatra, 100 Mbps-os hálózatot adnak, de IPv6-on csak papíron van korlátozva, tehát megy a gigabit amit bír a gépben a NIC. V6-on a sebességtöbblet mellett az is marha kényelmes, hogy ha kell hirtelen valamire egy VM (akár Linux akár Win) akkor simán el lehet érni kívülről, nem kell logikázni melyik port szabad még, meg átállítgatni. Pl. ha 5--10 percre kell valamihez fellövöm, használom a külső címet alap portokkkal és törlés. Macerásabb mint erre a feladatra fellőni valami VPS-t a felhőben, sebességre normális szervert venni, de egy 19 eurós dedikált vas esetében elnéző azért az ember az apró kellemetlenségek kapcsán és kb. bármit meg tudok valósítani.
Kicsit elOFF-oltam, de a lényeg talán benne van, a v6-ban nagy jövő van
-
adika4444
addikt
Hali!
Létre van hozva site-to-site módon L2TP kapcsolat egy központi eszköz és több telephely közt, tehát minden a központi MikroTik-ban fut össze (7.7 a ROS rajta).
99%-ban rendben fellépnek a kliensek. Létre van hozva mindenkinek az l2tp-server-nél a saját konfigja, a name és az user.
A probléma, hogy időnként az ip-címeknél nem úgy jelenik meg, hogy az l2tp szerver neve, mondjuk telephely1 mint interfésznév, hanem <l2tp-telephely1>. Ezzel az a gond, hogy nem a beállított név szerinti interfésszel épül fel a kapcsolat, hanem valamiféle dinamikus interfésszel, így a rá vonatkozó tűzfal szabályok nem lépnek érvénybe. Ilyenkor hiába aktív a kapcsolat, az l2tp-server-nél a telephely1 bejegyzésnél az sem jelenik meg, hogy running, hanem egy dinamikus interfész tűnik fel.
Mi okozhatja, hogy látszólag totál random dinamikusan jelenik meg, holott van létrehozva neki bejegyzés az l2tp-server-nél?
Remélem nem lett túl kusza, jelenleg működik rendben, így nem tudok kimeneteket bemásolni, de amint megint elromlik, bedobom ha addig nem lesz megoldás.
Köszi!
-
adika4444
addikt
válasz
snorbi82
#18921
üzenetére
Ha megáll, parancssorból egy curl -vv yettel.hu meg curl -vv speedtest.net parancsot futtass és rakd be ide a kimenetét. Hátha az mutatja, hol akad el a dolog. Én is MTU-ra tippelnék, de mobilnetnél nem tudom, ezt egyáltalán hol lehet állítani, meg mennyi az ideális érték. Mi az APN amúgy? NAT-olt az IPv4 cím?
-
-
adika4444
addikt
válasz
amargo
#18603
üzenetére
Ha a kliensek a forwardert kérik le (router IP-je) és az IP DNS részen van megadva az upstream szerver, akkor normális, hogy a router címe jelenik meg, hisz az ő DNS szervere kéri le az AdGuard-tól az infót és adja tovább a kliensnek. Megoldás lehet, ha DHCP-n a network részen beállítod, milyen DNS-t adjon a klienseknek, de ezt nem szeretem, mert ha kell, pl. megáll a megadott szerver, lassú nagyon a váltás.
-
adika4444
addikt
válasz
kopogo
#18573
üzenetére
Az ac3-ban nand storage van, jobban bírja, mint a flash. Ezen felül szerintem előnyösebb a kialakítása, nagyobb, nem melegszik annyira és nem rántják le a kábelek. Viszont nem tudom, nekem megérné-e a majd' 30%-os felárat az ac3 úgy, hogy az ac2 is 30k-nál indul. Mindkettő jó eszköz, az ac3 mellett még az szól, hogy a nand miatt sokkal gyorsabb a reboot és a firmware frissítése.
#18574Zwodkassy
hAP ac3-on nekem ment szépen néhány hétig, végül a CAPsMan-nal való inkompatibilitása miatt dobtam. -
#18569
adika4444
addikt
lionhearted
#18568
adika4444
addikt
válasz
lionhearted
#18568
üzenetére
A MikroTik DDNS NAT esetén nem állítja be a külső IP-címet automatikusan? Ha jól rémlik, nem hagyja, hogy RFC szerinti belsős cím kerüljön rá.
-
adika4444
addikt
A WireGuard konfigba rakd be az [Interface] részbe, hogy DNS = 192.168.1.1 (vagy ami a router címe). A WG subnet felől engedd be a DNS-kéréseket (firewall filter chain=input dst-port=53 src-address=<wg subnet>), így úgy fog menni mint amikor LAN-ból mész ki és a DHCP adja a DNS-t. Mivel feltételezem, hogy nem a WG subnetben van az IP amire felold a domén, ezért kliens oldalon kellhet az AllowedIPs-be a LAN subnet amiben van a céleszköz.
-
adika4444
addikt
válasz
user12
#18491
üzenetére
Csak példának írtam, hogy ha másik alhálózatra raknál v6-ot. De te ahogy írod nem másik alhálózatra akarod, hanem a már meglévőn címezni egy routert. Ez meg azért bonyolultabb, mert általában RA-val klienst címeznek, emiatt a router alapból nem is fogadja az ilyen csomagokat.
-
adika4444
addikt
válasz
user12
#18489
üzenetére
Azon az eszközön, amin a PPPoE interfész építi fel a kapcsolatot, az IPv6 címeknél simán tudsz egy olyat, hogy add address=::1 from-pool=telekom interface=bridge2 advertise=yes, itt a bridge2-es bridge-en is lesz v6-os tartomány és cím. Ha másik MikroTik eszköznek akarsz címet adni a hálózaton, akkor az eszközön amit címeznél az IPv6 settings-nél kell kikapcsolni a forwarding-ot és beállítani, hogy RA-n kérjen címet. Így viszont ő nem tudja továbbadni a prefixet, bár ha csak AP, akkor nem is kell, akkor csak az AP-t akarod megcímezni, azt így simán lehet.
-
adika4444
addikt
válasz
user12
#18487
üzenetére
akkor adj neki címet, vagy is hát inkább egy tartományt ahogy a bridge-nek. Telekom-on a /56-ból meg tudsz címezni pár interfészt
Legjobb tudomásom szerint nem tudsz prefix-et továbbadni. Csak címet tud kapni a mögé kötött MikroTik, de azt csak ő tudja használni. Esetleg még NAT-olni lehet, de IPv6-on nekem felemás a tapasztalatom vele. A router mögött router felállást nem tudom, v6-on hogy lehet normálisan kivitelezni leszámítva azt, amikor egynémelyik router tud IPv6 passtrough-t és csak továbbadja a mögötte lévőt (pl. ASUS-ok).
-
adika4444
addikt
Hali! Lenne egy érdekes kérdésem amire ezidáig nem találtam választ. Adott egy read-only hozzáférésű account egy VPS-en futó RouterOS-hoz, első kérdésem, ez olvasásban limitál-e valamit.
A második kérdés pedig, hogy erre a vasra van routolva egy /26-os tartomány (ebből tudunk adni címeket a klienseknek). A kliensek változatosan (L2TP, SSTP) módon csatlakoznak, de van egy olyan gondom, hogy egyszerűen nem látom, hogyan van melyik külső IP hozzárendelve a tartományból adott eszközhöz. Az export-ban egyedül egy tűzfal address-list-ben látom az ügyfélnek a címét, de a ppp profiles-nél a local és a remote címe is egy-egy 172 kezdetű belső cím. Néztem a /ip/route részen, ott dinamikus szabályként megjelenik (D flag) adott cím az ügyfélhez routolva, viszont nem látom, hogy a VPS-en futó router hogy csinálja. néztem már és csináltam teljes exportot a /routing-ról, ott nincs. Az egész /26-os blokkal csak a firewall address-list-ben találkozom, ott is egy-egy elemével csak, ami épp ki van osztva.
Remélem nem lett nagyon kusza. Van valakinek valami ötlete? Vagy a read-only hozzáférésem korlátozza a dolgot és full joggal többet látnék?
-
adika4444
addikt
válasz
freddirty
#18180
üzenetére
Hali!
Jó lenne tudni, milyen VPN (WireGuard, OpenVPN, L2TP Ipsec)?
Ezen felül a quickset-es dolgok (a tűzfalszabály alapján annak tűnik) nem a legjobb út, mert feketedoboz jelleggel nem pontosan tudod, mit miként állított be. Mindazonáltal a manageléshez kéne egy olyan input szabály, ahol accept action van és az src-address a VPN pool. Ez a drop-os beírt szabályod fölé, révén a MikroTik fentről lefelé értékeli ki azokat. -
#18072
adika4444
addikt
Project: A
#18067
adika4444
addikt
válasz
Project: A
#18067
üzenetére
QuickSet helyett szerintem használd ezt a leírást.
Anno ez alapján kezdtem én is. Időben nem több, mint QS-ezni és keresni a hibákat. -
-
adika4444
addikt
Kímélendő az akkut, inkább USB táplálású RNDIS protokoll-t használó 4G dongle-t nézz.
Én hasonló mutatványt egy ZyXEL WAH7706-ossal szoktam művelni. A gond, hogy aksis, annak azért nem válik a javára a tartós ilyesfajta üzemeltetés. Van még egy E3372 stick-em, de nem tud LTE-CA-t (kisebb így a sebessége), és RNDIS-t sem, ezért PPP interfészként működik. A PPP viszont jobban paraméterezhető, a LTE-nek van pár hülyesége, pl. kötelezően DHCP-n kér címet, ami akkor baj, ha a LTE eszköz is egy NAT, és mondjuk adott IP-re van DSTNAT/DMZ/port forward, mert a MikroTik-en nem állítható statikusra.
-
adika4444
addikt
válasz
yodee_
#17664
üzenetére
Wireguard Warp-pal teszteltem, ott 70 Mbps. Most összekötöttem egy Telekomos hAP ac2-vel, 170--220 Mbps között jön minden, a MTU állítgatásával változik, de ha nő a sebesség, egyre jobban ugrál. Viszont ha a Telekom-os WG-be rakom bele a fenntebbi VPS-en lévő WG-t, akkor nagyon hullámzó a sebesség. Tűzfal átnézve, fölösleges szolgáltatások nem futnak, szóval szerintem ez ilyen. A sebesség nem nőtt, de ismét beleraktam a Telekom VPN-be a netcup-ot, és stabilabbnak sokkal stabilabb, sajnos ez megint fekete pont a DIGI-nek, hogy ennyire rosszak ebbe az irányba.
-
#17660
adika4444
addikt
Alteran-IT
#17659
adika4444
addikt
válasz
Alteran-IT
#17659
üzenetére
A Telekom új TV platformjának mindenképpen kell a net (nem elég a belsős VLAN). Ezért született az a megoldás, hogy minden PPPoE felhasználóval kétszer lehet belépni, így az egyik munkamenet az ONT-on, másik egy saját eszközön.
HA viszont az ONT-on nincs felépítve, akkor két saját eszközre is mehet, a mutatvány a Sagem 5655 v2 összes LAN portjával működik, úgy egy éve próbáltam.A drágulásra meg csak nagyon röviden annyit, hogy amikor tápot kerestem az ac3-hoz (talán hétfőn vagy kedden), akkor kíváncsiságból megnéztem, találtam 35900-ért, viszont tegnap előtt már 47000 volt a legolcsóbb helyen. Én tavaly nyáron vettem 32k-ért. Annyit bőven megért, de 50k-t nem, annyiért két éve simán tudtam volna venni RB4011-et, és most nem küzdenék vele, hogy WireGuard-on egymásba ágyazva két tunnel-lel nem bír el.
Ja, két tunnelt pedig azért raknék egymásba, mert a DIGI peering-je netcup (Anexia, Németország) irányba borzasztóan rossz, viszont egy WireGuard-dal van összekötve a routerem a root server-emmel. Ha cloudflare-en át érem el az rs-t, akkor a max. 80 Mbps helyett felfelé és lefelé is hozza amit a csomag kínál (FTTH 1000/300), csak a router ezzel már nem bír, Debian-on viszont megy faszán.
-
#17407
adika4444
addikt
silver-pda
#17401
adika4444
addikt
válasz
silver-pda
#17401
üzenetére
Igen, az valószínű RNDIS-t használ, a /interface/lte helyen is látnod kell. Elég sok mifi megy így MikroTik-kel, két szépséghibával
- Az akkus darabok (mint az én ZyXEL WAH7706-om) telep nélkül nem mennek, viszont az nem okvetlen szereti a nonstop tápellátást.
- Másrészt pedig DHCP-vel auto kér IP-t ettől az interfésztől, emiatt az IP-je, routing-ja dinamikus lesz, és ebbe nem igazán lehet belenyúlni. Azaz kézi ipkonfig-ra a WAN-nak használt USB-n nem igazán van lehetőség sajna.#17404 yodee_:
Igen, sajna PPP emulációs módban (az én Huawei E3372-153 is ilyen) van némi sebességcsökkenés, meg nem is LTE if-ként látszik, ami miatt elég sok mobilhálózat-specifikus beállítás nem vagy csak nehezen érhető el. -
adika4444
addikt
Hali! A leírás DIGI-hez készült, az teljesen normális, hogy a Telekom nem ad címet. Elég a prefix, részint mert az interfész amire rárakod kap címet amit tud használni a router, részint meg mert a Telekom /56-ot ad, azaz több szubnetre is felhasználhatod, nem úgy, mint a DIGI egyetlen /64-ét.
A dinamikus prefix miatt semmiképpen nem javaslom, hogy a router GUA címét (tehát ami a bridge v6-os címe) próbáld osztani DNS-nek, egy PPPoE újracsatlakozáskor úgy is változni fog, és maximum script-elve lehetne megpatkolni, de ez tiszta macera.
Ha a Telekom DNS címét akarod használni, akkor rakd be a prefixhez, hogy advertise-dns=yes és dns="<Telekom szervere>" (a T DNS címét most nem tudom).
Ha pedig a router forwarderét használnád v6-on, vagy script-elj (fenntebb írtam, kifejezetten kerülendő megoldás), vagy vegyél fel UlA címeket a bridge-re, ami statikus, tehát nem fog megváltozni, és ezt a címet szórhatod a RA packet-ekben (tehát a fenntebbi DNS-hez beírod a saját UlA-dat).
Az IPv6 működési elvéből adódóan nem lesz gond a párhuzamos UlA és a GUA címekkel sem router, sem kliens oldalon. Az UlA csak a belső hálózaton működik, tehát max a kliensek érhetik el egymást a címeiken, de a RA miatt a második 64 bit úgy is EUI-64 alapján fog kigenerálódni (tehát ugyanaz lesz mint a GUA cím vége). -
adika4444
addikt
Hali!
A filter-ben WAN port felől csinálj egy forward szabályt, ami engedélyezi a forgalmat a nginx-es belső IP felé. HA nagyon paranoiás vagy, akkor hasonlóan a dstnat szabályodhoz limitáld mit engedsz be (port), ha kevésbé, akkor elég a dstnat-nál kikötni
Ja, és ne felejtsd el engedélyezni a szabályokat, itt a példában ki van kapcsolva (bár gondolom szándékosan).Az input szabály pedig nem kell, hisz nem a router-re engedélyezed. A dst-address-list-nél amúgy mi ez a "Erd DDNS address" az address-list-nél?
-
-
adika4444
addikt
Többször előjött már, biztos most is fog generálni pár HSZ-t.
Abban kétségtelenül igazad van, hogy egy alap szintre szükség van ahhoz, hogy az ember fel tudja tenni a megfelelő kérdéseket. Jól emlékszem még, amikor 2019 körül jöttem ide kérdezgetni. Elég hirtelen vásárlás volt a hAP ac^2, de pár nappal a vásárlás után már scripteltem. Szerintem a ROS alapjai - némi hálózati ismeret birtokában - elég hamar elsajátíthatóak, pláne, ha van némi motiváció, én CLI-n kezdtem el használni, azóta is ezt tartom a leghatékonyabbnak.
Ott van viszont a dolog másik oldala is, amit #16618 Zwodkassy írt. A fórum szerintem is a kölcsönös segítségnyújtásra szolgál alapvetően, de én kicsit tágabban értelmezném ezt a dolgot. Különféle témáknak, eszközöknek meg kérdéseknek eltérő a nehézségi szintje, viszont sose lehet tudni, hogy valaki aki betér egy topicba feltenni egy alap kérdést, nem-e a legnagyobb szaki egy másik topikban. Én hálózatos területen mozgok a fórumon úgy, hogy valamilyen szinten kompetensnek gondolom magam, de járok máshová is kérdezgetni, és jó érzés akár évekkel később olyan nick-eknek ajánlani router-t, megírni, hogy kapcsoltassák ki a DIGI-nél a NAT-ot, akik a megfelelő első használt üzleti notebook kiválasztásához segítettek hozzá, vagy ajánlottak egy jó HDD-t / SSD-t.
Másik, hogy változó kinek mennyi ideje, meg türelme van a fórumra, vannak azért itt olyanok akik minden 2. kérdésre hihetetlen türelemmel adnak minden részletre kiterjedő választt és olyanok is, akik szintén vágják, de kevesebb idejük / kedvük / motivációjuk van válaszolgatni. Én mindkét oldalon álltam, ha lehet így mondani, elég gyerekként regisztráltam be ide, toltam rendesen a kérdéseket, minden apró lépés sikerélmény volt amivel tudtam válaszolni, aztán ahogy nőtt a tudásom, nőtt a tapasztalatom, úgy csökkent az időm a fórumozásra, így manapság jórészt read-only vagyok, ritkán válaszolok (általában beelőznek), kérdezni is csak akkor kérdezek, ha a lehetőségekhez képest nem boldogulok egyedül, vagy azért mert kimerült minden általam ismert tudásforrás, vagy azért mert időszűkében vagyok. Viszont így is megvan, hogy vannak területek ahová két évben egyszer betévedek. Abszolút nem érdekel, a probléma oldódjon meg, aztán én lépek is onnan. Mindent nem lehet megtanulni, és hálózatos téren is lehet olyan, aki csak a problémát akarja megoldani. Persze értem azt a részt is, hogy egy ilyen szakmaibb jellegű topikban bosszantóak a "hogy kell portot nyitni" szintű kérdések, de az ilyet szerencsére át lehet pörgetniNa de a lényeg amit ki akartam ebből hozni, hogy szerintem egészében kell ezt nézni, és az újonc jellegű rangokat leszámítva azért bízom benne, hogy a magasabb HSZ-számmal rendelkezők nem csak kérdésekből szedték össze a rangjukat. A nagyon alap kérdésekkel persze sokszor nem lehet mit kezdeni, topikfüggően én is azt gondolom, hogy van azért ahová elkél némi előismeret, mert a hozzá nem értés később súlyosabb problémákat szülhet.
Nem akarok flame-áradatot indítani ezzel, csak már régóta megfogalmazódott ez bennem, mostanra jutottam el a leírásáig
-
adika4444
addikt
Low-cost szolgáltatás, itthon tudomásom szerint a legolcsóbb / legjobb ár/érték arányú SSD KVM VPS-t nyújtják.
A fizetési rész valóban fura egy kicsit, de ennyi még belefér. Egy haveromnak volt itt több hónapig VPS-e, egy pár órás packetloss-os hálózati gixert leszámítva semmi gond nem volt vele.
-
adika4444
addikt
Hali!
Frissítettem az IPv6-os blogbejegyzésem.
Benne van, hogy hogy lehet dinamikus IPv6 prefixekkel normálisan dolgozni, illetve, hogy miként lehet a változó prefixű hálózaton lévő eszközöket elérni kívülről, úgy, hogy közben minden más el van tűzfalazva.
-
adika4444
addikt
válasz
yodee_
#15525
üzenetére
Perpill szerintem konkrét szükség nincs rá, én azért szeretem, mert sokszor eltérő - jellemzően kevésbé terhelt - routing útvonalakat használ, mint az IPv4.
Meg amúgy is. Ha már van, és elérhető, ki akarom használniMegoldódott amúgy, valamiért automatikusan az add-default-route ellenére kézzel kellett felvenni a route-t, azóta teljesen jó.
-
adika4444
addikt
válasz
pitiless
#15124
üzenetére
Nem. Ez valami T-Mobil-os csoda, hilink nélküli. Simán bedugtam a routerbe, info és data channelt beállítom, és megy is. Stabilan üzemel, jó pingeket hoz, csak a sebessége ugrál nagyon. Itt a b3-as torony tud 70+ Mbps-t egy mobilrouter-rel, ezzel a kis stick-kel max. 40, átlag 30 Mbps a sebesség. De stabil, és backupnak emiatt jó.
-
adika4444
addikt
Hali!
A probléma ott keresendő - ahogy azt írtam is a bejegyzésben -, hogy a dinamikus IPv6 prefixekre nagyon nincs felkészülve a router.
Ezért azt a megoldást sikerült találnom, hogy a Windows klienseken se legyen gond, hogy nagyon rövid lifetime-mal dolgozok. Erre én is hónapok után jöttem rá, hogy Wi-Fi-s eszközökön (pláne iPhone) problémát okoz, mert a ra packetek mindegyike nem ér el oda, így időnként meg-meghal az IPv6.
Megoldás lehet a nagyobb lifetime. Viszont ha nagyobb a lifetime, PPPoE újracsatlakozás esetén a régi cím beragad a Windows klienseken, következésképp - amíg nem jár le a preferred a régi címen - nem lesz v6-os forgalom.
Erre én ismét egy hatalmas tákolást vetettem be, PPPoE disconnect-kor eröltetve küldök RA packetet, amiben már a lifetime-ok 0-k, így a következő PPPoE csatlakozásnál az új v6-os címet fogják használni a Windows-ok, amit meg ismét felhúzok jó magasra. Nem szép, de működik.
A leírást meg a script-eket is igyekszem majd frissíteni. Nem tudom, ez alapján a pár sor alapján meg tudod-e faragni, ha nem, és nem kardinális, kapcsold ki a v6-ot, írni fogok ide ha javítom.
-
adika4444
addikt
válasz
Reggie0
#14931
üzenetére
ER-X nem gyenge, az MT7621 ofload-dal jobban tudja NAT-olni a gigabitet, mint az IPQ4019, főleg IPv6-on, ahol az MT-nek még fasttrack megoldása sincs.
Az más kérdés, hogy az Ubi-val bugos chipset miatt lehetnek anomáliák. Emellett az Edgerouter vonal Ubiquiti-éknél elég leszálló ágban van, én ezért sem eröltetném. Nekem van egy, valószínű OpenWRT-t fogok rárakni. Az EdgeOS első ránézésre favorit volt, de pár hónap után tömény szenvedés, nekem nagyon átláthatatlan.
Hogy ne legyek teljesen OFF:
Pár napja jött a 7.1rc5, ráadásul a weboldalon még development, de a routeren már testing-et ír, szóval talán lassan érkezik az éles kiadás.#14937 Reggie0
Az Edge vonal kontroller nélkül is megy, mind webgui-val, mind SSH-n át. Telepíteni csak az UniFy-hoz célszerű a controller-t (bár nélküle is el lehet mojolni).
Amúgy egyetértek, Ubiquiti nekem sem jön be, de ízlésről vitatkozni... -
adika4444
addikt
válasz
ekkold
#14881
üzenetére
Nem fog működni. A WireGuard az endpoint-okkal kommunikál, amit minden sikeres kulcsegyeztetésnél lefrissít. Azaz ha rámész egy géppel, majd később egy másodikkal, akkor azutóbbi endpoint-jára fog frissülni a peer szerver oldalon, eredményképp minden packet az új helyre fog érkezni.
Csinálj saját peer-t minden klienshez.
-
adika4444
addikt
válasz
Mr Dini
#14876
üzenetére
Hali!
Ha nem szempont a Wi-Fi, akkor is jobb választás a hAP ac^2 vagy ac^3 mint a linkelt eszköz, hacsak nem szempont az SFP port.
Nekem ac^3-mal 210/210 Mbps körül van a teteje. A router DIGI PPPoE-n lóg (FTTH 1000/300), a kliens meg egy Windows 10-es Dell laptop, változó milyen neten, de a DIGI felé van normális peering, meg a CPU-n is látszik, hogy ez a 200 Mbps környéke a teteje.
Viszont érdemes átgondolni a felmerülő igényeket, kompatibilisek-e a RouterOS 7 legújabb RC-jével, mert bár nálam pl. abszolút szépen teszi dolgát, volt itt olyan HSZ, hogy a mailküldés nem megy.
-
adika4444
addikt
válasz
mZoleee
#14865
üzenetére
A local esetében a router WAN címét (ami nálad a 192.168.1.0/24 hálózatban van) használja, ezért nem megy kívülről.
Próbáld meg így:
/ip/firewall/nat
add chain=dstnat action=dst-nat to-addresses=192.168.43.6 protocol=tcp dst-address=192.168.1.2 dst-port=80,443
Ahol
- to-addresses az a cím, amit a MikroTik-től kap a céleszköz (NAS). Nálam ez a 43.6.
- dst-address: Az a cím, ami a MikroTik WAN lába a Sagemcom-on (ez ne DHCP-vel legyen, hanem lehetőség szerint fixen). Esetemben ez address-list (wan néven), amin mindig fent van az aktuális DIGI PPPoE címem, és ha be van épp dugva, a backup mobilnet is (így mindkét irányból elérni). Nálad meg ez egy fix cím, bár ha nem megy, érdemes egy address-list-et berakni, és arra felvenni a Sagem WAN címét + a router WAN címét a sagem felé teszt jelleggel.A dupla NAT-olás miatt nem egyszerű a te eseted. Próbáld meg így, ahogy írtam, aztán meglátjuk.
-
-
adika4444
addikt
válasz
Reggie0
#14613
üzenetére
hAP ac3, szintén hibátlan a ROS7. Augusztus eleje óta használom, eleinte a Wave2 miatt próbáltam ki, de olyan elégedett vagyok vele, hogy nem láttam értelmét visszalépni 6-osra.
Az új CLI szintaxis is jó, egyedül a kérdőjelet hiányolom, talán RC2-ből kivették, így f1-ezni kell, ha help kell konzolon.
-
adika4444
addikt
Hali!
Mi lehet arra a megoldás, ha a MikroTik féle DDNS-nél a routeren IPv6 címnek egy teljesen valótlan címet mutat (ipv6 address-nél teljesen más van), a net felől pedig nem is old fel IPv6-on a mynetname.net végű doménre?
hAP ac^2, 6.47.10 LongTerm firm van rajta.
Force-update-t nyomtam neki, de semmit nem ért. Rebootolni nem akarom, távoli eszköz, és nem tudom, épp mikor használják.
-
#14461
adika4444
addikt
E.Kaufmann
#14459
adika4444
addikt
válasz
E.Kaufmann
#14459
üzenetére
+ #14460 Reggie0
Köszi!
-
adika4444
addikt
válasz
Reggie0
#14449
üzenetére
Haverom szerint 10+ éve méricskélték, hogy a Wi-Fi-k a megengedett adásteljesítménnyel üzemelnek-e. Személyes tapasztalatom nincs, akkoriban még igen fiatal voltam az ilyesmihez
Szerk: Fenntebb láttam a szenegálos trükköt, 5Ghz-n tudtommal ma is méricskélnek, hogy nem zavarja-e semmi az időjárási radarokat.
-
adika4444
addikt
válasz
atiska007
#14404
üzenetére
Tűzfalon tiltod a címet (src-address a forward láncon). Ha meg több ilyen van, esetleg address-list-tel is lehet ügyeskedni.
Mi lenne amúgy a cél? A DHCP oldali statikus kiosztást elég egyszerű megkerülni, ha pl. egy IT-sebb beállítottságú gyerkőc korlátozása a cél, egy hozzáértő haver mindig lesz aki segít neki átállítani az IP-t. -
adika4444
addikt
válasz
Statikus
#14340
üzenetére
Egyrészt nem a gyártó hibája, hogy az adott eszköz nem teljesíti az igényeidet, bár a gigabitet nem tudja NAT-olni, de LAN-on hasznos lehet az ilyesfajta képessége.
Másrészt meg ha nem értesz valamihez, érdemes előre utánajárni. Az ac2 és ac3 gond nélkül tudja NAT-olni IPv4-en a gigabitet, v6-on már neccesebb, ott nem tudja routolni, nincs meg a FastTrack támogatás, így pár alapvető tűzfalszabállyal megfeneklik 300--400 Mbps körül miközben egy magot 100%-ra járat.
Ha szétnézel a soho kategóriában is a mai napig (igaz, egyre kevésbé) probléma ez. Attól, hogy gigabites switch van benne, még simán lehet, hogy nem képes annak a sebességnek a NAT-olására. A MikroTik előtt ASUS RT-AC66U B1-em volt, koppant a CPU a gigabit mérésénél.
-
adika4444
addikt
válasz
Statikus
#14324
üzenetére
Ahogy Shkiz0 is írja, nem negyedeli a tempót, sajnos ennyire képes. FastTrack szabályokat rakhatsz a tűzfalba, de azzal az egymagos CPU-val még DHCP-vel sem látom sok esélyét, hogy elérd a gyakorlatban kihozható maxot, ami 1000-es netnél akár 940--950 Mbps is lehet.
Wi-Fi-ben csatlakoznék az előttem szólókhoz, a MikroTik sebességben nagyon nem erős, viszont nekem a CAPsMan-ben tökéletes a roamingolás és a stabilitás, ez többet ér, mint a megabitek hajtása, arra szerintem amúgy sem való a Wi-Fi.
annál tovább, hogy nem működik, távolról nem sikerült jutnom...
Új hozzászólás Aktív témák
Hirdetés
- TUF Gaming F15 FX506HE 15.6" FHD IPS i5-11400H RTX 3050Ti 16GB 512GB NVMe magyar vbill gar
- Legion 5 15ACH6H 15.6" FHD IPS Ryzen 5 5600H RTX 3060 16GB 512GB NVMe magyar vbill gar
- MSI Prestige 15 i5-1240P/ 8gb ram/512ssd FHD IPS/RTX3050Ti
- Szuper áron DELL XPS 13 9380 /i7-/16 GB Ram/512 GB SSD 4K Touch/IPS/
- Apple Watch Ultra S1 49mm 1év garancia.
- Apple iPhone 14 Plus 256GB / AKKU 100% / 12 hónap jótállás
- GYÖNYÖRŰ iPhone 11 Pro 256GB Midnight Green -1 ÉV GARANCIA - Kártyafüggetlen, MS2048, 96% Akksi
- GYÖNYÖRŰ iPhone 13 mini 256GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3042, 94% Akkumulátor
- AKCIÓ! Apple iPad Pro 13 2024 M4 512GB Cellular tablet garanciával hibátlan működéssel
- DELL PowerEdge R640 rack szerver - 2xGold 6138 (20c/40t, 2.0/3.7GHz), 64GB RAM,4x1G, H730 1GB, áfás
Állásajánlatok
Cég: FOTC
Város: Budapest