Hvorfor en OpenVPN-profil virker hjemme, men svikter på et hotell

Kontorets Wi-Fi og et hotellrom kan gi den samme laptopen to svært ulike nettverk, og profilen imellom aner ingenting om det. Det som virker hjemme, forutsetter en ettergivende oppstrømsforbindelse, fungerende navneoppslag og et lokalt subnett som ikke kolliderer med noe tunnelen frakter. Hver av disse forutsetningene kan svikte uavhengig.

Den nyttige måten å feilsøke dette på er å behandle nettverket som fire atskilte fakta og deretter teste dem i rekkefølge. Å gjette på profilen først gir vanligvis en endring som ikke retter noe og tilslører bevisene.

Fire nettverksfakta endrer seg mellom steder

Det første faktumet er om det lokale nettverket slipper deg ut i det hele tatt. En innloggingsportal slipper en enhet inn på en innloggingsside og blokkerer alt annet til den siden er fullført, noe som betyr at tunnelen ikke kan starte, uansett hvor riktig profilen er.

Det andre er navneoppslag. En portal som fanger opp DNS, svarer på hver forespørsel med sin egen adresse, slik at VPN-vertsnavnet løses til portalen og klienten prøver å bygge en tunnel til en nettside.

Det tredje er transportfiltrering. Nettverk som bare vil tillate surfing, slipper TCP 443 gjennom til vilkårlige destinasjoner og dropper nesten alt annet, inkludert UDP.

Det fjerde er adressering. Det lokale subnettet kan overlappe et nettverk bak tunnelen, eller oppstrømsforbindelsen kan ikke gi noen brukbar IPv4-rute i det hele tatt.

Navneoppslag og innloggingsportalen

Bytt ut vertsnavnet i profilen med serverens numeriske adresse og prøv igjen. Hvis IP-en kobler til og navnet ikke, er navneoppslaget feilen, og profilen selv er i orden.

Åpne en nettleser og prøv en vanlig HTTP-side før du rører VPN-en. En omdirigering til en innloggingsside betyr at portalen fortsatt venter; fullfør den, og koble til på nytt. Mange hoteller lar også økten utløpe etter noen timer, noe som ser ut som en avbrytelse midt på dagen snarere enn et innloggingsproblem.

Hvis den numeriske adressen også svikter, er ikke navneoppslag forklaringen, så gå videre til transporten. Behold adressen du testet, fordi den forteller neste sjekk om pakkene i det hele tatt forlot maskinen.

Transportfiltrering: UDP først, TCP 443 som reserve

En OpenVPN-strøm over UDP 1194 ser ikke ut som noe en hotellbrannmur kjenner igjen, så den droppes uten feil. Klienten prøver på nytt til tidsavbruddet utløper, og brukeren ser en tilkobling som aldri etableres i stedet for en avvisning. Brannmurer som oppfører seg slik, logger sjelden droppet noe sted du kan se. Fraværet av en avvisning er selv ledetråden.

TCP 443 er den pålitelige reserven fordi nettverket ikke kan skille det fra vanlig HTTPS. Bruk operatørens TCP-profil når en finnes, siden serveren også må lytte på den transporten og porten; å endre bare klienten gir en annen type feil. Hvis det ikke finnes noen TCP-profil, spør operatøren i stedet for å finne opp en ved å redigere porten. Serversiden må være enig, og et avvik ser igjen ut som et brannmurproblem.

Forvent en pris i ytelse. TCP inne i TCP forsterker retransmisjoner på en forbindelse med tap, så en TCP-tunnel som virker kan fortsatt føles treg på et overbelastet hotellnettverk. Det er en byttehandel for nåbarhet, ikke en feil å jage.

Adressekollisjoner og oppstrømsforbindelser uten IPv4

En tunnel kan etableres og likevel ikke frakte noe. Når det lokale LAN-et og et eksternt nettverk deler et prefiks som 192.168.1.0/24, anser klienten den eksterne verten som direkte tilkoblet og sender pakken til den lokale forbindelsen i stedet for tunnelen. Symptomet er en vellykket tilkobling med ett subnett som ikke kan nås, noe som lett leses feil som et ruteproblem på serversiden.

Den varige løsningen er å flytte det eksterne LAN-et til et uvanlig privat område. Å velge et område ingen bruker hjemme, som 10.42.0.0/24, forhindrer problemet for hvert framtidige sted i stedet for ett. Den lokale omveien er å unngå det hotellet, hotspoten eller ruteren, noe som slett ikke er en løsning.

Mobile oppstrømsforbindelser legger til to varianter. Carrier-grade NAT betyr at innkommende tilkoblinger ikke kommer fram, noe som betyr noe hvis du hoster en server, men ikke for en utgående klient. Et APN konfigurert som bare IPv6 med NAT64-oversettelse kan få en klient som insisterer på en ekte IPv4-rute til å feile, og den vanlige kuren er å endre APN-ets protokoll til IPv4 eller dobbel stakk.

Symptomer etter at tunnelen er oppe

En tunnel som kobler til og deretter blir stille, er vanligvis et keepalive- eller MTU-problem, ikke en blokkert port. En tilkobling som faller etter et fast antall minutter, peker på en keepalive- eller renegosieringstimer. Sett klienten til å sondere motparten og starte på nytt når svar stopper, og test en mindre tunnel-MTU hvis ping går gjennom mens store overføringer stopper.

Før du ber om hjelp, skriv ned tre ting: adressen du prøvde og om den svarte, transporten og porten du brukte, og det lokale subnettet til nettverket som sviktet. Sammen skiller de navneoppslag fra transportfiltrering og fra en adressekollisjon, og det er årsakene som overlever kontakt med bevis.