VPN 1500MTU with fragmentation

Hálózatok általános

Üdv!

 

Olyan feladatot kaptam, hogy egy hálózaton át kellene vinnem 1500byte-os csomagokat VPN-en. Mikrotik EoIP, tudja ezt, működik is, csak eszméletlen rossz az átvitt sávszélesség abban az esetben, ha ténylegesen darabolnia kell a csomagokat.

Laborban tesztelve működik, valós környezetben, ahol nem <1ms, hanem 10-20ms a ping válaszideje, a valós sávszélesség alig 3-5%-t képes átvinni.

Mikrotik CCR2004-essel teszteltem, 500/500-as kapcsolat esetén 10-30Mbit-et lehet átvinni 1500-as csomagokkal. Ugyan ezen beállítással, 1400-as csomagoknál átmegy az eredeti sávszélesség ~80%-a. Miért lehet ekkora különbség a két érték között? Lehet valahogy finomhangolni az EoIP-t, hogy ne legyen ennyire érzékeny a válaszidőre?

 

2 laptoppal, OpenVPN-el tesztelve működik a dolog, de corei9-es CPU-k 1-1 magját 100%-ban kihajtva, ami nem túl jó megoldás, kevés olyan miniPC van, ami ezt a teljesítményt tudja 1 magon, ezért gondoltuk, hogy Mikrotik irányába lépünk. Sajnos OpenVPN userspace, emiatt ilyen nagy a gépigénye.

( wpeople v | 2021. 07. 13., k – 17:13 )

próbáld ki a Wireguard-ot RouterOS7-el, hátha.

A gond ott van, hogy 1500 byte-os MTU esetén a tunnel-mtu akkor lesz hatékony, ha ~1450 körüli értéknél nem nagyobb, egyébként minden (ennél nagyobb) frame-t két darabban küld. Nekem olyan 300mbps-t sikerült átvinni egyébként. ~6-10ms közötti "távolság" esetén. 4011-el.

Köszönöm! RouterOS7-et még nem próbáltam. Wireguard VPN-el kísérleteztem PC-n és ott jó volt.

Tudom, hogy mi a probléma, de nem indokolt, hogy ekkora válaszidőnél ennyire lecsökkenjen a sávszélesség. Ez a protokoll hiányossága/hibája. Attól, hogy ketté kell darabolni egy csomagot, még át lehetne vinni a sávszélesség 80%-át, de legrosszabb esetben is az ~50%-át. Az 5% nagyon kevés.

( godot v | 2021. 07. 13., k – 20:06 )

Szerkesztve: 2021. 07. 13., k – 20:22

PMTU discovery működik? Az icmp type3 code4 csomagok át vannak engedve mindenhol?

Az TCP MSS-t vagy a PMTU által felderített értékre kell állítani (clamp-to-pmtu), vagy fixen megmondani hogy az MSS mondjuk 1360 legyen ha  a PMTU-t nem lehet "megfixálni", mert mondjuk köztes eszközök ICMP blackhole-ok.

Persze connectionless kapcsolatokra (UDP) ez nem működik.

( SPYFF v | 2021. 07. 13., k – 22:00 )

Amit látsz nekem nem tűnik furcsának. TCP szegmentálás (felteszem TCP-vel esetleg UDP-vel mérsz) egy nagyságrenddel gyorsabb mint az IP fragmentálás. Márpedig ha a VPN 1500mtu-s akkor egy kis csücsök mindig kilóg majd ami miatt fragmentálni kell az IP csomagot. Ez a sebességcsökkenés szinte minden implementációnál így van, linux kernel stacknél, más stackeknél de ami nem célhardver ott fizikai routereknél is. A legjobb hogy keresel olyan megoldást ahol a legkisebb a sebességkülönbség. 

WireGuard szerintem gyorsabb lesz, kérdés hogy mennyire egyszerű menedzselni sok embernél, de szerintem már vannak egyszerűsített konfigok ehhez.

A feladat egy olyan VPN-t találni, ami nem lassul a válaszidő növekedésével. 

