Az UDP nem mindig gyorsabb: az OpenVPN-átvitel kiválasztása

Minden útmutató azt mondja, hogy az UDP jobb a TCP-nél OpenVPN-hez, és ez a tanács alapértelmezés, nem mérés. Az átvitel azt változtatja meg, hogyan kézbesítik a csomagokat és mi történik, amikor az útvonal eldobja őket, nem pedig azt, hogyan titkosítják az alagutat. Egy captive portal vagy egy csak a 443-as portot engedélyező proxy mögött a lassabb lehetőség az, amely egyáltalán csatlakozik. A következők elválasztják, mit tesz a protokoll, attól, mit engedélyez a hozzáférési hálózata.

Mit változtat meg valójában az átvitel

A TCP megbízható, sorrendben érkező bájtfolyamot biztosít, és újraküld mindent, ami elveszik, ahogy a RFC 9293 előírja. Az UDP datagramokat ad át a hálózatnak, és az OpenVPN a saját megbízhatósági rétegét futtatja ezen a socketen. A TCP TCP-be ágyazása két helyreállítási hurkot halmoz egymásra, így egyetlen elveszett szegmens is visszatarthatja a belső folyamot, amíg a külső újraküldés meg nem érkezik. Ez a kölcsönhatás az igazi érv az UDP mellett, és késleltetésként, nem pedig átbocsátásként jelentkezik.

A hatás a veszteséggel és az oda-vissza idővel nő. Tiszta helyi útvonalon mindkét átvitel azonosnak érződik, ezért egy laboratóriumi teszt ritkán reprodukálja a panaszt. Egy túlterhelt mobil kapcsolaton a különbség interaktív munkamenetekben jóval azelőtt látszik, hogy egy nagy átvitel bármit észlelne.

Ezek egyike sem érinti a bizalmasságot vagy a sértetlenséget. A TLS-kézfogás és az adatcsatorna-rejtjel ugyanaz mindkét átvitelnél, így a váltás nem menthet meg egy gyenge rejtjelkészletet.

Ahol a TCP kiérdemli a helyét

A hozzáférési hálózatok a szokásos ok a TCP választására. Egy hotel, repülőtér vagy vendéghálózat engedélyezheti a kimenő 443-at és eldobhat minden mást, és az azon a porton futó TCP-figyelő az egyetlen működő profil. Ez elérhetőség, nem teljesítmény, és önmagában is elég jó ok.

A TCP akkor is segít, amikor az útvonal stabil, de a köztes eszközök ellenségesek. Egyes hálózatok visszaállítják a hosszú életű UDP-folyamokat, miközben elviselik a közönséges webtraffichez hasonló TCP-munkameneteket. Hogy ez a hasonlóság sikerül-e, az adott hálózat tulajdonsága, és egyetlen útmutató sem ígérheti mindegyikük nevében. Teszteljen abban a hálózatban, amelyik meghibásodik, mielőtt a protokollt okolná.

Egy elutasított bejelentkezés nem átviteli probléma. A tanúsítvány-ellenőrzés kikapcsolása a kapcsolat erőltetéséhez más változtatás, sokkal rosszabb eredménnyel.

A kész TCP-profil tartása a gyakorlati kompromisszum. A legtöbb kliens mindkettőt tárolja, és engedi a váltást, amikor egy hálózat elutasítja az UDP-útvonalat, ami semmibe sem kerül, amíg szükség nem lesz rá. Amit nem szabad tenni, az két különböző végpontra mutató profil szállítása, mert akkor az összehasonlítás a szervereket méri.

Ellenőrizze, melyik figyelője van valójában

A teljesítmény összehasonlítása előtt erősítse meg, hogy mindkét vég egyetért az átvitelben és a portban. A proto udp proto tcp-ra módosítása egy kliensfájlban nem hoz létre szerveroldali figyelőt. A szervert erre a protokollra kell beállítani, és a profilnak illeszkednie kell hozzá.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

A grep kiírja, mit mondtak a szervernek, hogy használjon, míg a két socketlista megmutatja, mihez van kötve. Az UDP-figyelő csak az első listában, a TCP-figyelő csak a másodikban jelenik meg, így a hiányzó sor a leggyorsabb módja egy soha nem alkalmazott profil megtalálásának. Hasonlítsa össze a portot is, mert az 1194-es TCP-profil a legtöbb hozzáférési hálózatban másként viselkedik, mint a 443-as. A módosítás után indítsa újra a szolgáltatást, és olvassa el a kötést jelentő naplósort.

Az ügyféloldali megerősítés olcsó: futtassa a kapcsolatot --verb 4-mal, és olvassa el az átviteli sort a naplóban. Ha az ügyfél UDP-t mond, miközben a szerver TCP-n figyel, a kézfogás soha nem indul el, és semmilyen hangolás nem segít.

A munkaterhelést hasonlítsa össze, ne az átvitel címkéjét

A tisztességes összehasonlítás mindent állandóan tart az átvitel kivételével. Ugyanaz az eszköz, ugyanaz a hozzáférési hálózat, ugyanaz a célgazda, ugyanaz az alkalmazás és ideális esetben ugyanaz a szerver. Ha a két profil különböző gazdákra mutat, akkor azokat a gazdákat is méri.

Rögzítsen három eredményt minden futáshoz: létrejön-e az alagút, fennmarad-e, és befejeződik-e a feladat. A kis kérések, amelyek működnek, miközben a nagy átvitelek elakadnak, a csomagméretre és az MTU-ra utalnak, nem az átvitelre. Az ismételt újracsatlakozások az útvonalra vagy egy köztes eszköz időtúllépésére utalnak.

Tartsa meg a profilt, amely a ténylegesen előforduló körülmények között működik, és mentse el a másikat. A választás a hálózaté, nem a személyé, ezért minden egyetlen alapértelmezett válasz valahol hibás.