UDP is nie altyd vinniger nie: kies jou OpenVPN-vervoer

Elke gids sê UDP klop TCP vir OpenVPN, en dié raad is ’n verstek, nie ’n meting nie. Die vervoer verander hoe pakkette afgelewer word en wat gebeur wanneer die pad hulle laat val, nie hoe die tonnel geïnkripteer word nie. Agter ’n captive portal of ’n proxy wat net poort 443 toelaat, is die stadiger opsie die een wat hoegenaamd konnekteer. Wat volg, skei wat die protokol doen van wat jou toegangsnetwerk toelaat.

Wat die vervoer werklik verander

TCP lewer ’n betroubare, geordende greiestroom en stuur weer wat verlore gaan, soos RFC 9293 bepaal. UDP gee datagramme aan die netwerk oor, en OpenVPN hardloop sy eie betroubaarheidslaag oor daardie sokkel. Om TCP in TCP te kapsuleer, stapel twee herstel-lusse, so een verlore segment kan die binneste stroom ophou totdat die buitenste herversending aankom. Dié wisselwerking is die regte argument vir UDP, en dit verskyn as latensie eerder as deurvloei.

Die effek skaal met verlies en heen-en-weer-tyd. Op ’n skoon plaaslike pad voel albei vervoermiddels identies, en daarom reproduseer ’n laboratoriumtoets selde die klagte. Op ’n oorlaaide mobiele skakel wys die verskil in interaktiewe sessies lank voordat ’n groot oordrag iets agterkom.

Niks hiervan raak vertroulikheid of integriteit nie. Die TLS-handdruk en die datakanaal-syfer is dieselfde vir albei vervoermiddels, so oorskakel kan nie ’n swak syfersuite red nie.

Waar TCP sy plek verdien

Toegangsnetwerke is die gewone rede om TCP te kies. ’n Hotel, ’n lughawe of ’n gasnetwerk mag uitgaande 443 toelaat en alles anders laat val, en ’n TCP-luisteraar op daardie poort is die enigste profiel wat werk. Dit is bereikbaarheid, nie prestasie nie, en dit is op sigself ’n goeie genoeg rede.

TCP help ook wanneer die pad stabiel is maar die middleboxes vyandig is. Sommige netwerke stel langdurige UDP-vloei terug terwyl hulle TCP-sessies duld wat op gewone webverkeer lyk. Of daardie ooreenkoms slaag, is ’n eienskap van die spesifieke netwerk, en geen gids kan dit vir almal belowe nie. Toets binne die netwerk wat faal voordat jy die protokol blameer.

’n Verwerpte aanmelding is nie ’n vervoerprobleem nie. Om sertifikaatverifikasie af te skakel om ’n verbinding deur te dwing, is ’n ander verandering met ’n veel erger uitkoms.

Om ’n TCP-profiel gereed te hou, is die praktiese kompromis. Die meeste kliënte stoor albei en laat jou oorskakel wanneer ’n netwerk die UDP-pad weier, wat niks kos totdat jy dit nodig het nie. Wat jy nie moet doen nie, is om twee profiele te lewer wat na verskillende eindpunte wys, want dan meet jou vergelyking die bedieners.

Kontroleer watter luisteraar jy werklik het

Voordat jy prestasie vergelyk, bevestig dat albei kante dit oor die vervoer en die poort eens is. Om proto udp na proto tcp in ’n kliëntlêer te verander, skep nie ’n bediener-luisteraar nie. Die bediener moet vir daardie protokol opgestel wees, en die profiel moet daarby pas.

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

Die grep druk wat aan die bediener gesê is om te gebruik, terwyl die twee sokkel-lyste wys waaraan dit gebind is. ’n UDP-luisteraar verskyn net in die eerste lys en ’n TCP-luisteraar net in die tweede, so ’n ontbrekende reël is die vinnigste manier om ’n profiel te vind wat nooit toegepas is nie. Vergelyk ook die poort, want ’n TCP-profiel op 1194 gedra hom anders as een op 443 in die meeste toegangsnetwerke. Herbegin die diens ná die verandering en lees die logreël wat die binding rapporteer.

Kliëntkant-bevestiging is goedkoop: laat die verbinding met --verb 4 loop en lees die vervoerreël in die log. As die kliënt UDP sê terwyl die bediener op TCP luister, begin die handdruk nooit nie en geen mate van instel sal help nie.

Vergelyk die werklaag, nie die vervoeretiket nie

’n Regverdige vergelyking hou alles behalwe die vervoer konstant. Dieselfde toestel, dieselfde toegangsnetwerk, dieselfde bestemminghost, dieselfde toepassing, en ideaal dieselfde bediener. As die twee profiele na verskillende hosts wys, meet jy daardie hosts ook.

Teken drie uitkomste vir elke lopie aan: of die tonnel vestig, of dit bly staan, en of die taak voltooi. Klein versoeke wat werk terwyl groot oordragte vasval, wys op pakgrootte en MTU eerder as op die vervoer. Herhaalde herverbindings wys op die pad of op ’n middlebox-tydsverloop.

Hou die profiel wat werk onder die omstandighede wat jy werklik teëkom, en hou die ander een gestoor. Die keuse hoort by die netwerk, nie by die persoon nie, en daarom is enige enkele verstekantwoord ergens verkeerd.