Prečo profil OpenVPN doma funguje, ale v hoteli zlyhá

Kancelárska Wi-Fi a hotelová izba môžu tomu istému notebooku ponúknuť dve veľmi odlišné siete a profil medzi nimi o tom nič nevie. To, čo doma funguje, predpokladá ústretové odchádzajúce spojenie, funkčný preklad mien a miestnu podsieti, ktorá sa neprekrýva s ničím, čo tunel prenáša. Každý z týchto predpokladov môže zlyhať samostatne.

Užitočný spôsob ladenia je brať sieť ako štyri samostatné skutočnosti a potom ich skúšať po poriadku. Hádanie o profile najprv zvyčajne prinesie zmenu, ktorá nič neopraví a zakryje dôkazy.

Štyri sieťové skutočnosti sa medzi miestami menia

Prvá skutočnosť je, či vás miestna sieť vôbec pustí von. Prihlasovací portál pustí zariadenie na prihlasovaciu stránku a zablokuje všetko ostatné, kým sa stránka nedokončí, čo znamená, že tunel nemôže začať, nech je profil akokoľvek správny.

Druhá je preklad mien. Portál, ktorý zachytáva DNS, odpovedá na každú otázku svojou vlastnou adresou, takže sa názov hostiteľa VPN preloží na portál a klient sa pokúsi postaviť tunel k webovej stránke.

Tretia je filtrovanie prenosu. Siete, ktoré chcú povoliť len prehliadanie, prepúšťajú TCP 443 na ľubovoľné ciele a zahadzujú takmer všetko ostatné vrátane UDP.

Štvrtá je adresovanie. Miestna podsieti sa môže prekrývať so sieťou za tunelom, alebo odchádzajúce spojenie nemusí ponúkať vôbec žiadnu použiteľnú cestu IPv4.

Preklad mien a prihlasovací portál

Nahraďte názov hostiteľa v profile číselnou adresou servera a skúste to znova. Ak sa IP pripojí a názov nie, na vine je preklad mien a profil sám je v poriadku.

Otvorte prehliadač a skúste obyčajnú HTTP stránku, než sa dotknete VPN. Presmerovanie na prihlasovaciu stránku znamená, že portál ešte čaká; dokončite ho a potom sa pripojte znova. Mnohé hotely tiež po niekoľkých hodinách ukončia reláciu, čo vyzerá ako odpoludňajšie odpojenie, nie ako problém s prihlásením.

Ak zlyhá aj číselná adresa, preklad mien to nie je, takže prejdite k prenosu. Ponechajte si adresu, ktorú ste testovali, pretože ďalšej kontrole povie, či pakety vôbec opustili počítač.

Filtrovanie prenosu: najprv UDP, TCP 443 ako záloha

Tok OpenVPN cez UDP 1194 nevyzerá ako nič, čo hotelový firewall pozná, takže sa zahodí bez chyby. Klient to skúša znova, kým nevyprší jeho časový limit, a používateľ vidí spojenie, ktoré sa nikdy nenadviaže, namiesto odmietnutia. Firewally, ktoré sa takto správajú, zahadzovanie málokedy zaznamenajú niekam, kde to uvidíte. Neprítomnosť odmietnutia je sama stopou.

TCP 443 je spoľahlivá záloha, pretože sieť ho nedokáže rozlíšiť od bežného HTTPS. Použite TCP profil operátora, keď existuje, pretože aj server musí počúvať na tomto prenose a porte; zmena len na klientovi vedie k inému druhu zlyhania. Ak TCP profil neexistuje, opýtajte sa operátora, namiesto toho, aby ste ho vymýšľali úpravou portu. Strana servera musí súhlasiť a nesúlad znovu vyzerá ako problém firewallu.

Počítajte s cenou vo výkone. TCP v TCP zosilňuje opakované prenosy na stratovom spoji, takže funkčný TCP tunel môže byť v preťaženej hotelovej sieti aj tak pomalý. To je výmena za dosiahnuteľnosť, nie závada, ktorú treba naháňať.

Kolízie adries a odchádzajúce spoje bez IPv4

Tunel sa môže nadviazať a predsa nič neprenášať. Keď miestna LAN a vzdialená sieť zdieľajú predponu ako 192.168.1.0/24, klient považuje vzdialeného hostiteľa za priamo pripojeného a pošle paket na miestne spojenie namiesto do tunela. Príznakom je úspešné spojenie s jednou nedostupnou podsieti, čo sa dá ľahko nesprávne prečítať ako problém trasy na strane servera.

Trvalé riešenie je presunúť vzdialenú LAN do nezvyčajného súkromného rozsahu. Výber rozsahu, ktorý doma nikto nepoužíva, napríklad 10.42.0.0/24, zabráni problému pre každé budúce miesto namiesto jedného. Miestne obídenie je vyhýbať sa tomu hotelu, hotspotu alebo routeru, čo nie je riešenie vôbec.

Mobilné odchádzajúce spoje pridávajú dva varianty. NAT na úrovni operátora znamená, že prichádzajúce spojenia nedorazia, čo je dôležité, ak hostujete server, ale nie pre odchádzajúceho klienta. APN nastavený len na IPv6 s prekladom NAT64 môže zlyhať u klienta, ktorý trvá na skutočnej ceste IPv4, a obvyklou nápravou je zmeniť protokol APN na IPv4 alebo dvojitý zásobník.

Príznaky po nadviazaní tunela

Tunel, ktorý sa pripojí a potom stíchne, býva problém keepalive alebo MTU, nie zablokovaný port. Spojenie, ktoré padne po pevnom počte minút, ukazuje na časovač keepalive alebo opätovného vyjednávania. Nastavte klienta, aby skúšal protistranu a reštartoval sa, keď odpovede prestanú, a otestujte menší MTU tunela, ak pingy prechádzajú, ale veľké prenosy sa zaseknú.

Než požiadate o pomoc, napíšte si tri veci: adresu, ktorú ste skúšali a či odpovedala, prenos a port, ktoré ste použili, a miestnu podsieti siete, ktorá zlyhala. Spoločne oddeľujú preklad mien od filtrovania prenosu a od kolízie adries, a to sú príčiny, ktoré vydržia stretnutie s dôkazmi.