Proč profil OpenVPN doma funguje, ale v hotelu selže

Kancelářská Wi-Fi a hotelový pokoj mohou stejnému notebooku nabídnout dvě velmi odlišné sítě a profil mezi nimi o tom nic neví. To, co doma funguje, předpokládá vstřícné odchozí spojení, funkční překlad jmen a místní podsíť, která se nepřekrývá s ničím, co tunel přenáší. Každý z těchto předpokladů může selhat samostatně.

Užitečný způsob ladění je brát síť jako čtyři samostatné skutečnosti a pak je zkoušet popořadě. Hádání o profilu nejdřív obvykle přinese změnu, která nic nespraví a zakryje důkazy.

Čtyři síťové skutečnosti se mezi místy mění

První skutečnost je, zda vás místní síť vůbec pustí ven. Přihlašovací portál pustí zařízení na přihlašovací stránku a zablokuje všechno ostatní, dokud se stránka nedokončí, což znamená, že tunel nemůže začít, ať je profil sebevíc správný.

Druhá je překlad jmen. Portál, který zachytává DNS, odpovídá na každý dotaz svou vlastní adresou, takže se jméno hostitele VPN přeloží na portál a klient se pokusí postavit tunel k webové stránce.

Třetí je filtrování přenosu. Sítě, které chtějí povolit jen prohlížení, propustí TCP 443 na libovolné cíle a zahodí téměř všechno ostatní včetně UDP.

Čtvrtá je adresování. Místní podsíť se může překrývat se sítí za tunelem, nebo odchozí spojení nemusí nabízet vůbec žádnou použitelnou cestu IPv4.

Překlad jmen a přihlašovací portál

Nahraďte jméno hostitele v profilu číselnou adresou serveru a zkuste to znovu. Pokud se IP připojí a jméno ne, na vině je překlad jmen a profil sám je v pořádku.

Otevřete prohlížeč a zkuste obyčejnou HTTP stránku, než se dotknete VPN. Přesměrování na přihlašovací stránku znamená, že portál ještě čeká; dokončete ho a pak se připojte znovu. Mnoho hotelů také po několika hodinách ukončí relaci, což vypadá jako odpolední odpojení, ne jako problém s přihlášením.

Pokud selže i číselná adresa, překlad jmen to není, takže přejděte k přenosu. Ponechte si adresu, kterou jste testovali, protože další kontrole řekne, zda pakety vůbec opustily počítač.

Filtrování přenosu: nejdřív UDP, TCP 443 jako záloha

Tok OpenVPN přes UDP 1194 nevypadá jako nic, co hotelový firewall zná, takže se zahodí bez chyby. Klient to zkouší znovu, dokud nevyprší jeho časový limit, a uživatel vidí spojení, které se nikdy nenaváže, místo odmítnutí. Firewally, které se tak chovají, zahazování málokdy zaznamenají někam, kde to uvidíte. Nepřítomnost odmítnutí je sama stopou.

TCP 443 je spolehlivá záloha, protože síť ho nedokáže rozeznat od běžného HTTPS. Použijte TCP profil operátora, když existuje, protože i server musí poslouchat na tomto přenosu a portu; změna jen na klientovi vede k jinému druhu selhání. Pokud TCP profil neexistuje, zeptejte se operátora, místo abyste ho vymýšleli úpravou portu. Strana serveru musí souhlasit a nesoulad znovu vypadá jako problém firewallu.

Počítejte s cenou ve výkonu. TCP v TCP zesiluje opakované přenosy na ztrátovém spoji, takže funkční TCP tunel může být v přetížené hotelové síti i tak pomalý. To je výměna za dosažitelnost, ne závada, kterou je třeba honit.

Kolize adres a odchozí spoje bez IPv4

Tunel se může navázat a přesto nic nepřenášet. Když místní LAN a vzdálená síť sdílejí předponu jako 192.168.1.0/24, klient považuje vzdáleného hostitele za přímo připojeného a pošle paket na místní spoj místo do tunelu. Příznakem je úspěšné spojení s jednou nedostupnou podsítí, což se snadno přečte jako problém trasy na straně serveru.

Trvalé řešení je přesunout vzdálenou LAN do neobvyklého privátního rozsahu. Volba rozsahu, který doma nikdo nepoužívá, třeba 10.42.0.0/24, zabrání problému pro každé budoucí místo místo jednoho. Místní obejití je vyhýbat se tomu hotelu, hotspotu nebo routeru, což není řešení vůbec.

Mobilní odchozí spoje přidávají dvě varianty. NAT na úrovni operátora znamená, že příchozí spojení nedorazí, což je důležité, pokud hostujete server, ale ne pro odchozího klienta. APN nastavený jen na IPv6 s překladem NAT64 může selhat u klienta, který trvá na skutečné cestě IPv4, a obvyklou nápravou je změnit protokol APN na IPv4 nebo dvojí zásobník.

Příznaky po navázání tunelu

Tunel, který se připojí a pak ztichne, bývá problém keepalive nebo MTU, ne zablokovaný port. Spojení, které spadne po pevném počtu minut, ukazuje na časovač keepalive nebo opětovného vyjednávání. Nastavte klienta, aby zkoušel protějšek a restartoval se, když odpovědi přestanou, a otestujte menší MTU tunelu, pokud pingy procházejí, ale velké přenosy se zaseknou.

Než požádáte o pomoc, napište si tři věci: adresu, kterou jste zkoušeli a zda odpověděla, přenos a port, které jste použili, a místní podsíť sítě, která selhala. Společně oddělují překlad jmen od filtrování přenosu a od kolize adres, což jsou příčiny, které vydrží střet s důkazy.