UDP är inte alltid snabbare: att välja OpenVPN-transport

Varje guide säger att UDP slår TCP för OpenVPN, och rådet är ett standardval, inte en mätning. Transporten ändrar hur paket levereras och vad som händer när vägen tappar dem, inte hur tunneln krypteras. Bakom en captive portal eller en proxy som bara tillåter port 443 är det långsammare alternativet det som överhuvudtaget ansluter. Det följande skiljer vad protokollet gör från vad ditt åtkomstnät tillåter.

Vad transporten faktiskt ändrar

TCP levererar en pålitlig, ordnad byteström och skickar om allt som förloras, som RFC 9293 föreskriver. UDP lämnar datagram till nätet, och OpenVPN kör sitt eget tillförlitlighetslager ovanpå den socketen. Inkapsling av TCP i TCP staplar två återhämtningsloopar, så ett enda förlorat segment kan hålla kvar den inre strömmen tills den yttre omsändningen anländer. Det samspelet är det egentliga argumentet för UDP, och det visar sig som latens snarare än som genomströmning.

Effekten ökar med förluster och rundtur-tid. På en ren lokal väg känns båda transporterna identiska, och därför återger ett labbtest sällan klagomålet. På en överbelastad mobillänk syns skillnaden i interaktiva sessioner långt innan en stor överföring märker något.

Inget av detta rör konfidentialitet eller integritet. TLS-handskakningen och datakanalens chiffer är desamma för båda transporterna, så ett byte kan inte rädda en svag chifferuppsättning.

Där TCP förtjänar sin plats

Åtkomstnät är det vanliga skälet att välja TCP. Ett hotell, en flygplats eller ett gästnät tillåter kanske utgående 443 och släpper allt annat, och en TCP-lyssnare på den porten är den enda profil som fungerar. Det är nåbarhet, inte prestanda, och det är skäl nog i sig.

TCP hjälper också när vägen är stabil men mellanliggande utrustning är fientlig. Vissa nät återställer långvariga UDP-flöden medan de tolererar TCP-sessioner som liknar vanlig webbtrafik. Om den likheten lyckas är en egenskap hos det konkreta nätet, och ingen guide kan lova det för alla. Testa inne i nätet som misslyckas innan du skyller på protokollet.

En avvisad inloggning är inte ett transportproblem. Att stänga av certifikatverifieringen för att tvinga igenom en anslutning är en annan ändring med ett mycket sämre utfall.

Att ha en TCP-profil redo är den praktiska kompromissen. De flesta klienter sparar båda och låter dig byta när ett nät avvisar UDP-vägen, vilket inte kostar något förrän du behöver det. Det du inte bör göra är att leverera två profiler som pekar på olika ändpunkter, för då mäter din jämförelse servrarna.

Kontrollera vilken lyssnare du faktiskt har

Innan du jämför prestanda, bekräfta att båda sidor är överens om transporten och porten. Att ändra proto udp till proto tcp i en klientfil skapar ingen serverlyssnare. Servern måste vara konfigurerad för det protokollet, och profilen måste matcha det.

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

grep skriver ut vad servern fick besked att använda, medan de två socket-listorna visar vad den är bunden till. En UDP-lyssnare visas bara i den första listan och en TCP-lyssnare bara i den andra, så en saknad rad är det snabbaste sättet att hitta en profil som aldrig användes. Jämför även porten, för en TCP-profil på 1194 beter sig annorlunda än en på 443 i de flesta åtkomstnät. Starta om tjänsten efter ändringen och läs loggraden som rapporterar bindningen.

Bekräftelse på klientsidan är billig: kör anslutningen med --verb 4 och läs transportraden i loggen. Om klienten säger UDP medan servern lyssnar på TCP börjar handskakningen aldrig, och ingen justering hjälper.

Jämför arbetsbelastningen, inte transportetiketten

En rättvis jämförelse håller allt konstant utom transporten. Samma enhet, samma åtkomstnät, samma målvärd, samma applikation och helst samma server. Om de två profilerna pekar på olika värdar mäter du också dem.

Registrera tre utfall per körning: om tunneln upprättas, om den håller sig uppe och om uppgiften slutförs. Små förfrågningar som fungerar medan stora överföringar fastnar pekar på paketstorlek och MTU, inte på transporten. Upprepade återanslutningar pekar på vägen eller på en tidsgräns i en mellanliggande utrustning.

Behåll profilen som fungerar under de förhållanden du faktiskt möter, och spara den andra. Valet tillhör nätet, inte personen, och därför är varje enskilt standardsvar fel någonstans.