Sziasztok!
Csak ötletben / tippben kérnék, egy kis útmutatást, a megoldást vagy magam megkeresem vagy megköszönöm nektek.
Adott két mikrotik egy Hap Ax3 (arm64) és egy hex reflesh (arm)-os.
https://mikrotik.com/product/hex_2024
A probléma a következő:
Ugyanazok a beállítások mtu, ipsec titkosítás (aes-cbc, aes-gcm)
Egy dolog a különbség, az ipsec policyban a Transfer vagy a Tunnel átvitel.
Az eredmény siralmas. 100Mbit kontra 5Mbit, szinte teljesen mindegy milyen titkosítást használok hasonló az arány.
Az 5Mbit néha "csak" 20kbps-en ragad egy nagyméretű ftp fájlmásolás alatt. Teljesen mindegy, hogy a tunnel ipip, gre vagy eoip. Csökkentett mtuval, pl.: 1300-ra is ugyanez a helyzet.
Cpu terén 100Mbitnél is maximum 50%-on van, 5Mbitnél kb 1-5%.
Kérlek ne azt mondjátok, hogy menjek wireguard, zerotier irányba, hanem a Mikrotik Expertektől kérdezném, mi felett siklottam el, hogy tunnel módban ilyen siralmas a helyzetem.
Segítségeteket előre is köszönöm.
Config:
Update:
Van clamp tcp mss a tunnelen és van mangle szabály is:
chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface-list=Tunnels tcp-mss=1419-65535 log=yes log-prefix="ChangeMSS"
- 1191 megtekintés
Hozzászólások
Mikrotik Guruk please help! NAT-T engedélyezve.
- A hozzászóláshoz be kell jelentkezni
A leírás alapján nem biztos, hogy mikrotik specifikus probléma, inkább fragmentation problémák tűnik, hiszen Tunnel módban kisebb payload fér bele és ezt még megfejeled azzal is, hogy UDP encapsulation is van a nat traversal miatt. Nem lehet, hogy valami nem stimmel a PMTU discoveryvel? Hol állítottad az MTU-t?
ui: biztos kell NAT-T? Ha tudsz állítani egy one-on-one NAT-ot, akkor az ESP csomagok is betalálnak a helyükre és akkor ki tudnád kapcsolni.
- A hozzászóláshoz be kell jelentkezni
Magán a Gre / IPIP tunnelen.
- A hozzászóláshoz be kell jelentkezni
Mangle alatt próbálj clamp-ot mindkét oldalon a túloldal felé. Esetleg fasttrack nem zavar be valami szabályba? Azt is kikapcsolnám tűzfalon.
Színes vászon, színes vászon, fúj!
Kérem a Fiátot..
- A hozzászóláshoz be kell jelentkezni
Szerintem is fragmentation probléma, én GRE nélkül próbálnám IKEv2-vel. Itt van leírva hogy kell: https://help.mikrotik.com/docs/spaces/ROS/pages/11993097/IPsec#IPsec-Si…
- A hozzászóláshoz be kell jelentkezni
Default beállítás a tunneleken a clamp tcp mss, illetve a fastpath is csak kikapcsolva lehet ipsec mellett.
Mangle is van clamp to pmtu-val, icmp engedélyezve ehhez a configban.
chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface-list=Tunnels tcp-mss=1419-65535 log=yes log-prefix="ChangeMSS"
- A hozzászóláshoz be kell jelentkezni
Most látom ezt a new-mss=clam-to-pmtu beállítást. Biztos jó ez? 1400as MSS az lehet hogy nagy lesz. Kipróbálok mondjuk "new-mss=1360"-al?
- A hozzászóláshoz be kell jelentkezni
A config:
- A hozzászóláshoz be kell jelentkezni
1. Nézz meg egy routeros 6-ot, hátha valami újabb csodás bug a 7-esbe
2. Nézd meg pl. openvpn-nel. Amúgy miért kell ipsec?
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Tippre a hw gyorsítás miatt, mert egy (ma már csoffadt) 750Gr3 is tud ilyet és gyorsabb is, mint bármilyen más VPN megoldás, de ha ennyire nem jön össze, akkor egy próbát megér, v7-en a Wireguard pláne.
Színes vászon, színes vászon, fúj!
Kérem a Fiátot..
- A hozzászóláshoz be kell jelentkezni
Igaz, OP írta, hogy ipsec only-t vár, de valóban, v7-en a 750Gr3 wireguard-dal kb. tud annyit átvinni, mint a hardveres ipsec-kel. És nem kell így szívni mint most, hanem 3 perc beállítani...
- A hozzászóláshoz be kell jelentkezni
Tunnel és Transfer módban is van H flag azaz gyorsított, amennyiben aes-cbc a titkosítás mert támogatott. A transfer mód esetén csak részben titkosított, azaz a fejlécek nem, de akkor se kéne 20x vagy nagyobb arányú eltérésnek lennie.
- A hozzászóláshoz be kell jelentkezni
Mikrotik oldalon az van hogy hex reflesh -ben nincs hw gyorsitás,
- A hozzászóláshoz be kell jelentkezni
Nem tudom hol nézted, de
https://mikrotik.com/product/hex_2024#fndtn-specifications
IPsec hardware acceleration | Yes |
Illetve
https://help.mikrotik.com/docs/spaces/ROS/pages/11993097/IPsec#IPsec-Ha…
EN7562CT sort kell nézni, mert az a chipset van benne.
- A hozzászóláshoz be kell jelentkezni
IPsec "installed sa" fülön webfigben látsz H betüt. Hardware gyorsítást ?
UI:
Az egyik mikrotikedben nincs hw gyorsitás, és ha van valamelyik oldalon egy gyenge upload, akkor az korlát lesz.
Nálam upload egyik oldalon 20 Mbit, ipsec sebessége 20 Mbit/sec, Másik irányba jobb ott 50-100 Mbit/sec. Mindketto hw-es mikrotik.
Ping paranccsal a ki tudod deriteni a csomagméretet, ping ne fragmentáljon, és kezd csökkenteni a csomagméretet. Van pár kész kis script erre.
- A hozzászóláshoz be kell jelentkezni
Fentebb:
- A hozzászóláshoz be kell jelentkezni
Szerintem is MTU probléma lesz és/vagy valamelyik oldal mégsem használja a HW IPsec gyorsítást. IPsec NAT-T GRE tunnellel kapásból szép kis overhead (kb. 92 byte IPv4 címzés esetén).
Én is úgy próbálnám, hogy leveszem a tunnel MTU-t mondjuk 1200-ra, és mérek, majd emelem addig, amíg be nem konyul a sebesség.
- A hozzászóláshoz be kell jelentkezni
Fentebb írtam, hogy próbáltam. Csökkentetem 1300-ra, ami már mindenre is elég kellett volna hogy legyen.
- A hozzászóláshoz be kell jelentkezni
Fentebb írtam, hogy próbáltam. Csökkentetem 1300-ra, ami már mindenre is elég kellett volna hogy legyen.
Kipróbáltad ???
És miért is elég az 1300, elég mert az szerencseszám ? Na ahol nem elég:
C:\Users\vasla>tracert 172.16.3.100
Tracing route to 172.16.3.100 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 192.168.4.3
2 * * * Request timed out.
3 15 ms 13 ms 14 ms 172.16.3.100
Trace complete.
C:\Users\vasla>ping -f -l 1300 172.16.3.100
Pinging 172.16.3.100 with 1300 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 172.16.3.100:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\vasla>ping -f -l 1200 172.16.3.100
Pinging 172.16.3.100 with 1200 bytes of data:
Reply from 172.16.3.100: bytes=1200 time=39ms TTL=253
Reply from 172.16.3.100: bytes=1200 time=15ms TTL=253
Reply from 172.16.3.100: bytes=1200 time=15ms TTL=253
Reply from 172.16.3.100: bytes=1200 time=21ms TTL=253
Ping statistics for 172.16.3.100:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 39ms, Average = 22ms
- A hozzászóláshoz be kell jelentkezni
Belső hálon ok az 1500 MTU, interneten meg nagy.
- A hozzászóláshoz be kell jelentkezni
Arra értettem, ahol 1 tunnel van mondjuk közepes titkosítással (IPv4-en), és nem pedig a tunnel a tunnelben jellegűek...
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy ez az "1 tunnel van" dolog ez csak egy high level elnevezés. Alapvetően ha NAT-T-vel használsz ipsec-et, akkor már dupla encapsulation van, egyszer ESP aztán pedig UDP. Egy "tunnel" az nem más mint egy vagy több encpasulation a valódi csomag előtt amit el akarsz küldeni. Minden encapsulation csökkenti a "valós" csomagméretet.
- A hozzászóláshoz be kell jelentkezni
1400-as mtu-val
ecsi@vm1:~$ ping -M do -s 1372 192.168.80.200
PING 192.168.80.200 (192.168.80.200) 1372(1400) bytes of data.
1380 bytes from 192.168.80.200: icmp_seq=1 ttl=62 time=13.4 ms
1380 bytes from 192.168.80.200: icmp_seq=2 ttl=62 time=11.0 ms
1380 bytes from 192.168.80.200: icmp_seq=3 ttl=62 time=11.0 ms
^C
--- 192.168.80.200 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 10.955/11.767/13.370/1.133 ms
ecsi@vm1:~$ ping -M do -s 1373 192.168.80.200
PING 192.168.80.200 (192.168.80.200) 1373(1401) bytes of data.
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
^C
--- 192.168.80.200 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2037ms
ecsi@vm1:~$
- A hozzászóláshoz be kell jelentkezni
tracepath 192.168.80.200 mit ir ki PMTU-ra?
- A hozzászóláshoz be kell jelentkezni
ecsi@vm1:~$ tracepath 192.168.80.200
1?: [LOCALHOST] pmtu 1500
1: _gateway 2.497ms
1: _gateway 2.711ms
2: 192.168.0.254 4.692ms pmtu 1400
3: 192.168.80.200 16.345ms reached
Resume: pmtu 1400 hops 3 back 3
ecsi@vm1:~$
- A hozzászóláshoz be kell jelentkezni
Nyilván nem látom át a rendszeredet, de az látszik, hogy az MTU 1400, és az 1372 byteos icmp még átfér (1372+8 UDP +20 IP header). Én azt gyanítom, hogy nagyon a határon van a segment size, és az ESP header méretének változása miatt van amikor átmegy a csomag, van amikor nem (inkább nem) és ebből lesz a brutális lassulás. Az is jó kérdés, hogy éppen melyik hopon történik meg a fragmentálás, nekem volt egy érdekes issuem korábban amikor éppen az MTU növelése oldotta meg a problémát. Anno kiszámolgattam hogy mi és miért történt, de akárhogy próbálok, nem emlékszem vissza rá, pedig érdekes volt.
Arra emlékszem, hogy nagyon alacsony MTU-val (1300 vagy 1200) működött szépen, és volt egy range azt hiszem 1400 és 1420 között amikor nem működött. A teszt kedvéért próbáld feljebb tolni az MTU-t
- A hozzászóláshoz be kell jelentkezni
Nálam mostanra a wireguard kapcsolatok mennek 1300-on, aminél valamivel kevesebb az overhead (60 byte IPv4, 80 byte IPv6). Tapasztalatom szerint 1300 feletti tunnel MTU esetén nem minden túloldalon működik nem minden szolgáltatás elérése.
Én sem szoktam pontosan kiszámolni, méregeni kapcsolatonként, meg pláne nem szoktam PMTU-t nézegetni. Csak tapasztalati alapon erre jutottam, és sehol sem célzom meg az elméleti max. sávszélt, inkább biztosra megyek az elérhetőnél valószínű alacsonyabb MTU-val.
Ha 1300-zal is ugyan olyan lassú, attól még egy 1300 alatti (pl. 1280, ami az IPv6 min. MTU) próba nem árthat. Max. nem lesz jobb, és megtudod, tuti nem az MTU a probléma.
- A hozzászóláshoz be kell jelentkezni
1200-vel is detto.
- A hozzászóláshoz be kell jelentkezni
"meg pláne nem szoktam PMTU-t nézegetni"
erre van a clamp tcp mss a tunnelen illetve lehet tenni mangle clamp to pmtu szabályt.
- A hozzászóláshoz be kell jelentkezni
Ezek a tesztek jutottak eszembe:
1) Meg tudnád próbálni, hogy teljesen kikapcsolod a fasttrackot a mikrotikeken és újraindítotod mindekőt.
Nézd meg kikapcsolt fasttrack és újraindítás után milyen sebességeid vannak.
2) Ha GRE nélkül csak natív IPSEC-cel húzod össze akkor is hasonló eredményeid vannak?
3) Tudod esetleg SCP-vel is tesztelni a történetet?
4) aes-gcm ről menj le aes-256 cbc re. Nekem a minap volt olyan problémám ( bár az régebbi 7-es vol) hogy összeállt a tunnel PH1 és PH2 is, látszólag bele is ment a forgalom, de a másik végén nem jött ki. Bár ott a túloldalt nem mikrotik volt.
- A hozzászóláshoz be kell jelentkezni
Minden layeren (publikus IP, gre, ipsec) ki kell mérni a sávszélességet btest-el. Azon belül lehet irányonként is mérni ill. tcp-t vagy udp-t is használni. Amint látod, hogy melyik layeren veszik el a sebesség, sokkal okosabb leszel.
https://help.mikrotik.com/docs/spaces/ROS/pages/7962644/Bandwidth+Test
- A hozzászóláshoz be kell jelentkezni