VPN prisijungia namuose, bet viešbučio Wi-Fi tinkle baigiasi laikas

Nešiojamasis prisijungia prie namų Wi-Fi, klientas prisijungia per tris sekundes, o tas pats profilis po valandos nepavyksta viešbutyje. Tarp to nieko nebuvo atnaujinta. Šio dalyko nagrinėjimas su klientu priešais pirmiausia reiškia žinoti, kuri klaida priklauso kuriam etapui, nes naudinga informacija yra kode, kurį klientas išspausdina, o ne tame, kad jis nepavyko. Atlikite keturis žemiau pateiktus veiksmus iš eilės ir žinosite, ar jus atmetė vardas, paketas, prievadas ar politika.

Skaitykite klaidos kodą kaip etapą, o ne kaip nuosprendį

Klientas pasiekia tris atskirus etapus, kol tunelio dar nėra. Jis išsprendžia serverio vardą, gauna atsakymą iš kažko tinkle ir derasi dėl saugumo asociacijos. Kiekvienas etapas turi savo nepavykimo pranešimą, o ypač Windows dosnus skirtingų kodų, kai žinote, kuriam etapui jie priklauso.

Du iš tų kodų reiškia, kad tinklas nekaltas. 789 reiškia, kad paketai ėjo ir abu galai nesutarė dėl šifravimo, o tai konfigūracijos problema, kurią galite ištaisyti namuose. 868 reiškia, kad nė vieno paketo nereikėjo išleisti, todėl tunelio konstrukcija nesvarbi, kol vardas neišspręstas. Kodo priskyrimas teisingam etapui sutaupo daugiau laiko nei bet koks užfiksavimas, nes pasako, kurį iš trijų kitų žingsnių praleisti.

Būkite atitinkamai atsargūs, jei klientas ne Windows. Trečiųjų šalių klientai didžiąją dalį to sutraukia į "ryšys nepavyko", todėl kiti du žingsniai visiškai nepasikliauja pranešimu.

Patikrinkite vardą prieš kaltindami tunelį

Viešbučių ir oro uostų tinklai nuolat perima DNS, o sprendiklis, atsakantis portalo adresu, sukuria nepavykimą, kuris atrodo lygiai kaip miręs serveris. Palyginkite, ką sako vietinis sprendiklis, su tuo, ką sako viešas:

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

Jei du atsakymai skiriasi, jus nukreipia, o likusi diagnostika bergždžia, kol tai nebus išspręsta. Ypač portalo adresas mielai priims TCP ryšį ir paskui užstrigs, todėl naršykle tikrinant tai gali atrodyti kaip ugniasienės blokavimas.

Dabar patvirtinkite, kad adresas, į kurį norite patekti, yra naudojamas. Kai kurie klientai kešuoja ankstesnį sprendimą visą profilio veikimo laiką, todėl pakartotinis prisijungimas po DNS pakeitimo vis tiek eina senu adresu. Prieš kartodami bandymą visiškai uždarykite klientą, o ne spauskite atjungti ir prijungti tame pačiame lange.

Išsiaiškinkite, kuris išorinis paketas dingsta

Tunelis turi išorinį srautą, kuris visiškai priklauso keliui tarp jūsų ir serverio, ir būtent tą srautą tarpinės dėžės klasifikuoja ir numeta. Užfiksuokite jį kliente, tada palyginkite veikiantį tinklą su nepavykstančiu. Windows pakanka įmontuoto fiksavimo pirmam žvilgsniui:

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

Norite pamatyti, ar jūsų paketai apskritai išeina, ir ar kas nors grįžta. Paketai lauk be nieko atgal reiškia, kad kelias arba tolimasis galas juos numeta; jei lauk nieko neišeina, klientas niekada nepasiekė siuntimo, o tai nurodo į vardų sprendimą arba vietinę ugniasienės politiką.

Pakartokite tą patį bandymą telefono hotspot'e. Tai vienintelis informatyviausias palyginimas, kurį turite, nes jis pašalina iš kelio kiekvieną viešbučio dėžę, o nešiojamasis, klientas ir prisijungimo duomenys lieka tie patys. Jei tunelis pakyla hotspot'e, nustokite žiūrėti į serverį. Jei ir ten nepavyksta, turite kliento ar paskyros problemą, kurios tinklas niekada nesukėlė.

Pakeiskite vieną transportą ir bandykite dar kartą

Kai žinote, kad išorinis srautas numetamas, praktinis klausimas yra, kokį srautą tinklas vis dėlto leidžia. Dauguma ribotų tinklų leidžia išeinantį TCP 443, nes kitaip negalėtų veikti, todėl klausytojo perkėlimas ten yra įprastas atsakymas. Su OpenVPN tai kliento pusės jungiklis, kol serveris nebus pakeistas:

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

IPsec klientai turi atitinkamą jungiklį savo nustatymų skydeliuose, paprastai apibūdinamą kaip IPsec per TCP arba NAT praėjimas. Jį pakeisti taip pat yra diagnostika: jei tunelis pakyla per TCP ir miršta per UDP, įrodėte, kad tinklas filtruoja UDP, ir taip pat radote nustatymą, kurio prireiks kiekvieną kartą lankantis toje vietoje.

Atsispirkite pagundai pirmu bandymu išjungti maršrutizatoriaus funkcijas. Išjungti būseninę patikrą ar apsaugą nuo potvynio viešbučio tinkle jums vis tiek neleidžiama, o savo įrangoje tai iškeičia tikrą apsaugą į vieną nešiojamąjį. Užsirašykite, kuris nustatymas pakeitė rezultatą, tada grąžinkite jį ir ieškokite transporto, kurį tinklas jau leidžia.

Patikrinkite tą patį profilį antrame tinkle

Prieš uždarydami bilietą, įrodykite, kad pakeitimas išgyveno išėjimą iš pastato. Prisijunkite iš naujo pradiniame tinkle su pradiniais nustatymais, užfiksuokite pirmąsias trisdešimt sekundžių ir patvirtinkite, kad klientas pasiekia tą pačią būseną kaip hotspot'e:

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

Skirtumą, kurį atskleidžia paskutinė komanda, verta išsaugoti: profilis gali pranešti apie prijungtą tunelį, nors maršrutizavimas jo viduje yra neteisingas, ir tai sukuria "VPN įjungtas, bet niekas neveikia", o tai kitas straipsnis. Jei po jūsų redagavimo tunelio tipas pasikeitė, profilis nėra tas, kurį bandėte.

Tada užrašykite išvadą ten, kur žiūrės kitas žmogus. "Įmonės profiliui šioje vietoje reikia TCP 443; UDP 500 filtruoja viešbutis" yra sakinys, kuriuo kolega gali vadovautis. "VPN nepastovus viešbučiuose" nėra, ir tai garantuoja, kad tą pačią valandą teks praleisti ir kitą mėnesį.