OpenVPN på port 53: tre samtal som folk blandar ihop
Uppslagningen av slutpunkten, den krypterade transporten och DNS efter tunneln är tre samtal. Avgör vilket steg som misslyckades innan du byter port eller resolver.
Rapporter som säger att VPN:en är blockerad på port 53 blandar ihop tre observationer som misslyckas av olika skäl. Uppslagningen av slutpunktens namn sker innan någon tunnel finns, den krypterade transporten är ett eget samtal, och DNS-frågorna som görs efteråt är det tredje. Var och en har sin egen felsignatur, och bara en av dem handlar om DNS över huvud taget.
Sortera paketen efter syfte innan du ändrar något, eftersom åtgärden följer steget.
Tre samtal, ett portnummer
Det första samtalet är en namnsökning för slutpunkten: din maskin frågar den konfigurerade resolvern var vpn.example.com ligger, och svaret kommer via vanlig DNS innan klienten skickar ett enda tunnelpaket. Det andra är själva OpenVPN-transporten, som ansluter till adressen som sökningen gav, på det protokoll och den port som profilen anger. Det tredje sker efter att tunneln är uppe, när program begär namn och de påskjutna resolverinställningarna avgör vem som svarar.
Dessa tre kan lyckas eller misslyckas oberoende av varandra. En klient kan slå upp sin slutpunkt perfekt och ändå inte nå lyssnaren, och den kan upprätta en tunnel medan varje intern namnsökning misslyckas eftersom DNS-inställningarna aldrig kom fram.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Läs tabellen som en checklista och inte som en beskrivning. Om slutpunktens namn inte går att slå upp kan ingenting senare fungera, och tunneln startar aldrig.
Portnumret namnger inte programmet
Port 53 bär DNS enligt konvention, och en OpenVPN-operatör kan också publicera en lyssnare där, och det är just därför numret är en dålig identifierare. En OpenVPN-session på UDP 53 är fortfarande en OpenVPN-session, och en DNS-fråga till en server på port 53 säger ingenting om huruvida en tunnel är tillåten. Raderna proto och remote i profilen definierar den yttre slutpunkten; portnumret definierar ingenting i sig självt.
Det skär åt båda hållen vid felsökning: en generisk UDP-probe mot port 53 bevisar att en port svarar, inte att VPN-tjänsten svarar. Testa med den riktiga klienten och den riktiga profilen, eftersom bara det övar den handskakning som tjänsten förväntar sig.
Bevisa lyssnaren innan du skyller på nätet
Kontrollera på servern vad som är bundet med ss -lunp | grep 53 och jämför med profilens protokoll och port. Från klientens nätverk, kör klienten med högre detaljgrad så att loggen visar vilken adress och transport den försökte. Om servern lyssnar och klientens paket inte kommer fram är det vägen eller policyn som avvisar dem, och det är ett samtal med nätägaren och inte ett skäl att byta port.
En annan port hjälper bara när tjänsten faktiskt lyssnar där och driftsättningen tillåter det. Att flytta en lyssnare för att undvika filtrering i ett hanterat nät är ett policybeslut, inte ett felsökningssteg. Fråga nätägaren vad som är tillåtet innan du ändrar tjänsten, eftersom en omväg som bryter mot policyn stängs senare ändå. Skriv ner svaret bredvid profilen så att nästa person inte upprepar begäran.
Kontrollera DNS efter tunneln, separat
När tunneln är uppe, undersök resolverstatusen på VPN-gränssnittet och fråga efter ett internt och ett offentligt namn. Om interna namn misslyckas medan tunneln bär trafik har de påskjutna DNS-inställningarna inte tillämpats, vilket är en fråga om klientintegration och inte om transport. Om offentliga namn misslyckas och interna namn fungerar gör policyn för delad tunnel det den konfigurerades för.
Låt DNS-ändringarna ligga hos resolverns ägare. Att skriva över en hanterad resolverkonfiguration för att få ett test att passera kan förstöra privata namn för allt annat på maskinen. Om tunneln skjuter ut en resolver och klienten ignorerar den, reparera klientintegrationen i stället för att lägga till en statisk post någon annanstans. Statiska poster döljer felet tills någon byter nätverk. Skriv ner vilken resolver som förväntas svara för varje namnrymd.