OpenVPN fungerar hemma men inte på ett nätverk: UDP eller TCP?

Samma profil ansluter hemifrån och fastnar på ett hotell-, campus- eller filialnätverk. Inloggningsuppgifterna har inte ändrats, så den intressanta variabeln är vägen: OpenVPN vad som händer med paketen innan den läser dem. Att jämföra fyra möjliga orsaker i den ordning de kan testas slår att gissa om certifikat. Var och en lämnar ett olikt spår, och spåret är det som skiljer dem åt.

Vilket steg som misslyckades avgör vilken jämförelse som spelar roll

Klientloggen registrerar redan hur långt du kom. En rad som säger att TLS-nyckelförhandlingen inte skedde inom tidsgränsen betyder att ett första paket lämnade och inget användbart kom tillbaka, vilket pekar på vägen. Ett certifikatavslag ser helt annorlunda ut: ett svar anländer, och sedan namnger ett specifikt verifieringsfel orsaken. Notera sista raden före återförsöksloopen, för det är värdet du jämför mellan nätverk.

Fånga medan du försöker igen, inte efteråt. På klienten visar tcpdump -ni any udp port 1194 om det överhuvudtaget kommer tillbaka något svar. Upprepa på WAN-gränssnittet på en server du kontrollerar, vilket avslöjar om paketen överhuvudtaget når den bortre änden.

Enkelriktad trafik är det mest användbara resultatet som finns här, eftersom det förvandlar ett återkommande klagomål till en riktning att undersöka. Spara fångstfilerna, för nästa rapport om samma problem stängs lättare med bevis än med en beskrivning.

UDP-filtrering kontra en stängd port

Många åtkomstnätverk ser ihållande UDP som misstänkt, och vissa leverantörer håller med. En stängd port producerar samma tystnad från klientsidan. Skillnaden är selektivitet: ett filter brukar vara kräset när det gäller vilka destinationer eller portar det släpper, medan en stängd port avvisar allt som riktas mot den porten.

En TCP-profil på port 443 är den vanliga lösningen, eftersom den liknar ett vanligt HTTPS-flöde och passerar de flesta captive-portaler och utgående filter. Två villkor måste gälla. Servern måste lyssna med proto tcp-server och klienten måste matcha med proto tcp-client, och operatören måste publicera den alternativa slutpunkten. Att skriva om en fungerande UDP-profil för att hävda TCP 443 leder ingenstans när inget lyssnar på andra sidan.

En stängd port är ett konfigurationsproblem, inte ett censurproblem. En server bakom en hemrouter behöver vidarebefordran av UDP-porten, och routerns brandvägg måste tillåta det. När porten aldrig har tillåtits misslyckas varje klient i förhandlingen oavsett inloggningsuppgifter, och felet följer servern i stället för nätverket.

Äldre protokoll står sig dåligt på den här axeln. PPTP kräver TCP 1723 plus GRE, och GRE är IP-protokoll 47, inte en port, så ingen vanlig portvidarebefordran uttrycker det.

När det är switchen som släpper paketen

En hanterad switch kan släppa tunneln med avsikt. Vissa HPE- och Aruba-modeller erbjuder en UDP-floodskyddskontroll, ibland märkt Prevent UDP Blat Attack, i sitt avancerade säkerhetsavsnitt. När kontrollen är aktiv svarar en server bakom switchen inte på något och varje klient får timeout på samma sätt. Att stänga av den och spara den körande konfigurationen är hela reparationen, men först efter att du har fastställt att switchen verkligen ligger i vägen.

Motbevis är det som skiljer ett switchsläpp från en leverantörsblockering. Läs gränssnittsräknarna och floodskyddsloggen innan du öppnar ett ärende hos leverantören. Konsumentroutrar med DoS- eller floodskydd misslyckas i samma form, och detsamma gäller varje mellanliggande box med kort UDP-tomgångstid. Ett handtryck som aldrig fullbordas tyder på ett släpp, medan en tunnel som dör efter några minuters tystnad tyder på tidsgränsen.

Skriv ner varje enhet mellan klient och server innan du ändrar en profil. En rättelse som läggs på fel lager ser korrekt ut fram till nästa nätverk. Den listan berättar också för nästa ingenjör var hen ska titta utan att upprepa hela undersökningen.

En adressöverlappning som ser ut som ett DNS-fel

Ett åtkomstnätverk numrerat inom 10.0.0.0/8 kan överlappa tunnelpoolen, och resolvern bor oftast i den poolen. När en laptop får en adress som 10.184.178.50 med /8-mask på Wi-Fi är varje 10.x-destination lokal per definition. Paket till 10.4.0.1 går då till LAN, tunneln hålls uppe och namnmatchningen misslyckas.

ip addr visar överlappningen direkt, och ip route get 10.4.0.1 visar var paketet verkligen skulle levereras. Eftersom det synliga symptomet är ett resolverfel överlever detta ofta flera omgångar av DNS-ändringar.

Numrera om poolen eller håll det åtkomstnätverket utanför omfånget. Ingen klientinställning återställer från en överlappning.

Att välja mellan TCP-reservväg och vägfix

Välj TCP-reservvägen när du inte kontrollerar vägen och användarna behöver arbeta idag, och acceptera kostnaderna: TCP inuti TCP beter sig illa på länkar med förluster, och reservvägen kräver en lyssnare som du driver. Välj vägfixen när blockeringen ligger på infrastruktur du äger, eftersom en brandväggsregel är billigare än en andra lyssnare. Hur som helst, gå igenom lagren i ordning: länk, yttre transport, förhandling, intern routing. Steget som misslyckades i det nätverket är det enda faktum som spelar roll.

Registrera resultatet per nätverk, inte per användare. Nästa rapport om samma fel börjar då vid ett känt steg i stället för vid en certifikatteori. Den registreringen är också det som motiverar en permanent andra lyssnare, om en någonsin behövs.