VPN konektiĝas hejme, sed templimo trafas ĝin en hotelaj Wi-Fi

La tekkomputilo aliĝas al la hejma Wi-Fi, la kliento konektiĝas en tri sekundoj, kaj la sama profilo fiaskas en la hotelo unu horon poste. Intere nenio estis ĝisdatigita. Trairi tion kun kliento antaŭ vi plejparte temas pri scii, kiu eraro apartenas al kiu etapo, ĉar la utila informo estas en la kodo, kiun la kliento presas, ne en la fakto, ke ĝi fiaskis. Trapasu la kvar paŝojn sube laŭorde kaj vi scios, ĉu nomo, paketo, pordo aŭ politiko rifuzis vin.

Legu la erarkodon kiel etapon, ne kiel verdikton

La kliento atingas tri apartajn etapojn antaŭ ol tunelo ekzistas. Ĝi solvas la servilan nomon, ĝi ricevas respondon de io en la reto, kaj ĝi interkonsentas sekurecan asocion. Ĉiu etapo havas sian propran fiaskan mesaĝon, kaj precipe Windows estas malavara per apartaj kodoj, unufoje vi scias, al kiu etapo ili apartenas.

Du el tiuj kodoj signifas, ke la reto estas senkulpa. 789 signifas, ke la paketoj fluis kaj la du finoj malkonsentis pri kriptado, kio estas agorda problemo, kiun vi povas ripari hejme. 868 signifas, ke neniu paketo iam ajn bezonis eliri, do la tunela dizajno estas malgrava ĝis la nomo solviĝos. Ordigo de la kodo en la ĝustan etapon ŝparas pli da tempo ol ajna kapto, ĉar ĝi diras al vi, kiun el la sekvaj tri paŝoj preterlasi.

Estu konvene singarda, se la kliento ne estas Windows. Flankaj klientoj kunfandas la plejparton de tio en "konekto fiaskis", tial la sekvaj du paŝoj tute ne fidas la mesaĝon.

Kontrolu la nomon antaŭ ol kulpigi la tunelon

Hotelaj kaj flughavenaj retoj konstante interkaptas DNS, kaj solvilo, kiu respondas per portala adreso, produktas fiaskon, kiu aspektas precize kiel morta servilo. Komparu, kion diras la loka solvilo, kun tio, kion diras publika solvilo:

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

Se la du respondoj malsamas, vi estas direktata kaj la resto de la diagnozo estas vana ĝis tio solviĝos. Precipe portala adreso volonte akceptos la TCP-konekton kaj poste haltos, tial ĝi povas aspekti kiel fajroŝirma blokado, kiam vi testas per retumilo.

Nun konfirmu, ke la adreso, kiun vi intencas atingi, estas la uzata. Iuj klientoj kaŝmemorigas la antaŭan solvon por la tuta vivo de la profilo, do rekonekto post la DNS-ŝanĝo ankoraŭ iras al la malnova adreso. Fermu la klienton tute antaŭ ol retesti, anstataŭ premi malkonekti kaj konekti en la sama fenestro.

Elkompreni, kiu ekstera paketo malaperas

La tunelo havas eksteran fluon, kiu tute apartenas al la vojo inter vi kaj la servilo, kaj ĝuste tiun fluon mezaj skatoloj klasifikas kaj forĵetas. Kaptu ĝin en la kliento, poste komparu funkciantan reton kun la fiaska. En Windows la enkonstruita kapto sufiĉas por unua rigardo:

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

Tio, kion vi volas vidi, estas ĉu viaj paketoj entute eliras kaj ĉu io revenas. Paketoj eksteren sen io reen signifas, ke la vojo aŭ la malproksima fino forĵetas ilin; nenio eksteren entute signifas, ke la kliento neniam atingis la sendadon, kio montras reen al nomsolvo aŭ al loka fajroŝirma politiko.

Ripetu la saman teston per poŝtelefona konekta punkto. Tio estas la ununura plej informa komparo disponebla al vi, ĉar ĝi forigas ĉiun skatolon en la hotelo el la vojo, konservante la tekkomputilon, la klienton kaj la legitimilojn identaj. Se la tunelo leviĝas en la konekta punkto, ĉesu rigardi la servilon. Se ĝi fiaskas ankaŭ tie, vi havas klientan aŭ kontan problemon, kiun la reto neniam kaŭzis.

Ŝanĝu unu transporton kaj retestu

Unufoje vi scias, ke la ekstera fluo estas forĵetata, la praktika demando estas, kiun fluon la reto tamen permesas. Plej multaj limigitaj retoj permesas eliran TCP 443 ĉar ili alie ne povas funkcii, do movi la aŭskultanton tien estas la kutima respondo. Ĉe OpenVPN tio estas ŝaltilo ĉe la klienta flanko ĝis la servilo ŝanĝiĝos:

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

IPsec-klientoj havas ekvivalentan ŝaltilon en siaj propraj agordaj paneloj, kutime priskribata kiel IPsec super TCP aŭ NAT-trapaso. Ŝanĝi ĝin ankaŭ estas diagnozo: se la tunelo leviĝas super TCP kaj mortas super UDP, vi pruvis, ke la reto filtras UDP, kaj vi ankaŭ trovis la agordon, kiun vi bezonos ĉiufoje, kiam vi vizitos tiun lokon.

Rezistu la tenton malŝalti ruteriajn funkciojn ĉe la unua provo. Malŝalti statoinspektadon aŭ inunda protekto en hotela reto tamen ne disponeblas al vi, kaj sur via propra aparataro ĝi interŝanĝas realan protekton kontraŭ unu tekkomputilo. Notu, kiu agordo ŝanĝis la rezulton, poste remetu ĝin kaj serĉu transporton, kiun la reto jam permesas.

Kontrolu la saman profilon en la dua reto

Antaŭ ol vi fermos la bileton, pruvu, ke la ŝanĝo postvivis la forlason de la konstruaĵo. Rekonektu en la origina reto kun la originaj agordoj, kaptu la unuajn tridek sekundojn, kaj konfirmu, ke la kliento atingas la saman staton kiel en la konekta punkto:

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

La distingo, kiun la lasta komando malkaŝas, indas esti konservata: la profilo povas raporti konektitan tunelon dum la ena vojigo estas malĝusta, kaj tio produktas "la VPN estas supre sed nenio funkcias", kio estas alia artikolo. Se la tunela tipo ŝanĝiĝis post via redakto, la profilo ne estas tiu, kiun vi testis.

Poste skribu la konstaton tien, kie la sekva persono rigardos. "La firmaaprofilo bezonas TCP 443 ĉe tiu loko; UDP 500 estas filtrita de la hotelo" estas frazo, pri kiu kolego povas agi. "VPN estas malfirma en hoteloj" ne estas, kaj ĝi garantias, ke la sama horo estos elspezita denove venontmonate.