A VPN otthon csatlakozik, de a hotel Wi-Fi-jén időtúllépésbe fut

A laptop csatlakozik az otthoni Wi-Fi-hez, a kliens három másodperc alatt kapcsolódik, majd ugyanaz a profil egy órával később a hotelben elbukik. Közben semmi nem frissült. Ennek végigjárása egy előtted ülő ügyféllel főleg arról szól, hogy tudod, melyik hiba melyik szakaszhoz tartozik, mert a hasznos információ abban a kódban van, amit a kliens kiír, nem abban, hogy elbukott. Járd végig az alábbi négy lépést sorrendben, és tudni fogod, hogy egy név, egy csomag, egy port vagy egy szabályzat utasított el.

Olvasd a hibakódot szakaszként, ne ítéletként

A kliens három külön mérföldkőhöz ér, mielőtt alagút létezne. Feloldja a kiszolgáló nevét, választ kap valamitől a hálózaton, és biztonsági társítást tárgyal. Minden mérföldkőnek megvan a maga hibaüzenete, és a Windows különösen bőkezű a különböző kódokkal, ha egyszer tudod, melyik szakaszhoz tartoznak.

Ezek közül két kód azt jelenti, hogy a hálózat ártatlan. A 789 azt jelenti, hogy a csomagok folytak, és a két vég nem értett egyet a titkosításban, ami konfigurációs probléma, és otthon javítható. A 868 azt jelenti, hogy egyetlen csomagnak sem kellett kimennie, tehát az alagút terve irreleváns, amíg a név fel nem oldódik. A kód helyes szakaszba sorolása több időt spórol bármely rögzítésnél, mert megmondja, melyiket hagyhatod ki a következő három lépés közül.

Légy megfelelően óvatos, ha a kliens nem Windows. A harmadik féltől származó kliensek a legtöbbet "sikertelen kapcsolódás"-ra zsugorítják, ezért a következő két lépés egyáltalán nem támaszkodik az üzenetre.

Ellenőrizd a nevet, mielőtt az alagutat okolnád

A hotel- és repülőtéri hálózatok folyamatosan elfogják a DNS-t, és a portálcímekkel válaszoló feloldó olyan hibát okoz, amely pontosan úgy néz ki, mint egy halott kiszolgáló. Hasonlítsd össze, mit mond a helyi feloldó azzal, mit mond egy nyilvános:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Ha a két válasz eltér, átirányítanak, és a diagnózis többi része addig kárba vész, amíg ez meg nem oldódik. Különösen a portálcím fogadja szívesen a TCP-kapcsolatot, majd megakad, ezért tűnhet tűzfalbóloknak, amikor böngészővel tesztelsz.

Most erősítsd meg, hogy az a cím van használatban, amelyet el akarsz érni. Egyes kliensek a korábbi feloldást a profil teljes élettartamára gyorsítótárazzák, így a DNS-váltás utáni újracsatlakozás még mindig a régi címre megy. Teljesen zárd be a klienst az újratesztelés előtt, ahelyett hogy ugyanabban az ablakban nyomnád a bontás és csatlakozás gombot.

Derítsd ki, melyik külső csomag tűnik el

Az alagútnak van egy külső folyama, amely teljesen a közted és a kiszolgáló közötti úthoz tartozik, és pont ezt a folyamot osztályozzák és dobják el a köztes dobozok. Rögzítsd a kliensen, majd hasonlíts össze egy működő hálózatot a hibázóval. Windowson a beépített rögzítés elég egy első pillantásra:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Azt akarod látni, hogy a csomagjaid egyáltalán kimennek-e, és hogy jön-e vissza valami. Kifelé menő csomagok visszaérkezés nélkül azt jelentik, hogy az útvonal vagy a távoli vég eldobja őket; ha semmi nem megy ki, a kliens soha nem jutott el a küldésig, ami a névfeloldásra vagy egy helyi tűzfalszabályra mutat vissza.

Ismételd meg ugyanezt a tesztet egy telefonos hotspoton. Ez az egyetlen leghasznosabb összehasonlítás, ami a rendelkezésedre áll, mert kiveszi az útból a hotel minden dobozát, miközben a laptop, a kliens és a hitelesítő adatok ugyanazok maradnak. Ha az alagút feljön a hotspoton, hagyd abba a kiszolgáló nézegetését. Ha ott is elbukik, kliens- vagy fiókproblémád van, amelyet a hálózat soha nem okozott.

Változtass egy átvitelen, és tesztelj újra

Ha egyszer tudod, hogy a külső folyam eldobásra kerül, a gyakorlati kérdés az, melyik folyamot engedi a hálózat. A legtöbb korlátozott hálózat engedi a kimenő TCP 443-at, mert másképp nem tud működni, ezért a figyelő áthelyezése oda a szokásos válasz. Az OpenVPN esetében ez kliensoldali kapcsoló, amíg a kiszolgálót nem módosítják:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

Az IPsec-klienseknek saját beállítási paneljükön van egy egyenértékű kapcsoló, amelyet általában IPsec TCP felett vagy NAT-átjárás néven írnak le. Ennek átállítása is diagnózis: ha az alagút TCP felett feljön és UDP felett meghal, bebizonyítottad, hogy a hálózat szűri az UDP-t, és megtaláltad azt a beállítást is, amelyre minden ottani látogatáskor szükséged lesz.

Állj ellen a kísértésnek, hogy első próbálkozásra kikapcsold az útválasztó funkcióit. Az állapotfigyelő ellenőrzés vagy az árvízvédelem kikapcsolása egy hotelhálózaton amúgy sem elérhető számodra, a saját eszközödön pedig valódi védelmet cserél egyetlen laptopra. Jegyezd fel, melyik beállítás változtatta meg az eredményt, majd tedd vissza, és keress olyan átvitelt, amelyet a hálózat már enged.

Ellenőrizd ugyanazt a profilt a második hálózaton

Mielőtt lezárod a jegyet, bizonyítsd, hogy a változás túlélte az épület elhagyását. Csatlakozz újra az eredeti hálózaton az eredeti beállításokkal, rögzítsd az első harminc másodpercet, és erősítsd meg, hogy a kliens ugyanabba az állapotba jut, mint a hotspoton:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Érdemes megtartani a különbséget, amelyet az utolsó parancs feltár: a profil jelenthet csatlakoztatott alagutat, miközben a benne lévő útválasztás hibás, és ez "a VPN fel van csatlakozva, de semmi nem működik" kimenetet adja, ami egy másik cikk. Ha a szerkesztésed után megváltozott az alagút típusa, a profil nem az, amelyet teszteltél.

Ezután írd le a leletet oda, ahol a következő ember nézni fogja. "A vállalati profilnak ezen a helyen TCP 443 kell; az UDP 500-at a hotel szűri" olyan mondat, amelyre egy kolléga cselekedhet. "A VPN instabil a hotelekben" nem az, és ez garantálja, hogy ugyanaz az óra jövő hónapban újra elmegy.