VPN-ul se conectează acasă, dar expiră pe Wi-Fi-ul hotelului

Laptopul se alătură Wi-Fi-ului de acasă, clientul se conectează în trei secunde, iar același profil eșuează la hotel o oră mai târziu. Între timp nu s-a actualizat nimic. Parcurgerea acestui lucru cu un client în față înseamnă în principal să știi care eroare aparține cărei etape, pentru că informația utilă este în codul pe care clientul îl afișează, nu în faptul că a eșuat. Parcurge cei patru pași de mai jos în ordine și vei ști dacă te-a refuzat un nume, un pachet, un port sau o politică.

Citește codul de eroare ca pe o etapă, nu ca pe o sentință

Clientul atinge trei repere separate înainte să existe un tunel. Rezolvă numele serverului, primește un răspuns de la ceva din rețea și negociază o asociere de securitate. Fiecare reper are propriul mesaj de eșec, iar Windows în special este generos cu coduri distincte odată ce știi cărei etape aparțin.

Două dintre acele coduri înseamnă că rețeaua este nevinovată. Un 789 înseamnă că pachetele circulau și cele două capete nu erau de acord asupra criptării, ceea ce este o problemă de configurare pe care o poți rezolva acasă. Un 868 înseamnă că niciun pachet nu a trebuit să iasă, deci proiectarea tunelului este irelevantă până când numele este rezolvat. Încadrarea codului în etapa corectă economisește mai mult timp decât orice captură, pentru că îți spune care dintre următorii trei pași poate fi sărit.

Fii precaut în mod corespunzător dacă clientul nu este Windows. Clienții terți reduc cea mai mare parte din asta la "conexiune eșuată", motiv pentru care următorii doi pași nu se bazează deloc pe mesaj.

Verifică numele înainte să dai vina pe tunel

Rețelele hotelurilor și aeroporturilor interceptează constant DNS, iar un resolver care răspunde cu o adresă de portal produce o eroare care arată exact ca un server mort. Compară ce spune resolverul local cu ce spune unul public:

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

Dacă cele două răspunsuri diferă, ești dirijat și restul diagnosticului este irosit până când asta se rezolvă. În special o adresă de portal va accepta bucuros conexiunea TCP și apoi se va bloca, motiv pentru care poate părea o blocare de firewall când testezi cu un browser.

Acum confirmă că adresa pe care vrei să o atingi este cea folosită. Unii clienți memorează în cache rezolvarea anterioară pentru toată durata de viață a profilului, așa că o reconectare după schimbarea DNS merge tot la adresa veche. Închide complet clientul înainte de a retesta, în loc să apeși deconectare și conectare în aceeași fereastră.

Află care pachet exterior dispare

Tunelul are un flux exterior care aparține în întregime drumului dintre tine și server, iar acel flux este cel pe care echipamentele intermediare îl clasifică și îl aruncă. Capturează-l pe client, apoi compară o rețea care funcționează cu cea care eșuează. Pe Windows captura încorporată este suficientă pentru o primă privire:

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

Ce vrei să vezi este dacă pachetele tale ies măcar și dacă se întoarce ceva. Pachete afară fără nimic înapoi înseamnă că drumul sau capătul îndepărtat le aruncă; dacă nu iese nimic, clientul nu a ajuns niciodată să trimită, ceea ce trimite înapoi la rezolvarea numelor sau la o politică locală de firewall.

Repetă același test pe un hotspot de telefon. Este cea mai informativă comparație de care dispui, pentru că scoate din drum fiecare cutie din hotel păstrând identice laptopul, clientul și datele de acces. Dacă tunelul urcă pe hotspot, oprește-te din privit serverul. Dacă eșuează și acolo, ai o problemă de client sau de cont pe care rețeaua nu o cauza niciodată.

Schimbă un transport și testează din nou

Odată ce știi că fluxul exterior este aruncat, întrebarea practică este ce flux permite rețeaua. Majoritatea rețelelor restricționate permit TCP 443 spre exterior pentru că altfel nu ar putea funcționa, așa că mutarea ascultătorului acolo este răspunsul obișnuit. Pe OpenVPN acesta este un comutator pe partea clientului până când serverul este schimbat:

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

Clienții IPsec au un comutator echivalent în propriile panouri de setări, descris de obicei ca IPsec peste TCP sau traversare NAT. Schimbarea lui este și ea un diagnostic: dacă tunelul urcă peste TCP și moare peste UDP, ai dovedit că rețeaua filtrează UDP și ai găsit și setarea de care vei avea nevoie la fiecare vizită în acel loc.

Rezistă tentației de a dezactiva funcții ale routerului la prima încercare. Dezactivarea inspecției cu stare sau a protecției anti-inundație într-o rețea de hotel nu îți este oricum disponibilă, iar pe echipamentul propriu schimbă o protecție reală pe un singur laptop. Notează ce setare a schimbat rezultatul, apoi pune-o la loc și caută un transport pe care rețeaua îl permite deja.

Verifică același profil în a doua rețea

Înainte să închizi tichetul, dovedește că schimbarea a supraviețuit ieșirii din clădire. Reconectează-te în rețeaua originală cu setările originale, captează primele treizeci de secunde și confirmă că clientul ajunge în aceeași stare ca pe hotspot:

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

Distincția pe care o dezvăluie ultima comandă merită păstrată: profilul poate raporta un tunel conectat în timp ce rutarea din interior este greșită, iar asta produce "VPN-ul este pornit, dar nimic nu funcționează", care este un alt articol. Dacă tipul tunelului s-a schimbat după editarea ta, profilul nu este cel pe care l-ai testat.

Apoi scrie constatarea acolo unde se va uita următoarea persoană. "Profilul companiei are nevoie de TCP 443 în acest loc; UDP 500 este filtrat de hotel" este o propoziție pe care un coleg poate acționa. "VPN-ul este instabil în hoteluri" nu este, și garantează că aceeași oră va fi irosită din nou luna viitoare.