Kvifor ein OpenVPN-profil verkar heime, men sviktar på eit hotell

Kontoret sitt Wi-Fi og eit hotellrom kan gje den same laptopen to svært ulike nettverk, og profilen imellom veit ingenting om det. Det som verkar heime, føreset ei ettergjevande oppstraumslinje, fungerande namneoppslag og eit lokalt subnett som ikkje kolliderer med noko tunnelen fraktar. Kvar av desse føresetnadene kan svikte uavhengig.

Den nyttige måten å feilsøkje dette på er å handsame nettverket som fire atskilde fakta og deretter teste dei i rekkjefølgje. Å gjette på profilen først gir vanlegvis ei endring som ikkje rettar noko og tilslører prova.

Fire nettverksfakta endrar seg mellom stader

Det første faktumet er om det lokale nettverket slepp deg ut i det heile. Ein innloggingsportal slepp ein eining inn på ei innloggingsside og blokkerer alt anna til sida er fullført, noko som tyder at tunnelen ikkje kan starte, uansett kor riktig profilen er.

Det andre er namneoppslag. Ein portal som fangar opp DNS, svarar på kvar førespurnad med si eiga adresse, slik at VPN-vertsnamnet blir løyst til portalen og klienten prøver å byggje ein tunnel til ei nettside.

Det tredje er transportfiltrering. Nettverk som berre vil tillate surfing, slepp TCP 443 gjennom til vilkårlege mål og droppar nesten alt anna, inkludert UDP.

Det fjerde er adressering. Det lokale subnettet kan overlappe eit nettverk bak tunnelen, eller oppstraumslinja kan ikkje gje nokon brukbar IPv4-rute i det heile.

Namneoppslag og innloggingsportalen

Byt ut vertsnamnet i profilen med den numeriske adressa til serveren og prøv igjen. Viss IP-en koplar til og namnet ikkje, er namneoppslaget feilen, og profilen sjølv er i orden.

Opne ein nettlesar og prøv ei vanleg HTTP-side før du rører VPN-en. Ei omdirigering til ei innloggingsside tyder på at portalen framleis ventar; fullfør ho, og kople til på nytt. Mange hotell lèt også økta gå ut etter nokre timar, noko som ser ut som eit avbrot midt på dagen snarare enn eit innloggingsproblem.

Viss den numeriske adressa også sviktar, er ikkje namneoppslag forklaringa, så gå vidare til transporten. Hald på adressa du testa, fordi ho fortel neste sjekk om pakkane i det heile forlét maskina.

Transportfiltrering: UDP først, TCP 443 som reserve

Ein OpenVPN-straum over UDP 1194 ser ikkje ut som noko ein hotellbrannmur kjenner att, så han blir droppa utan feil. Klienten prøver på nytt til tidsavbrotet går ut, og brukaren ser ei tilkopling som aldri blir etablert i staden for ei avvising. Brannmurar som oppfører seg slik, loggar sjeldan droppet nokon stad du kan sjå. Fråværet av ei avvising er sjølv leiartråden.

TCP 443 er den pålitelege reserven fordi nettverket ikkje kan skilje det frå vanleg HTTPS. Bruk TCP-profilen til operatøren når ein finst, sidan serveren også må lytte på den transporten og porten; å endre berre klienten gir ein annan type feil. Viss det ikkje finst nokon TCP-profil, spør operatøren i staden for å finne opp ein ved å redigere porten. Serversida må vere samd, og eit avvik ser igjen ut som eit brannmurproblem.

Vent ein pris i yting. TCP inne i TCP forsterkar retransmisjonar på ei linje med tap, så ein TCP-tunnel som verkar kan framleis kjennast treg på eit overbelasta hotellnettverk. Det er eit bytte for nåbarheit, ikkje ein feil å jage.

Adressekollisjonar og oppstraumslinjer utan IPv4

Ein tunnel kan bli etablert og likevel ikkje frakte noko. Når det lokale LAN-et og eit eksternt nettverk deler eit prefiks som 192.168.1.0/24, reknar klienten den eksterne verten som direkte tilkopla og sender pakken til den lokale linja i staden for tunnelen. Symptomet er ei vellukka tilkopling med eitt subnett som ikkje kan nåast, noko som lett blir lese feil som eit ruteproblem på serversida.

Den varige løysinga er å flytte det eksterne LAN-et til eit uvanleg privat område. Å velje eit område ingen brukar heime, som 10.42.0.0/24, hindrar problemet for kvar framtidig stad i staden for éin. Den lokale omvegen er å unngå det hotellet, hotspoten eller rutaren, noko som slett ikkje er ei løysing.

Mobile oppstraumslinjer legg til to variantar. Carrier-grade NAT tyder at innkommande tilkoplingar ikkje kjem fram, noko som tel viss du hostar ein server, men ikkje for ein utgåande klient. Eit APN konfigurert som berre IPv6 med NAT64-omsetjing kan få ein klient som insisterer på ei ekte IPv4-rute til å feile, og den vanlege kuren er å endre protokollen til APN-et til IPv4 eller dobbel stakk.

Symptom etter at tunnelen er oppe

Ein tunnel som koplar til og deretter blir stille, er vanlegvis eit keepalive- eller MTU-problem, ikkje ein blokkert port. Ei tilkopling som fell etter eit fast tal minutt, peikar på ein keepalive- eller renegosieringstimer. Set klienten til å sondere motparten og starte på nytt når svar stoppar, og test ein mindre tunnel-MTU viss ping går gjennom medan store overføringar stoppar.

Før du ber om hjelp, skriv ned tre ting: adressa du prøvde og om ho svara, transporten og porten du brukte, og det lokale subnettet til nettverket som svikta. Saman skil dei namneoppslag frå transportfiltrering og frå ein adressekollisjon, og det er årsakene som overlever kontakt med prov.