OpenVPN opretter ikke forbindelse på hotel-Wi-Fi? Prøv TCP 443

Åbn klienten, tryk på Connect, og læs statuslinjen i stedet for dialogen, der følger efter den. En profil, der går i stå på Connecting eller Waiting for server efter et hotel-, campus- eller mobilnetværk, har normalt mistet sin transport et sted på vejen, ikke sine loginoplysninger. Det næste nyttige skridt er at finde ud af, hvad det netværk bærer, før du rører serveren. Ændr intet, før den samme profil har virket et andet sted.

Test først fra et telefon-hotspot. Hvis tunnelen kommer op der, er serveren, certifikatet og kontoen i orden, og den eneste tilbageværende variabel er netværket foran dig.

Start ved klienten: læs statuslinjen

Statuslinjen fortæller, hvilket trin der fejlede. En klient, der sidder fast på Connecting, er stadig ved at slå værten op eller åbne den ydre socket; en, der når Waiting for server, har en vej men intet svar; en, der godkender og derefter falder, har et helt andet problem. Klientloggen og profilens egne remote- og proto-felter viser, hvad klienten forsøger, og --verb 4 på en kommandolinjeklient udskriver samme detalje. Det er sammenligningen med netværket foran dig, der gør »VPN er blokeret« til en konkret påstand.

Undersøg derefter netværket med værktøjer, du allerede har. nc -vzu 203.0.113.10 1194 sender en UDP-datagram, curl -v telnet://203.0.113.10:443 rapporterer, om et TCP-håndtryk fuldføres, og en browser, der indlæser en HTTPS-side, beviser kun, at udgående 443 når den ene vært. Små undersøgelser besvarer det, VPN-klienten ikke kan: hvilken port og protokol der overhovedet forlader dette netværk.

Tre netværksadfærder ligner hinanden fra klienten og kræver forskellige svar. Udgående 443 kan være åben, kun en proxy kan være tilladt, eller 443 kan videresendes gennemsigtigt til en inspektionsboks, der ikke kan læse, hvad den bærer. Den første løses af profilændringen nedenfor, den anden af proxyindstillinger, og den tredje kan fuldføre et håndtryk og derefter gå i stå, når inspektøren beslutter, at den ikke kan lide strømmen. At vide, hvilken du står over for, er forskellen mellem en ændring på ti minutter og en eftermiddag med geninstallation af klienter.

Flyt lytteren og profilen sammen

På serversiden skal du sætte lytteren til det, netværket tillader: port 443 og proto tcp i serverkonfigurationen, genstart derefter tjenesten og bekræft socketten med ss -lntp. På klientsiden skal profilen være enig, fordi transport og port ligger uden for tunnelen: proto tcp og port 443 i .ovpn, eller de tilsvarende felter på appens indstillingsskærm. En profil, der stadig peger på UDP 1194, fejler præcis som før, og fristelsen er at give en firewall skylden, som allerede er rettet. Hvis den samme vært også svarer på HTTPS på 443, kan de to lyttere ikke dele den adresse og protokol; giv VPN'en en anden adresse eller sæt en demultiplekser foran.

Følg den første forbindelse med tcpdump -ni any port 443 i begge ender. Pakker, der forlader klienten og aldrig ankommer, betyder, at netværket alligevel filtrerer, eller at adressen i profilen ikke er den, du antager. Pakker, der ankommer uden svar, sender dig tilbage til serverloggen, hvor en protokolmismatch straks viser sig som en droppet pakke.

Når kun en proxy slipper ud af netværket

Nogle gæstenetværk tillader intet andet end en HTTP-proxy, hvilket er en anden begrænsning end en lukket port og udelukker mere end OpenVPN. Klienter, der kun taler PPTP, L2TP/IPsec eller bar IPsec, har ingen vej igennem en sådan, fordi de konstruktioner forventer, at deres ydre protokol når serveren direkte. OpenVPN kan, med http-proxy proxy.example.net 8080 i klientprofilen, forudsat at proxyen tillader CONNECT-metoden til din port. En SOCKS-proxy er endnu nemmere, fordi den videresender strømmen uden at bekymre sig om, hvad der er indeni.

Hvor klienten ikke har proxyunderstøttelse, er en SSH-tunnel over 443 normalt det, der er tilbage. Den tilføjer et andet lag, og netværkets operatør har måske en mening om det, så behandl den som en bro til én rejse snarere end som en arkitektur.

Beregn prisen på fallbacken, før du beholder den

TCP inde i TCP har en kendt pris. Når den ydre forbindelse er TCP og nyttelasten også er TCP, udløser et tabt segment gensendelse på begge lag, og den indre forbindelse bakker væk fra et tab, den ikke kan se. Browsing overlever det; interaktive sessioner og opkald mærker det. Behold TCP 443-lytteren som fallback til netværk, der kræver det, og lad UDP være standard for alt, der stadig slipper det igennem.

Noter valget i profilnavnet og i supportnoterne: hvilken port, hvilken protokol og hvilket netværk der udløste det. Spørg derefter netværkets administrator, om den port forbliver åben efter næste udstyrsudskiftning, fordi en fallback, der stille forsvinder, er værre end ingen fallback.