Hvorfor en OpenVPN-profil virker derhjemme, men fejler på et hotel

Kontorets Wi-Fi og et hotelværelse kan give den samme bærbare computer to meget forskellige netværk, og profilen imellem aner ikke noget om det. Det, der virker derhjemme, forudsætter en imødekommende uplink, fungerende navneopløsning og et lokalt subnet, der ikke kolliderer med noget, tunnelen bærer. Hver af disse forudsætninger kan svigte uafhængigt.

Den nyttige måde at fejlfinde dette på er at behandle netværket som fire adskilte fakta og derefter teste dem i rækkefølge. At gætte på profilen først giver normalt en ændring, der ikke retter noget og slører beviserne.

Fire netværksfakta ændrer sig mellem lokationer

Det første faktum er, om det lokale netværk overhovedet lukker dig ud. En captive portal lukker en enhed ind på en login-side og blokerer alt andet, indtil siden er gennemført, hvilket betyder, at tunnelen ikke kan starte, uanset hvor korrekt profilen er.

Det andet er navneopløsning. En portal, der opsnapper DNS, svarer på hver forespørgsel med sin egen adresse, så VPN-værtsnavnet opløses til portalen, og klienten forsøger at bygge en tunnel til en webside.

Det tredje er transportfiltrering. Netværk, der kun vil tillade browsing, sender TCP 443 til vilkårlige destinationer og dropper næsten alt andet, inklusive UDP.

Det fjerde er adressering. Det lokale subnet kan overlappe et netværk bag tunnelen, eller uplinken giver slet ingen brugbar IPv4-rute.

Navneopløsning og portalen

Erstat værtsnavnet i profilen med serverens numeriske adresse, og prøv igen. Hvis IP'en forbinder, og navnet ikke gør, er navneopløsningen problemet, og profilen selv er i orden.

Åbn en browser, og forsøg en almindelig HTTP-side, før du rører VPN'en. En omdirigering til en login-side betyder, at portalen stadig venter; gennemfør den, og opret derefter forbindelsen igen. Mange hoteller udløber også sessionen efter nogle timer, hvilket ser ud som en afbrydelse midt på dagen snarere end et login-problem.

Hvis den numeriske adresse også fejler, er navneopløsningen ikke forklaringen, så gå videre til transporten. Behold den adresse, du testede, fordi den fortæller den næste kontrol, om pakkerne overhovedet forlod maskinen.

Transportfiltrering: UDP først, TCP 443 som reserve

En OpenVPN-strøm over UDP 1194 ligner ikke noget, en hotelfirewall genkender, så den droppes uden fejl. Klienten prøver igen, indtil dens timeout udløber, og brugeren ser en forbindelse, der aldrig etableres, i stedet for en afvisning. Firewalls, der opfører sig sådan, logger sjældent droppet noget sted, du kan se. Fraværet af en afvisning er selv ledetråden.

TCP 443 er den pålidelige reserve, fordi netværket ikke kan skelne det fra almindelig HTTPS. Brug operatørens TCP-profil, når der findes en, da serveren også skal lytte på den transport og port; at ændre kun klienten giver en anden slags fejl. Hvis der ikke findes en TCP-profil, så spørg operatøren i stedet for at opfinde en ved at redigere porten. Serversiden skal være enig, og en uoverensstemmelse ligner igen et firewall-problem.

Forvent en pris i ydeevne. TCP inde i TCP forstærker gensendinger på et tabsgivende link, så en TCP-tunnel, der virker, kan stadig føles langsom på et overbelastet hotelnetværk. Det er en byttehandel for nåbarhed, ikke en fejl at jage.

Adressekollisioner og uplinks uden IPv4

En tunnel kan etablere og stadig ikke bære noget. Når det lokale LAN og et fjernnetværk deler et præfiks som 192.168.1.0/24, betragter klienten fjernværten som direkte forbundet og sender pakken til det lokale link i stedet for tunnelen. Symptomet er en vellykket forbindelse med et enkelt subnet, der ikke kan nås, hvilket let læses forkert som et ruteproblem på serversiden.

Den permanente løsning er at flytte fjern-LAN'et til et usædvanligt privat område. At vælge et område, som ingen bruger derhjemme, såsom 10.42.0.0/24, forhindrer problemet for enhver fremtidig lokation i stedet for én. Den lokale omvej er at undgå det hotel, hotspot eller den router, hvilket slet ikke er en løsning.

Mobile uplinks tilføjer to variationer. Carrier-grade NAT betyder, at indgående forbindelser ikke ankommer, hvilket betyder noget, hvis du hoster en server, men ikke for en udgående klient. En APN konfigureret som kun IPv6 med NAT64-oversættelse kan få en klient til at fejle, som insisterer på en rigtig IPv4-rute, og den sædvanlige kur er at ændre APN'ets protokol til IPv4 eller dobbelt stak.

Symptomer efter tunnelen er oppe

En tunnel, der forbinder og derefter går i stå, er normalt et keepalive- eller MTU-problem, ikke en blokeret port. En forbindelse, der falder efter et fast antal minutter, peger på en keepalive- eller genforhandlingstimer. Indstil klienten til at probe sin peer og genstarte, når svar stopper, og test en mindre tunnel-MTU, hvis ping lykkes, mens store overførsler går i stå.

Før du beder om hjælp, skriv tre ting ned: den adresse, du prøvede, og om den svarede, den transport og port, du brugte, og det lokale subnet i det netværk, der fejlede. Sammen adskiller de navneopløsning fra transportfiltrering og fra en adressekollision, som er de årsager, der overlever kontakten med beviser.