UDP is net altyd flugger: de OpenVPN-transport kieze

Elke gids seit dat UDP better is as TCP foar OpenVPN, en dy rie is in standert, gjin mjitting. De transport feroaret hoe't pakketten ôflevere wurde en wat der bart as it paad se ferdwynt, net hoe't de tunnel fersifere wurdt. Efter in captive portal of in proxy dy't allinnich poarte 443 talit, is de stadiger opsje dejinge dy't hielendal ferbynt. Wat folget skiedt wat it protokol docht fan wat dyn tagongsnetwurk talit.

Wat de transport eins feroaret

TCP leveret in betroubere, oardere bytestream en stjoert alles opnij dat ferlern giet, sa't RFC 9293 bepaalt. UDP jout datagrammen oan it netwurk, en OpenVPN draait syn eigen betrouberenslaach oer dy socket. TCP yn TCP kapselje steapelt twa herstelslûzen, sadat ien ferlern segmint de binnenstream tsjinhâlde kin oant de bûtenste werhelling oankomt. Dy wikselwurking is it echte argumint foar UDP, en it docht bliken as fertraging ynstee fan trochstreaming.

It effekt groeit mei ferlies en hinne-en-wer-tiid. Op in skjin lokaal paad fiele beide transporten identyk, dêrom makket in laboratoariumtest de klacht selden opnij. Op in oerlêst mobyl ferbining docht it ferskil him foar yn ynteraktive sesjes lang foar't in grutte oerdracht eat merkt.

Neat hjirfan rekket fertroulikens of yntegriteit. De TLS-hânskodding en de daadkanaal-sifer binne itselde foar beide transporten, dus omskeakelje kin in swak siferpakket net rêde.

Wêr't TCP syn plak fertsjinnet

Tagongsnetwurken binne de gewoane reden om TCP te kiezen. In hotel, in fleanfjild of in gastenetwurk mei útgeand 443 talitte en al it oare falle litte, en in TCP-lister op dy poarte is it ienige profyl dat wurket. Dat is berikberens, net prestaasje, en it is op himsels in goed genôch reden.

TCP helpt ek as it paad stabyl is, mar de middenbakken fijannich binne. Guon netwurken resetten langduorjende UDP-streamen wylst se TCP-sesjes tolerearje dy't op gewoan webforkear lykje. Oft dy likenis slagget, is in eigenskip fan it konkrete netwurk, en gjin gids kin it foar alle netwurken tasizze. Test binnen it netwurk dat mislearret foar't jo it protokol de skuld jouwe.

In ôfwiisd oanmelding is gjin transportprobleem. Sertifikaatferifikaasje út sette om in ferbining troch te twingen is in oare feroaring mei in folle slimmer útkomst.

In TCP-profyl klear hâlde is it praktyske kompromis. De measte kliïnten bewarje beide en litte jo omskeakelje as in netwurk it UDP-paad wegeret, wat neat kostet oant jo it nedich hawwe. Wat jo net dwaan moatte, is twa profilen leverje dy't nei ferskillende einpunten wize, want dan mjit jo ferliking de servers.

Kontrolearje hokker lister jo echt hawwe

Foar't jo prestaasje ferlykje, befêstigje dat beide kanten it iens binne oer de transport en de poarte. proto udp feroarje yn proto tcp yn in kliïntbestân makket gjin serverlister. De server moat foar dat protokol konfigurearre wêze, en it profyl moat dêrmei oerienkomme.

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

grep print wat de server sein is te brûken, wylst de twa socketlisten sjen litte wêr't it oan ferbûn is. In UDP-lister ferskynt allinnich yn 'e earste list en in TCP-lister allinnich yn 'e twadde, dus in ûntbrekkende rigel is de fluchste manier om in profyl te finen dat nea tapast is. Ferlykje ek de poarte, want in TCP-profyl op 1194 hâldt him oars as ien op 443 yn 'e measte tagongsnetwurken. Start de tsjinst nei de feroaring opnij en lês de logrigel dy't de bining meldt.

Befêstiging oan 'e kliïntkant is goedkeap: rin de ferbining mei --verb 4 en lês de transportrigel yn 'e log. As de kliïnt UDP seit wylst de server op TCP harket, begjint de hânskodding nea en gjin enkele ôfstelling sil helpe.

Ferlykje de wurklêst, net it label fan 'e transport

In earlike ferliking hâldt alles behalve de transport konstant. Itselde apparaat, itselde tagongsnetwurk, deselde bestimming-host, deselde applikaasje en idealiter deselde server. As de twa profilen nei ferskillende hosts wize, mjit jo dy hosts ek.

Registrearje trije útkomsten per run: oft de tunnel ta stân komt, oft er oanhâldt en oft de taak ôfmakke wurdt. Lytse fersiken dy't wurkje wylst grutte oerdrachten fêstrinne, wize op pakketgrutte en MTU, net op de transport. Werhelle ferbinings wize op it paad of op in time-out fan in middenbak.

Hâld it profyl dat wurket ûnder de omstannichheden dy't jo echt treffe, en bewarje it oare. De kar heart by it netwurk, net by de persoan, en dêrom is elk inkeld standertantwurd earne ferkeard.