OpenVPN kobler ikke til på hotell-Wi-Fi? Prøv TCP 443

Åpne klienten, trykk Koble til og les statuslinjen i stedet for dialogboksen som kommer etter. En profil som stopper på Kobler til eller Venter på server etter et hotell-, campus- eller mobilnett, har som regel mistet transporten et sted på veien, ikke påloggingsinformasjonen. Det nyttige neste steget er å finne ut hva dette nettet frakter før du rører serveren. Ikke endre noe før samme profil har virket et annet sted.

Test først fra et mobilpunkt. Hvis tunnelen kommer opp der, er serveren, sertifikatet og kontoen i orden, og den eneste variabelen som gjenstår er nettet foran deg.

Start på klienten: les statuslinjen

Statuslinjen forteller hvilket trinn som feilet. En klient som står fast på Kobler til, løser fortsatt opp vertsnavnet eller åpner den ytre sockelen; en som når Venter på server, har en vei men ikke noe svar; en som autentiserer og deretter faller ut, har et helt annet problem. Klientloggen og profilens egne remote- og proto-felt viser hva klienten prøver å gjøre, og --verb 4 på en kommandolinjeklient skriver ut samme detalj. Det er sammenligningen med nettet foran deg som gjør 'VPN-et er blokkert' til en konkret påstand.

Deretter undersøk nettet med verktøyene du allerede har. nc -vzu 203.0.113.10 1194 sender et UDP-datagram, curl -v telnet://203.0.113.10:443 rapporterer om TCP-håndtrykket fullføres, og en nettleser som laster en HTTPS-side beviser bare at utgående 443 når den ene verten. Små undersøkelser svarer på det VPN-klienten ikke kan: hvilken port og hvilken protokoll som i det hele tatt forlater dette nettet.

Tre nettverksoppførsler ser like ut fra klienten og krever ulike svar. Utgående 443 kan være åpen, bare en proxy kan være tillatt, eller 443 kan videresendes transparent til en inspeksjonsboks som ikke kan lese det den frakter. Den første fikses med profilendringen nedenfor, den andre med proxyinnstillinger, og den tredje kan fullføre et håndtrykk og deretter stoppe når inspektøren bestemmer seg for at den ikke liker strømmen. Å vite hvilken av de tre du står overfor er forskjellen mellom en endring på ti minutter og en ettermiddag med reinstallasjon av klienter.

Flytt lytteren og profilen sammen

På serversiden setter du lytteren til det nettet tillater: port 443 og proto tcp i serverkonfigurasjonen, deretter starter tjenesten på nytt og bekrefter sockelen med ss -lntp. På klientsiden må profilen stemme, fordi transport og port ligger utenfor tunnelen: proto tcp og port 443 i .ovpn, eller de tilsvarende feltene i appens innstillingsskjerm. En profil som fortsatt er rettet mot UDP 1194 feiler nøyaktig som før, og fristelsen er å skylde på en brannmur som allerede er reparert. Hvis samme vert også svarer HTTPS på 443, kan de to lytterne ikke dele den adressen og protokollen; gi VPN-et en andre adresse eller sett en demultiplekser foran.

Følg den første forbindelsen med tcpdump -ni any port 443 i begge ender. Pakker som forlater klienten og aldri kommer fram betyr at nettet likevel filtrerer, eller at adressen i profilen ikke er den du antar. Pakker som kommer fram uten svar sender deg tilbake til serverloggen, der et protokollavvik straks vises som en forkastet pakke.

Når bare en proxy slipper ut av nettet

Noen gjestenett tillater ingenting annet enn en HTTP-proxy, som er en annen begrensning enn en lukket port og utelukker mer enn OpenVPN. Klienter som bare snakker PPTP, L2TP/IPsec eller bar IPsec har ingen vei gjennom en slik, fordi de designene forventer at den ytre protokollen deres når serveren direkte. OpenVPN kan, med http-proxy proxy.example.net 8080 i klientprofilen, forutsatt at proxyen tillater CONNECT-metoden til porten din. En SOCKS-proxy er enda enklere, fordi den videresender strømmen uten å bry seg om hva som er inni.

Der klienten ikke har proxy-støtte, er en SSH-tunnel over 443 vanligvis det som gjenstår. Den legger til et andre lag, og operatøren av nettet kan mene noe om det, så behandle den som en bro for én reise og ikke som en arkitektur.

Pris reserven før du beholder den

TCP inne i TCP har en kjent kostnad. Når den ytre forbindelsen er TCP og nyttelasten også er TCP, utløser et tapt segment retransmisjon på begge lag, og den indre forbindelsen trekker seg tilbake fra et tap den ikke kan se. Nettlesing tåler det; interaktive økter og samtaler merker det. Behold TCP 443-lytteren som reserve for nett som krever den, og la UDP være standard for alt som fortsatt slipper den gjennom.

Skriv valget i profilnavnet og i støttenotatene: hvilken port, hvilken protokoll og hvilket nett som utløste det. Spør deretter nettets administrator om den porten blir stående åpen etter neste utstyrsutskifting, fordi en reserve som stille forsvinner er verre enn ingen reserve i det hele tatt.