proto udp eller tcp-client: vilken hör din server?

En profil som fungerade förra månaden går nu i timeout, och någon föreslår att proto udp byts till proto tcp-client. Ibland är det rätt steg, ibland ger det en klient som ansluter till en port där ingenting lyssnar, eftersom servern aldrig konfigurerades för den andra transporten. Direktivet beskriver hur din sida talar; det kan inte skapa en lyssnare i andra änden. Läs profilen och servern tillsammans innan du ändrar någon av dem.

Läs transporten som den valda anslutningen använder

En profil kan innehålla flera remote-poster, och var och en kan ange sin egen transport. Klienten går igenom dem i ordning, så raden du ser först är inte nödvändigtvis den som gäller.

Hitta posten som faktiskt provas och läs sedan dess transport. Ordningen spelar roll, eftersom klienten inte går vidare i tysthet. Vissa byggen provar nästa post först efter en timeout, så ett fungerande alternativ längst ner i filen nås sekunder senare än du förväntar dig. Följ i loggen vilken ändpunkt som provas i stället för att anta att den första raden vann.

Om filen har en proto-rad nära toppen och flera remote-poster under den, är den raden standard för varje remote som inte åsidosätter den. En lokal ändring av standarden gör ingenting för en remote-post som anger sin egen transport.

grep -nE '^(remote|proto)\b' client.ovpn

UDP och TCP är inte en hastighetsinställning

UDP skickar datagram utan att bygga en ordnad ström, så själva tunneltrafiken packas inte in i en andra tillförlitlig transport. TCP ger dig en väg genom nätverk som tappar eller blockerar UDP, till priset av inbäddad omsändning som kan få en förlustdrabbad länk att kännas värre.

Det är ett byte av nåbarhet, inte en universell rangordning. Rätt val är det som nätverket framför klienten tillåter. En väg som tappar UDP på VPN-porten kommer aldrig att förhandla, hur välskriven profilen än är. Testa vägen och välj sedan transporten.

Att välja mellan dem enbart utifrån en mätning är ett misstag, eftersom svaret beror på vad nätverket framför dig tillåter. Ett hotell eller en företagsproxy kan tillåta utgående TCP på 443 och ingenting annat, och därför erbjuder leverantörerna den varianten. Det förblir en OpenVPN-anslutning på den porten, inte en HTTPS-session, även om portnumret är det bekanta.

Vad tcp-client egentligen betyder

Direktivet på klientsidan namnger den ände som startar en TCP-anslutning. Serversidan använder sin egen lyssnande form, och att kopiera klientens ord till en serverkonfiguration ger en lyssnare som förväntar sig att bli uppringd, inte en som accepterar.

Att matcha betyder att de två ändarna är överens om transporten, inte att de delar samma sträng.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Fråga servern vad den lyssnar på innan du antar att profilen är fel. En UDP-lyssnare syns inte i en TCP-socketlista, och det omvända är också sant, så titta på den protokollspecifika vyn i stället för en generisk.

När profilen importeras men aldrig ansluter

En importerad profil som omedelbart går i timeout misslyckas vanligtvis före någon autentisering. Paketet går till en port utan lyssnare, eller så tappar nätverket det i tysthet.

Testa vägen på enklaste möjliga sätt: anslut till samma värd och port med den transport som profilen hävdar, från samma nätverk som den misslyckade klienten.

Om ett UDP-test inte får något och ett TCP-test ansluter, erbjuder servern den andra transporten och profilen är helt enkelt inaktuell. Om ingen av dem svarar ligger problemet ovanför transportvalet och ingen ändring av profilen åtgärdar det. Att skilja dessa två fall tar en minut och sparar en timme felsökning av certifikat som aldrig var relevant.

Skriv ner den fungerande transporten

När en kombination fungerar skriver du ner den med server, port och protokoll och noterar vilket nätverk den testades från.

Annars kommer nästa person som råkar ut för en timeout att prova samma experiment i motsatt riktning, och kanske ändra en server som var i ordning.

Om leverantören publicerar båda varianterna, behåll båda filerna och märk dem efter det nätverk de passar för. Två tydligt namngivna profiler förhindrar att en klienttransport av misstag blandas med en serverlyssnare som aldrig konfigurerades för den.