Ez alatt mit értesz? Szerintem ez inkább window probléma: ha kis ms RTT-nél okés, nagynál meg nem akkor:

1. lehet buffer probléma (erről írtam egy hosszú blogposztot korábban: https://hup.hu/node/167720)
2. TCP snd/rcv window probléma (nagy BDP-nél egy vagy kevés flow nem éri el a lehetséges max sávszélt)
3. CC probléma: Cubic helyett nézd meg egy BBR TCP küldővel, úgy mennyivel magasabb a sávszél.

Sima UDP tesztnél is jelentkezik  a sávszélesség csökkenése az eredeti hálózat válaszidejének növekedésével.

EoIP-nél:

1ms hálózaton az 1Gbites kapcsolatnál, szinte a teljes sávszélesség megmarad.

Most teszteltem 7ms-os kapcsolatnál, már csak a fele sávszélesség maradt meg.

12-14ms-nél már jó ha a 10-20%-a megmarad.

Ahogy fenn írtam, ez az 1500-as csomagméretre vonatkozik. Ha maradok a darabolás nélküli csomagméretnél, akkor megmarad a teljes sávszélesség.

 

Mikrotik 7.1beta + WireGuard VPN:

7ms-es hálózaton tesztelve szinte ugyan azt az eredményt hozza, mint az EoIP. Nagyon hasonló VPN, valószínűleg a mikrotik implementációja is hasonlóan oldja meg a kérdést.

 

Az OpenVPN-ben az tetszik, hogy egyáltalán nem érzékeny a csomagméretre. Az implementációja nem foglalkozik ezzel a kérdéssel. Gyűjti az adatokat és amint összejött az átvihető mennyiség, elküldi. Sok kis csomagnál konkrétan összevárja a kis csomagokat és egyben küldi el. Akár még gyorsíthat is a hálózaton emiatt. Korrekt modern megoldás, csak nem a sebesség volt a cél a tervezésnél és implementálásnál, ezért nagyon gépigényes. Linux kernel modult még nem próbáltam, fejlesztés alatt áll, de elvileg már kipróbálható lenne.

PC lenne a jó megoldás, de egyelőre nincs olyan eszközöm, amin linuxot tudnék futtatni és kellő teljesítményű (3-4GHz) a teszthez.

PC lenne a jó megoldás, de egyelőre nincs olyan eszközöm, amin linuxot tudnék futtatni és kellő teljesítményű (3-4GHz) a teszthez.

Nezd meg a PCEngines/APU(2) vonalat. Eleg jol adja a teljesitmeny, 3x gigabit fizikai ethernet, elegendo RAM, nincs benne mozgo alkatresz, keveset fogyaszt, full linux support, alapertelmezett hheadless mukodes, rutinszeru hasznalat 100% readonly filerendszerrel (egyszeruen megoldhato hogy bootup soran se legyen r/w semelyik mountpoint sem), kesobb is bovitheto a szep dobozoltsag megtartasa mellett (3x minipcix csatlakozo). Mi sokmindenre hasznaljuk - leginkabb beagyazott vezerles, szoval nem feltetlen fo halozati eszkozkent - de lenyegeben erre, azaz routerek, egyedi switchek es halozato pontok, wifi/gsm access pointok epitesere talaltak ki a hardvert. Azaz tkp arra ami neked is kell :)

Esetleg próbáld ki a softether-t tud olyat, hogy egy VPN kapcsolatot több TCP kapcsolatba szór szét, így nem bántja annyira a válaszidő növekedése. Jól használható cliens és szerver manager programjai is vannak igaz windowsra, de azzal is tudsz más oprendszeren levő szervert állítgatni. A cli beállítás sem vészes.

( apal v | 2021. 07. 14., sze – 01:14 )

Ha nagyon egyedi es specifikus a problemad, akkor sajat implementacion is elgondolkodhatsz - pl linux-linux kozott a /dev/net/tun megnyitasa, es ugy stream-eled at a ket vegpont kozott ahogy a problemara az epp' optimalis. Ez raadasul layer2, szoval megtobb szabadsagod lesz a kesobbiekben. Igen, ez userspace, de nem biztos hogy az openvpn-nel a networking overhead miatt porog a processzor, lehet hogy a titkositas vagy egyeb nyalanksagok miatt. 

