- Motorola Moto Tag - nyomom, követ
- Fotók, videók mobillal
- Yettel topik
- Android alkalmazások - szoftver kibeszélő topik
- Google Pixel topik
- Samsung Galaxy A54 - türelemjáték
- Okosóra és okoskiegészítő topik
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Vivo X200 Pro - a kétszázát!
- Apple iPhone 16 Pro - rutinvizsga
-
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
-
Tamarel
senior tag
Már másodszor tapasztaltam, hogy újraindítás nélküli routerboard (bootloader) upgrade után szakadozik a wifi (7.13.3 -> 7.13.5). Max 10-15 percenként ledob.
A különböző verzió nem zavarja, újraindítás után egyből jó.
-
Tamarel
senior tag
válasz
Reggie0 #21463 üzenetére
Mert a source nat feltétele minden LAN -> LAN csomagra vonatkozik?
Switchen belül oké, de bridge-n belül (ethernet <-> wifi)?chain: srcnat
src address: 192.168.88.0/24
dst address 192.168.88.0/24
action: masquaradehttps://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Tehát:
- "odafelé" kicseréli a source ip-t a router ip-jére
- "visszafelé" visszacseréli az eredeti küldőreMűködik, lehet észre se veszed még maximális sebességű másolásnál sem, csak felesleges.
(Úgy általában a source - destination subnet azonossága gyanús, hogy a routing logika lassulását fogja jelenteni, mert nem tud egyszerűen dönteni, pl fib alapján. Mikrotiknél még nem kellett ilyet nyomoznom, szóval lehet immunis rá.)
Persze lehet igazatok van, de akkor: miért?
-
Tamarel
senior tag
Internet vonal (digi) kieséseit hogyan naplózzátok? Valami script-el?
A pppoe-n nem látszik semmi, mégis problémás minden nap, többször. -
Tamarel
senior tag
válasz
kpepe111 #21402 üzenetére
Először is a csatornát kellene beállítani, mert az automata váltás okozhat ilyet. Másrészt az eCee értelme ezután derül ki (ott legyen a Control, ahol nincs más -> zavarásnál visszaskálázhat 40 vagy 20as szélességre).
A kinézet alapján ez a sima csomag, nem a wave2?
Szóval a legfrissebb szoftver kellene (most 7.13.3) és a wave2.Ez után haladhatunk tovább, ha még szükséges.
-
Tamarel
senior tag
válasz
E.Kaufmann #21390 üzenetére
Az passzív állapot valóban okozhat kevesebb kapcsolatot, de önmagában csak nagyon kevés peer esetén akadályozhatja meg a forgalmat.
Az automatikus port nyitás pedig biztonsági probléma, soha nem javasolt. -
Tamarel
senior tag
válasz
ncc1701 #21276 üzenetére
Cserébe jobban merül az akkumulátorod, mert n-ig még hiányoznak az energiatakarékos funkciók. Ac-tól már jó.
Számszerűen: (amikor teszteltem) éjjel 3-4%os merülés a 10-12% helyett.Persze ha ax-ed van, bekapcsoltad 2.4re és minden n-es kliens képes csatlakozni, akkor oké.
-
Tamarel
senior tag
Két szabály az egész:
/ip firewall nat
add action=masquerade chain=srcnat dst-address=192.168.0.100 src-address=192.168.0.100/24 to-addresses=192.168.0.100
add action=dst-nat chain=dstnat dst-address-list=wan-ip dst-port=22 protocol=tcp to-addresses=192.168.0.100Az első nálam elől van, az fontos. A második az utolsó a listában, annak szerintem mindegy.
A wan-ip lista az egyszerűség végett létezik:
/ip firewall address-list
add address=xxx.sn.mynetname.net list=wan-ip
add address=xxx.synology.me list=wan-ipEz azért jó, mert ha változik az ipd és még nem frissül a ddns szolgáltatónál (ez dinamikusan oldja fel és beteszi az ip-ket a wan-ip listába), akkor is a belső szerverre tereli.
-
Tamarel
senior tag
válasz
privatposta #21139 üzenetére
Akkor pl egy nyilvános vagy céges wifi hálózatból nem is lehet kitiltani senkit?
- tanúsítvány alapú eap-tls (egyébként nem is tud csatlakozni)
- esetleg mac cím alapján (pozitív lista)
- vendég hálózatra talán weboldalas belépés -
Tamarel
senior tag
válasz
flexes922 #21079 üzenetére
Még nincs hatékony és tesztelt configom.
Nálam is tervben van egy második ap, capsman felé indulok, az egyedüli kérdés a guest backhaul, hogy az hogy jön majd vissza unmanaged switchen keresztül (úgyis csak az internetet érheti el).
IoT-t el szeretném érni lanról (nem kell vlan), de az internetről le vannak tiltva.Tudom, ez neked most nem segít.
-
Tamarel
senior tag
válasz
adika4444 #21075 üzenetére
Onnan, hogy az ip / route szabály ugyanabban a routing táblában dolgozik.
Gyakorlatilag párhuzamosan van egy másik route logikád, ami csak a yettel:
- kifelé: elég a routing / rules, pl x host (source), y weboldal (destination), ezzel irányítod be a táblába, amiből ip / route szabály alapján megy ki (pl %yettel)
- befelé: nincs varázslat, ha jött egy csomag, akkor normál feldolgozásba mehet (main tábla) -
Tamarel
senior tag
válasz
szabi_zoli82 #21072 üzenetére
Valahogy el kellene különítened az eszközeid ip-jét, hogy kevesbb tűzfal szabályra legyen igény.
Például a mobil kliensek (telefon, tábla, laptop) maradnak a dhcp tartományban, a problémát okozó eszközök (tv, ps4, okosotthon) meg kapjanak fix ipt a dhcp szerveren, ezen a tartományon kívül.Így három szabályos a történet:
- forward, ha a nasról, jö, akkor allow
- forward, ha a kliens tartományból jön, akkor allow
- forward, hifi felé, drop (minden más eset)Tipikusan /24es tartományt használ mindenki otthon, szóval /25 elég erre (1-128, 129-256 bontás).
-
Tamarel
senior tag
válasz
mobilemaster #21030 üzenetére
Alapvetően jó, egyedül az 5 perces group key update zavarhat be. Próbáld ki 1 órával.
Úgy általában: szerintem is firmware upgrade kellene először, még long term esetén is a 6.49.10 2 évvel újabb.
-
Tamarel
senior tag
válasz
mobilemaster #21024 üzenetére
Mi a szoftververzió?
Van SA Query timeout a naplóban?Amúgy legyen külön ssid-t a két sávra, telefon / tábla / laptop csak 5Ghz, okosotthon / vendég 2.4Ghz-re.
(A két rádió között roaming-ol, ami kliens döntés és a 7.11 óta van egy kis zavar vele. Remélhetőleg a 7.13ban javítják.)
-
Tamarel
senior tag
A legegyszerűbb failover:
/ip route
add check-gateway=ping comment=wan1 disabled=no distance=1 dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-table=main suppress-hw-offload=no target-scope=11
add check-gateway=ping comment=wan2 disabled=no distance=2 dst-address=0.0.0.0/0 gateway=8.8.4.4 routing-table=main suppress-hw-offload=no target-scope=11
add disabled=no distance=1 dst-address=8.8.8.8/32 gateway=lte1 pref-src="" routing-table=main scope=10 suppress-hw-offload=no
add disabled=no distance=1 dst-address=8.8.4.4/32 gateway=lte2 pref-src="" routing-table=main scope=10 suppress-hw-offload=noRekurzív next hop lookup megoldás, vagyis megy egy folyamatos ping mind a két lte-n és ha nincs válasz az adott kapcsolaton, akkor az kiesik a routing táblából ideiglenesen.
(A gateway a weboldalon %lte formátumban látszódik.)Ezt egészíteném ki egy második routing táblával és még 2 ip route-al:
/routing table
add disabled=no fib name=lte2/routing rule
add action=lookup comment=lte2 disabled=no src-address=\
192.168.0.0/25 table=lte2
add action=lookup comment=nas-to-lte2 disabled=no src-address=\
192.168.0.200 table=lte2/ip route
add check-gateway=ping comment=wan2 disabled=no distance=1 dst-address=0.0.0.0/0 gateway=8.8.4.4 routing-table=lte2 suppress-hw-offload=no target-scope=11
add check-gateway=ping comment=wan1 disabled=no distance=2 dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-table=lte2 suppress-hw-offload=no target-scope=11Az eredmény egy kézi load balance + automatikus failover.
Most raktam össze kézzel, így a saját default route bejegyzéseddel még össze kell simítani (ha van). Valamint úgy tűnik így 2x2 ping fut majd.
-
Tamarel
senior tag
Kérdés, hogy mennyire szeretnéd bonyolítani a dolgot.
A load balance a connection trackingtől fog jól működni, de azt nem tudom, hogy különböző sebesség esetén mikrotiknél hogy megy.
A legegyszerűbb, ha eszközönként bontod szét (elsődleges-másodlagos beállítás mindkettőnél). Így jelentősen egyszerűbb a config.
-
Tamarel
senior tag
válasz
adika4444 #20714 üzenetére
Szerintem ezt nézd meg: https://www.youtube.com/watch?v=JB9aYqTNwlM
-
Tamarel
senior tag
A hiarpin nat gyakorlatilag egy szabály, mindössze egyedi és ezért nem találsz normális leírást hozzá.
Ez magyarázza el: https://help.mikrotik.com/docs/display/ROS/NAT#NAT-HairpinNAT
Példa:
add action=masquerade chain=srcnat dst-address=192.168.0.200 src-address=\
192.168.0.0/24 to-addresses=192.168.0.200A hatása: a 192.168.0.0/24 (lan) irányból érkező, 192.168.0.200 (nas) irányba haladó csomagokon a forrást kicseréli a router címére.
Nyilván van port forward is, hogy ddns:port címen elérd a nast mindehonnan.
add action=dst-nat chain=dstnat dst-address-list=wan-ip dst-port=5000 \
protocol=tcp to-addresses=192.168.0.200 -
Tamarel
senior tag
válasz
allnickused #20513 üzenetére
Az egyik most 55, a másik 62.
-
Tamarel
senior tag
válasz
silver-pda #20340 üzenetére
Telefon néha lecsatlakozik, majd vissza. Úgy tűnik van egy interface reset és ami akkor forgalmazna, az így jár.
Magától visszajön, nincs teendő.
-
Tamarel
senior tag
válasz
XENISETE #20308 üzenetére
Kevés olyan nagy szolgáltató van, akinél megy a wireguard csupaszon (és nem varázsnéven, csak saját kliensből).
A mikrotik része mindenképpen stabil, de több internetes oldal nem szereti.A fosbook és társai azonnal belépést kérnek, a cloudflare védelem sokszor kiakadt (régen emiatt egyáltalán nem ment a netpincer).
Valamint alkalmanként a fonts.googleapis.com is blokkolja a proton szervereket, így gyakorlatilag minden weboldal lassan tölt be, ha betölt egyáltalán.Ennek egyik valós oka, hogy a protonnál lehet dinamikus bejövő portot kapni (kliensből), amit phishing kampányban is használnak elrejtőzésre. Emiatt a biztonsági cégek blokklistára teszik a szervereket.
Szóval eszközönként szelektíven érdemes használni és néhány oldalt kivételre tenni. Minél alacsonyabb egy programkód minősége vagy reklámokból / az adataidból csinálnak pénzt, annál inkább vpn vagy internet blokkolás jár neki. Pl Tizen platform, (kínai) “okos” otthon vackok, stb.
A biztonsághoz annyit, hogy az egész csak ipv4, a dns és az ipv6 szivárgás. Csupasz dns-sel semmi értelme, vagy a protonét vagy dns-over-https szervert használj.
Az ipv6-ot teljesen ki kell kapcsolni, mert a szolgáltatói dhcpv6 miatt kilátszanak az eszközeid és így direktben címezhetőek, megkerülve a vpn-t. -
Tamarel
senior tag
-
Tamarel
senior tag
válasz
Fleto93 #20271 üzenetére
Előljáróban: nálam hasonló beállítás van, csak egyszerűbben, mert egy eszközön van minden:
- a guest egy darab wifi interface + dhcp server + tűzfal szabály (nem érheti el a lan subnet-et)
- kamera simán lan-on van (hogy legyen multicast), de az internetről le van tiltva egy access list + tűzfal szabállyal (a többi iot eszközzel együtt)Szóval nincs vlan, mert nem volt még rá igény.
Ez egy jó leírás: https://help.mikrotik.com/docs/display/ROS/VLAN
Szóval nálad még mindig zavarosak a portok:
- tagged a vlan a "trunk" portokon, vagyis ha többnek is el kell jutni oda (hálózati eszközök, nas)
- a számítógépek és telefonok meg csak egy vlanban + untagged beállítás, valamint a vlan-ok között routingEzzel tudod szabályozni a (layer 2) broadcast domain méretét, pl ha a kamerákat közvetlenül nem, csak a szerveren keresztül szeretnéd elérni vagy a mobil eszközökre minimalizálni a forgalmat akku-takarékossági megfontolásból.
-
Tamarel
senior tag
válasz
Fleto93 #20263 üzenetére
Első ránézésre a bridge beállításnál van keveredés, a tagged és untagged beállítás a portokra.
A tag ugye az ip csomagra kerülő kiegészítő információ, ami akkor szükséges, ha a fogadó oldalnak csinálnia kell vele valamit. Pl bonding-switch felé.
A végponti eszközöknél van, hogy gondot okoz, van, hogy nem. Jellemzően nem küldjük ki.A másik zavar, hogy mindhárom vlan rá van engedve a router sima portjaira (6-7-8-10), amitől mit is vársz?
Az adott számítógép kezelje maga a vlan-okat (tagged) és legyen mindegyikben ip címe vagy össze legyen mosva a három (untagged) és csak simán több ip címe legyen, kiszámíthatatlan forgalmazással?A szép, bármekkorára méretezhető felépítés az, hogy egy végpont csak egy vlan-ban van és az átjárást a router oldja meg.
(Ez általános, gyártó-független hálózati kérdés.)
Nézem a leírást is hamarosan.
-
Tamarel
senior tag
válasz
Pille99 #20236 üzenetére
A vlan nem vészesen bonyolult.
Alapértelmezetten minden vlan 1 és untagged, vagyis ha egy csomagon nincs jelölés, akkor 1-nek számít.
Ha megcsinálod a 44-est, akkor a végponti eszközök portjain jó volt a 44 + untagged beállítás, de a trunk / uplink is member kell legyen (az összes vlan-ban) és (az 1esen kívül mindegyik) tagged. Gyakorlatilag egy új, logikai ábrát rajzolhatsz vlan 44-re.Ha jól értem guest az ok, ami:
- egy eszközön belül egyszerű, a subnet és a dhcp közvetlenül hozzárendelhető a porthoz / wifihez (a fő tűzfal szabálya, hogy semmit nem érhet el a lan / vlan 1-ben)
- a külön switch esetén a porthoz
- vlan esetén viszont a vlan interface-hez és az egész hálózatban kézzel adod meg, hogy melyik eszközre jut el (trunk) és azon belül melyik portra / interface-re -
Tamarel
senior tag
Azt nem említetted, hogy kintről szeretnél dhcp-t osztani. Persze teljesen helyi ip cím mentesen is lehet (vxlan, eoip, zerotier), de akkor teljesítményt áldozol fel. Az ac2 eleve max 250-280 Mbps-t tud wireguard-on, ezt csökkented tovább minden egyébbel.
Plusz behozod a broadcast domain témát (amit minimalizálni kellene a wifi kliensek alvó állapota / akkumulátora miatt).Én inkább a sima, egyszerű routing-ra szavaznék:
- a fő routing táblára szükséged van, mert amúgy a forgalomnak (wireguard tunnel) mennie kell normálisan
- a routing rule tereli a forgalmat a wireguard tábla szabályai felé (szintén layer 3)
- interface list: attól függ hol tűzfalazol -
Tamarel
senior tag
https://forum.mikrotik.com/viewtopic.php?p=906311#p906311
A lényeg (példa):
/routing table
add disabled=no fib name=wireguard-xyz
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=wireguard-xyz pref-src="" routing-table=wireguard-xyz suppress-hw-offload=no
add disabled=no dst-address=192.168.0.0/24 gateway=lan-bridge routing-table=wireguard-xyz suppress-hw-offload=no
/routing rule
add action=lookup disabled=no src-address=192.168.0.0/24 table=wireguard-xyz
Az egyebeket már gondolom intézted:
- ha a cél dinamikus, akkor script-el wireguard interface ip frissítése
- tűzfal szabályok
- wireguard WAN-ba rakása (interface list) -
Tamarel
senior tag
Dns / ip felé keresgélnék.
Dinamikus ipv4-es végpontokon scripttel íratom be a wg interface-be a feloldott ip-t 10 percenként, a két vége között 5 perc eltolással.Talán elég egy oldali helyes ip a kapcsolat felépüléséhez (ha épp van ilyen irányú forgalom), de biztos, hogy nem mindig. Ilyenkor ki kell várni a 10 percet.
A lényeg, hogy mindig feljön magától.Mindkettőn van “betárcsázó” kliens (telefon), azokra nincs script. Ha leszakad, akkor marad a kézi megoldás.
-
Tamarel
senior tag
válasz
Dartimperial #19416 üzenetére
Logikailag routing-al megoldható.
Ip / routes
A dinamikus default route helyett kézzel berakni kettőt:
- 0.0.0.0/0
- gateway: %pppoe-out1
- check gateway: bfd
- distance: az elsődlegesre 1, a másodlagosra 2 vagy (gondolom) load balance esetén mindkettő legyen azonosA másik ugyanez, csak a másik kijáratra. Lehet pppoe, ethernet, amit csak akarsz.
A várt eredmény: a default route akkor kerül be a routing táblába, ha a megadott gateway elérhető. Az ip címe mindegy.
Pl ha az elsődleges kiesik, akkor a következő csomag csak a másik irányba tud menni.Mivel ilyen formában nem teszteltem (csak vpn-be irányításként), lehetnek komplikációk:
- pppoe interface-n kikapcsolni az “add default route”-t (ami a dinamikus)
- a load balance-ben sem vagyok biztos, hogy ez csomagonként, session-onként csinálja-e, ip vagy mac alapján, esetleg mikor éppen hogy -
Tamarel
senior tag
válasz
jerry311 #19274 üzenetére
Szerintem nagy cégnél belül privát ipv4 van, szóval ott a nat alap. Mintahogy szervercserénél is kellhet a nat és a több szolgáltató esetén is.
Ipv6-nál szerintem szintén privát tartomány lehet a jó irány, de a kijárat megoldása nem annyira egyértelmű. Gondolom vagy prefix csere-bere vagy proxy.
Az ebből egy eszközre egyszerűsített logikai megoldás a kérdés.Ha a szolgáltatói ipv6 címet leengeded az eszközeidre és egy belső másolás épp azzal megy, akkor az internet / ipv6 cím eltűnése megszakítja a kapcsolatot. Láttam, kösz nem kérem.
-
Tamarel
senior tag
válasz
lionhearted #19262 üzenetére
- csupasz sebesség 941 Mbps
- wireguard 830 Mbps
- speed.cloudflare.com 882 MbpsConnected via IPv6
Server location: Budapest
Your network: Digi TV (AS20845)
Your IP address: -
Tamarel
senior tag
válasz
lionhearted #19262 üzenetére
Nem tudok ipv6os vpn szolgáltatóról.
-
Tamarel
senior tag
válasz
paradison #18687 üzenetére
Sziasztok.
Nem értem a javaslatok egy részét:
- miért kell(ene) mangle szabály? nálam nincs, mégis wg felé megy a forgalom
- a killswitch is feleslegesnek tűnik, alapból úgy viselkedett, épp hogy külön kellett biztosítanom a kimenő forgalmat, amikor napokig nem volt elérhető a szerver
- a fasttrack-et miért kell(ene) törölni?
- mss-hez se nyúltam, de ez most kb mellékes -
Tamarel
senior tag
válasz
E.Kaufmann #18659 üzenetére
Az biztos, hogy valami érdekesség van.
Nem eszköz specifikus a wave2 csomag (arm64), de anélkül semmilyen wifi nincs. -
Tamarel
senior tag
válasz
Tamarel #18616 üzenetére
Ez a mérés kábelen történt és úgy tűnik alacsony szerverterhelés mellett. Wifin 350 körül mértem elsőre, de pl nem is bogarásztam ki melyik speedtest szerver a gyors.
Egyedüli fennakadás a wifi wave2-vel van, az egyik “okos” eszköz nem látja, teljesen lebutítva sem (2.4Ghz, n, wpa2).
-
Tamarel
senior tag
válasz
yodee_ #18617 üzenetére
senetic.hu, 57 ezer
4 darab volt csak, amikor megláttam. Az oldal keresője sem listázta, direkt linkkel mentem.
https://www.senetic.hu/product/C53UIG+5HPAXD2HPAXDLengyelországból hozta a dpd, magyar a számla. 2 év gari.
-
Tamarel
senior tag
Wireguard sebesség-teszt:
- ac2: 260Mbps körül van a maximuma
- ax3: 600Mbps körüli első méréseket produkáltUgyanazok a körülmények és a beállítás (vpn szolgáltató, digi 1000/300, speedtest).
-
Tamarel
senior tag
-
Tamarel
senior tag
válasz
szuszinho #18308 üzenetére
Ez alapján meg tudod csinálni:
https://forum.mikrotik.com/viewtopic.php?p=920105/routing table add fib name=use-WG
/routing rule add src-address=<helyi subnet> action=lookup-only-in-table table=use-WG
/ip route
dst-address=0.0.0.0/0 gwy=%wg-interface-name table=use-WGPlusz még egy ip route, hogy a local subnet %bridge-re menjen a wireguard helyett.
Ez a fapados része, lehet még variálni: dns, check gateway / netwatch.
-
Tamarel
senior tag
válasz
lionhearted #18303 üzenetére
Láttatok valahol ax2 wireguard teljesítmény-értékeket?
-
Tamarel
senior tag
Asusról váltottam, ott 2x2 ac 550-600, 2x2 ax router ac klienssel 650-700 volt, a tiszta 2x2 ax pedig kb 800Mpbs-t ért el. Laptoppal tesztelve.
Itt majd kiderül, a szoftverfrissítésre és beállításokra gondolok.
Ha ez igazat mond, akkor DL MU-MIMO 2 kliensre, az OFDMA 8ra működik. Az otthonra azért erős, a 2.4Ghz-el együtt elvileg ki tudna osztani egy teljes 2.5ös netet wifire.
http://www.bitswrt.com/nhx6018.html -
Tamarel
senior tag
Kapható az ax2 (magyar garanciával).
-
Tamarel
senior tag
Érdekes ez az IPQ 6010 (hap ax2), a mikrotik.com-ra kitett specifikációk szerint a tesztekben 25%kal lassabb, mint az IPQ 4018 (hap ac2).
Az új ax-es Chateau-ban is ugyanez van.Mi a trükk?
-
Tamarel
senior tag
válasz
Mr Dini #17819 üzenetére
Másodlagos route táblával a forrás ip tartományt teljes egészében wireguard-ba irányítani?
https://forum.mikrotik.com/viewtopic.php?p=906311#p906311
Új hozzászólás Aktív témák
Hirdetés
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 7600XT 16GB GAMER PC termékbeszámítással
- Dell USB-C, Thunderbolt 3, TB3, TB4 dokkolók (K20A) WD19TB/ WD19TBS/ WD22TB4, (K16A) TB16/ TB18DC
- BESZÁMÍTÁS! Intel Core i7 8700K 6 mag 12 szál processzor garanciával hibátlan működéssel
- DELL T40 EMC Szerver
- AKCIÓ! MSI Z790 i5 14600KF 64GB DDR5 512GB SSD RTX 3070 8GB Rampage SHIVA Enermax 750W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest