OpenVPN ansluter inte på hotell-Wi-Fi? Prova TCP 443

Öppna klienten, tryck Anslut och läs statusraden i stället för dialogrutan som följer. En profil som stannar på Ansluter eller Väntar på server efter ett hotell-, campus- eller mobilt nätverk har oftast tappat transporten någonstans på vägen, inte sina inloggningsuppgifter. Nästa användbara steg är att ta reda på vad det nätverket bär innan du rör servern. Ändra ingenting förrän samma profil har fungerat någon annanstans.

Testa först från en telefonhotspot. Om tunneln kommer upp där är servern, certifikatet och kontot i ordning, och den enda variabel som återstår är nätverket framför dig.

Börja vid klienten: läs statusraden

Statusraden talar om vilket steg som misslyckades. En klient som fastnat på Ansluter löser fortfarande upp värdnamnet eller öppnar den yttre socketen; en som når Väntar på server har en väg men inget svar; en som autentiserar och sedan faller har ett helt annat problem. Klientloggen och profilens egna remote- och proto-fält visar vad klienten försöker göra, och --verb 4 på en kommandorads klient skriver ut samma detalj. Det är jämförelsen med nätverket framför dig som gör 'VPN:et är blockerat' till ett konkret påstående.

Sedan undersök nätverket med verktygen du redan har. nc -vzu 203.0.113.10 1194 skickar ett UDP-datagram, curl -v telnet://203.0.113.10:443 rapporterar om TCP-handskakningen fullbordas, och en webbläsare som laddar en HTTPS-sida bevisar bara att utgående 443 når den enda värden. Små undersökningar svarar på det VPN-klienten inte kan: vilken port och vilket protokoll som överhuvudtaget lämnar det här nätverket.

Tre nätverksbeteenden ser likadana ut från klienten och kräver olika svar. Utgående 443 kan vara öppen, bara en proxy kan vara tillåten, eller 443 kan vidarebefordras transparent till en inspektionslåda som inte kan läsa vad den bär. Det första åtgärdas av profiländringen nedan, det andra av proxyinställningar, och det tredje kan fullborda en handskakning och sedan stanna när inspektören bestämmer sig för att den inte gillar flödet. Att veta vilken av de tre du står inför är skillnaden mellan en ändring på tio minuter och en eftermiddag med ominstallation av klienter.

Flytta lyssnaren och profilen tillsammans

På serversidan ställer du lyssnaren på det nätverket tillåter: port 443 och proto tcp i serverkonfigurationen, starta sedan om tjänsten och bekräfta socketen med ss -lntp. På klientsidan måste profilen stämma, eftersom transport och port ligger utanför tunneln: proto tcp och port 443 i .ovpn, eller motsvarande fält i appens inställningsskärm. En profil som fortfarande riktas mot UDP 1194 misslyckas precis som förut, och frestelsen är att skylla på en brandvägg som redan är reparerad. Om samma värd också svarar HTTPS på 443 kan de två lyssnarna inte dela den adressen och protokollet; ge VPN:et en andra adress eller sätt en demultiplexer framför.

Följ den första anslutningen med tcpdump -ni any port 443 i båda ändar. Paket som lämnar klienten och aldrig kommer fram betyder att nätverket filtrerar trots allt, eller att adressen i profilen inte är den du antar. Paket som kommer fram utan svar skickar dig tillbaka till serverloggen, där ett protokollavvikelse omedelbart visar sig som ett förkastat paket.

När bara en proxy tar sig ut ur nätverket

Vissa gästnätverk tillåter ingenting annat än en HTTP-proxy, vilket är en annan begränsning än en stängd port och utesluter mer än OpenVPN. Klienter som bara talar PPTP, L2TP/IPsec eller bar IPsec har ingen väg igenom en sådan, eftersom de konstruktionerna förväntar sig att deras yttre protokoll når servern direkt. OpenVPN kan, med http-proxy proxy.example.net 8080 i klientprofilen, förutsatt att proxyn tillåter CONNECT-metoden till din port. En SOCKS-proxy är ännu enklare, eftersom den vidarebefordrar flödet utan att bry sig om vad som finns inuti.

Där klienten saknar proxy-stöd är en SSH-tunnel över 443 vanligtvis det som återstår. Den lägger till ett andra lager, och nätverkets operatör kan ha en åsikt om det, så behandla den som en bro för en resa och inte som en arkitektur.

Prissätt reservvägen innan du behåller den

TCP inuti TCP har en känd kostnad. När den yttre anslutningen är TCP och nyttolasten också är TCP utlöser ett förlorat segment omsändning på båda lagren, och den inre anslutningen backar från en förlust den inte kan se. Bläddring tål det; interaktiva sessioner och samtal känner av det. Behåll TCP 443-lyssnaren som reserv för nätverk som kräver den, och låt UDP vara standard för allt som fortfarande släpper igenom den.

Skriv valet i profilnamnet och i supportanteckningarna: vilken port, vilket protokoll och vilket nätverk som föranledde det. Fråga sedan nätverkets administratör om den porten stannar öppen efter nästa utrustningsbyte, eftersom en reserv som tyst försvinner är värre än ingen reserv alls.