A `socat`-tal is meg tudod ezt csinalni, annak van beepitett TUN uzemmodja (szinten /dev/net/tun alapokon). Pelda: https://www.cybrary.it/blog/0p3n/creating-ssl-vpn-socat/. 

egyetértek. én első körben kihagynám a Mikrotik-et mint VPN-t a dologból, és mindkét végére odatennék 1 PC-t, amin tudod a tisztességes implementációját tesztelni a WireGuard-nak és OpenVPN-nek.
HA ez már jó, na akkor lehet esetleg visszamenni Mikrotik-re.

Mikrotik-nek a PChez képest nagy előnye a mérete és fogyasztása - viszont a beépített AES gyorsító emlékeim szerint csak IPSec-et gyorsít - ellenben a CPU-ban lévő AES utasításkészletet képes lehet az OpenVPN és WireGuard is kihasználni.
A mikrotik 10-20W fogyasztással elkocog - a géped pedig ~60-120W-t fog enni.

Én ehhez annyit fűznék hozzá, hogy én RPi3-mal is próbáltam Wireguard-ot (erős PC-n és gyenge Mikrotik RB750G-n kívül), és ott olyan 40-60% CPU terhelés mellett (erősen változó volt) ment 98 MBit mindkét irányba, mert az RPi3 a gagyi USB2-es Ethernet csatolóján ennyit tud, ott hardver limites a hálózata. Sajna RPi3B nem volt otthon akkor épp, ami elvileg 300 Mbit-et tud Eth-n. Az egész teszetet azért kezdtem, mert a neten azt olvastam RPi4-gyel, Wireguard-dal sok száz Mbit átmegy, annak rendes 1 GbE a hálózata, ami át is megy rajta, és kellene egy "maszek" helyre olcsó, kicsi, keveset fogyasztó gyors VPN kapcsolat (sajna az IPsec kiesett, a Digi egy ideje csinált valamit a lakossági neten, és max. 25 MBit megy át IPsec-en akármit csinálunk vele).

De az RB750G is hozta 7.1beta5-tel a 100 Mbit körüli sebességet, de azt CPU limitesen. Viszont abban ugye egy régi és eléggé gyenge CPU van.

Szerintem emiatt érdemes a PC-s teszt után RPi4-gyel is futni egy kört, mert az ugyan már nem ultra olcsó mint a régiek, viszont irtó keveset fogyaszt egy bármilyen PC-hez képest.

"sajna az IPsec kiesett, a Digi egy ideje csinált valamit a lakossági neten, és max. 25 MBit megy át IPsec-en akármit csinálunk vele"

Nekem van egy site2site vpn-m ipsec-en, és nekem olyan ~40mbit-el megy a gigás digi neten (mind2 oldal ugyanolyan gigás digi neten van, bp es miskolc).

Készítettem egy saját VPN megoldást, ami csökkenti az átvitt csomagok számát úgy, hogy egy ~1500-as csomagot nem 1450 + 50 méretű csomagban visz át, hanem mindig 1450-es csomagokat küld át UDP-n. Sajnos nem váltotta be a hozzá fűzött reményeket. Úgy látom, hogy a probléma nem a csomagok számából adódik, hanem valamilyen más, időzítés, buffer méret, RTT stb okozza a problémát. Ezt a részt már nem látom át, próbálkoztam változtatni a linux tcp, udp buffer méreteken és komoly sávszélesség csökkenéseket sikerült is elérnem vele, növelést sajnos egyáltalán nem. A gyári beállítás bizonyult a legjobbnak. Valószínűleg teljesen rossz irányba indultam el.

Tud segíteni ebben valaki?

( secretx v | 2021. 08. 15., v – 09:51 )

Fasttrack be van kapcsolva? Érdemes lehet tenni egy próbát kikapcsolva..

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"