Varför en OpenVPN-profil fungerar hemma men misslyckas på hotell

Kontorets Wi-Fi och ett hotellrum kan ge samma laptop två väldigt olika nätverk, och profilen däremellan vet ingenting om det. Det som fungerar hemma förutsätter en tillåtande upplänk, fungerande namnsuppslagning och ett lokalt subnät som inte krockar med något som tunneln transporterar. Varje sådan förutsättning kan brista separat.

Det användbara sättet att felsöka detta är att behandla nätverket som fyra separata fakta och sedan testa dem i ordning. Att gissa på profilen först ger oftast en ändring som inte åtgärdar något och skymmer bevisen.

Fyra nätverksfakta ändras mellan platser

Det första faktumet är om det lokala nätverket överhuvudtaget släpper ut dig. En inloggningsportal släpper in en enhet på en inloggningssida och blockerar allt annat tills den sidan är klar, vilket betyder att tunneln inte kan starta, hur korrekt profilen än är.

Det andra är namnsuppslagning. En portal som fångar upp DNS svarar på varje fråga med sin egen adress, så VPN-värdnamnet löses upp till portalen och klienten försöker bygga en tunnel till en webbsida.

Det tredje är transportfiltrering. Nätverk som bara vill tillåta surfning släpper igenom TCP 443 till godtyckliga destinationer och släpper nästan allt annat, inklusive UDP.

Det fjärde är adressering. Det lokala subnätet kan överlappa ett nätverk bakom tunneln, eller så kan upplänken inte erbjuda någon användbar IPv4-väg alls.

Namnsuppslagning och inloggningsportalen

Byt ut värdnamnet i profilen mot serverns numeriska adress och försök igen. Om IP:t ansluter men namnet inte, är namnsuppslagningen felet, och profilen i sig är i ordning.

Öppna en webbläsare och försök med en vanlig HTTP-sida innan du rör VPN:et. En omdirigering till en inloggningssida betyder att portalen fortfarande väntar; slutför den och anslut sedan igen. Många hotell låter också sessionen gå ut efter några timmar, vilket ser ut som en avbrytning mitt på dagen snarare än ett inloggningsproblem.

Om den numeriska adressen också misslyckas är namnsuppslagningen inte förklaringen, så gå vidare till transporten. Spara adressen du testade, eftersom den berättar för nästa kontroll om paketen överhuvudtaget lämnade maskinen.

Transportfiltrering: UDP först, TCP 443 som reserv

Ett OpenVPN-flöde över UDP 1194 ser inte ut som något en hotellbrandvägg känner igen, så det släpps utan fel. Klienten försöker igen tills dess tidsgräns går ut, och användaren ser en anslutning som aldrig upprättas i stället för en vägran. Brandväggar som beter sig så loggar sällan släppet någonstans där du kan se det. Avsaknaden av en vägran är i sig ledtråden.

TCP 443 är den pålitliga reserven eftersom nätverket inte kan skilja det från vanlig HTTPS. Använd operatörens TCP-profil när en finns, eftersom servern också måste lyssna på den transporten och porten; att bara ändra klienten ger en annan typ av fel. Om det inte finns någon TCP-profil, fråga operatören i stället för att hitta på en genom att redigera porten. Serversidan måste hålla med, och en avvikelse ser återigen ut som ett brandväggsproblem.

Räkna med en prestandakostnad. TCP inuti TCP förstärker omsändningar på en länk med förluster, så en fungerande TCP-tunnel kan ändå kännas långsam på ett överbelastat hotellnätverk. Det är ett byte för nåbarhet, inte ett fel att jaga.

Adresskollisioner och upplänkar utan IPv4

En tunnel kan upprättas och ändå inte transportera något. När det lokala LAN:et och ett fjärrnätverk delar ett prefix som 192.168.1.0/24 anser klienten att fjärrvärden är direkt ansluten och skickar paketet till den lokala länken i stället för tunneln. Symtomet är en lyckad anslutning med ett subnät som inte nås, vilket lätt läses fel som ett routingproblem på serversidan.

Den bestående åtgärden är att flytta fjärr-LAN:et till ett ovanligt privat område. Att välja ett område som ingen använder hemma, som 10.42.0.0/24, förhindrar problemet för varje framtida plats i stället för en. Den lokala kringgången är att undvika det hotellet, hotspot:en eller routern, vilket inte alls är en åtgärd.

Mobila upplänkar lägger till två varianter. Carrier-grade NAT innebär att inkommande anslutningar inte kommer fram, vilket spelar roll om du hostar en server men inte för en utgående klient. En APN konfigurerad som bara IPv6 med NAT64-översättning kan få en klient som kräver en riktig IPv4-väg att misslyckas, och det vanliga botemedlet är att ändra APN:ets protokoll till IPv4 eller dubbel stack.

Symtom efter att tunneln är uppe

En tunnel som ansluter och sedan tystnar är oftast ett keepalive- eller MTU-problem, inte en blockerad port. En anslutning som faller efter ett fast antal minuter pekar på en keepalive- eller omförhandlingstimer. Ställ in klienten att sondera sin motpart och starta om när svaren upphör, och testa en mindre tunnel-MTU om ping går igenom medan stora överföringar fastnar.

Innan du ber om hjälp, skriv ned tre saker: adressen du försökte och om den svarade, transporten och porten du använde, och det lokala subnätet i nätverket som misslyckades. Tillsammans skiljer de namnsuppslagning från transportfiltrering och från en adresskollision, och det är orsakerna som överlever kontakt med bevis.