Kumokonekta ang VPN sa bahay pero nag-time out sa Wi-Fi ng hotel
Parehong laptop, parehong account, ibang network. Basahin ang error code bilang isang yugto, suriin ang pangalan, pagkatapos ay hulihin ang panlabas na packet bago baguhin ang anumang setting.
Sumasali ang laptop sa Wi-Fi ng bahay, kumokonekta ang client sa tatlong segundo, at nabibigo ang parehong profile sa hotel makalipas ang isang oras. Walang na-update sa pagitan. Ang pagdaan dito kasama ang isang kliyenteng nasa harap mo ay tungkol sa pag-alam kung aling error ang kabilang sa aling yugto, dahil ang kapaki-pakinabang na impormasyon ay nasa code na ipinapasa ng client, hindi sa katotohanang nabigo ito. Gawin ang apat na hakbang sa ibaba nang sunod-sunod at malalaman mo kung pangalan, packet, port o patakaran ang tumanggi sa iyo.
Basahin ang error code bilang yugto, hindi bilang hatol
Naabot ng client ang tatlong magkakahiwalay na milestone bago umiral ang tunnel. Niresolba nito ang pangalan ng server, nakakakuha ito ng sagot mula sa isang bagay sa network, at nakikipag-usap ito sa isang security association. Bawat milestone ay may sariling mensahe ng pagkabigo, at ang Windows lalo na ay bukas-palad sa magkakaibang code kapag alam mo kung aling yugto sila kabilang.
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
Dalawang sa mga code na iyon ay nangangahulugang inosente ang network. Ang 789 ay nangangahulugang dumadaloy ang mga packet at hindi nagkasundo ang dalawang dulo sa crypto, na problema sa configuration na maaari mong ayusin sa bahay. Ang 868 ay nangangahulugang walang packet na kailangang lumabas, kaya ang disenyo ng tunnel ay walang kaugnayan hanggang maresolba ang pangalan. Ang pag-uuri ng code sa tamang yugto ay nakakatipid ng mas maraming oras kaysa anumang capture, dahil sinasabi nito kung alin sa tatlong susunod na hakbang ang laktawan.
Maging wasto ang pag-iingat kung ang client ay hindi Windows. Pinagsasama-sama ng mga third-party na client ang karamihan nito sa "nabigo ang koneksyon", kaya ang susunod na dalawang hakbang ay hindi umaasa sa mensahe.
Suriin ang pangalan bago sisihin ang tunnel
Ang mga network ng hotel at airport ay patuloy na humaharang sa DNS, at ang isang resolver na sumasagot ng portal address ay gumagawa ng pagkabigong kamukhang-kamukha ng patay na server. Ihambing ang sinasabi ng lokal na resolver sa sinasabi ng pampublikong resolver:
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"
Kung magkaiba ang dalawang sagot, ginagabayan ka at ang natitirang diagnostic ay walang saysay hanggang maayos iyon. Ang portal address lalo na ay malugod na tatanggapin ang TCP connection at pagkatapos ay titigil, kaya maaaring magmukhang firewall block kapag nagsubok ka gamit ang browser.
Ngayon, kumpirmahin na ang address na nais mong maabot ay ang ginagamit. Ang ilang client ay nag-cache ng nakaraang resolution sa buong buhay ng profile, kaya ang muling pagkonekta pagkatapos ng pagbabago ng DNS ay pumupunta pa rin sa lumang address. Isara nang mabuti ang client bago muling subukan, sa halip na pindutin ang idiskonekta at kumonekta sa parehong window.
Alamin kung aling panlabas na packet ang nawawala
Ang tunnel ay may panlabas na daloy na ganap na kabilang sa landas sa pagitan mo at ng server, at iyon ang daloy na inuuri at itinatapon ng mga intermediate box. Hulihin ito sa client, pagkatapos ay ihambing ang gumaganang network sa nabibigo. Sa Windows, sapat ang built-in na capture para sa unang tingin:
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl
Ang nais mong makita ay kung ang iyong mga packet ay lumalabas, at kung may bumabalik. Mga packet palabas na walang bumabalik ay nangangahulugang itinatapon ito ng landas o ng malayuang dulo; kung walang lumalabas, hindi kailanman nakarating ang client sa pagpapadala, na tumutukoy pabalik sa resolution ng pangalan o sa lokal na patakaran ng firewall.
Ulitin ang parehong pagsubok sa hotspot ng telepono. Ito ang tanging pinaka-kaalaman na paghahambing na mayroon ka, dahil inaalis nito sa landas ang bawat kahon sa hotel habang nananatiling pareho ang laptop, client at mga kredensyal. Kung bumangon ang tunnel sa hotspot, huminto sa pagtingin sa server. Kung mabibigo rin doon, mayroon kang problema sa client o account na hindi kailanman dahilan ng network.
Palitan ang isang transport at subukan muli
Kapag alam mo na itinatapon ang panlabas na daloy, ang praktikal na tanong ay aling daloy ang pinapayagan ng network. Karamihan ng restricted na network ay pinapayagan ang palabas na TCP 443 dahil hindi sila makakagana kung hindi, kaya ang ilipat ang listener doon ang karaniwang sagot. Sa OpenVPN iyon ay switch sa panig ng client hanggang mabago ang server:
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4
Ang mga client ng IPsec ay may katumbas na switch sa kanilang sariling mga panel ng setting, karaniwang inilarawan bilang IPsec sa ibabaw ng TCP o NAT traversal. Ang pagbabago nito ay diagnostic din: kung bumangon ang tunnel sa TCP at namatay sa UDP, napatunayan mong sinasala ng network ang UDP, at natagpuan mo rin ang setting na kakailanganin mo sa bawat pagbisita sa lugar na iyon.
Labanan ang tuksong patayin ang mga tampok ng router sa unang pagsubok. Ang patayin ang stateful inspection o flood protection sa network ng hotel ay hindi available sa iyo gayon pa man, at sa sarili mong kagamitan ito ay nagpapalit ng tunay na proteksyon para sa isang laptop. Itala kung aling setting ang nagbago ng resulta, pagkatapos ay ibalik ito at maghanap ng transport na pinapayagan na ng network.
I-verify ang parehong profile sa pangalawang network
Bago isara ang ticket, patunayan na ang pagbabago ay nakaligtas sa paglabas ng gusali. Kumonekta muli sa orihinal na network gamit ang orihinal na mga setting, hulihin ang unang tatlumpung segundo, at kumpirmahin na naabot ng client ang parehong estado na naabot nito sa hotspot:
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress
Ang pagkakaibang ibinubunyag ng huling command ay sulit na itago: ang profile ay maaaring mag-ulat ng konektadong tunnel habang mali ang routing sa loob nito, at gumagawa iyon ng "bukas ang VPN pero walang gumagana", na isa pang artikulo. Kung nagbago ang uri ng tunnel pagkatapos ng iyong pag-edit, ang profile ay hindi ang sinubukan mo.
Pagkatapos, isulat ang natuklasan sa lugar na titingnan ng susunod na tao. "Kailangan ng corporate profile ang TCP 443 sa site na ito; sinasala ng hotel ang UDP 500" ay isang pangungusap na maaaring kumilosan ng kasamahan. Ang "hindi stable ang VPN sa mga hotel" ay hindi, at ginagarantiyahan nito na ang parehong oras ay gugugulin muli sa susunod na buwan.