GVC na-stuck sa Acquiring IP: hindi ito problema sa password

Humihinto ang Global VPN Client sa Acquiring IP, at ang unang reaksyon ay i-type muli ang password o i-install muli ang client. Wala sa dalawa ang humahawak sa yugtong nabigo. Natapos na ang pagpapatunay bago pa humingi ng address ang client, kaya hindi ang mga kredensyal ang pumipigil sa iyo sa linyang iyon. Ang pumipigil sa iyo doon ay isang palitan ng DHCP na hindi pa tapos, at maaari itong ma-stuck sa tatlong magkaibang lugar.

Magkahiwalay na yugto ang pagpapatunay at pagtatalaga ng address

Pruweba muna ng GVC kung sino ka, pagkatapos ay humihingi ito ng mga setting para sa virtual adapter nito ayon sa patakarang itinalaga sa iyong koneksyon. Sunod-sunod na hakbang ito na may magkaibang senyales ng pagkabigo. Karaniwang nabibigo ang maling kredensyal nang mas maaga, gamit ang mensahe ng pagpapatunay o pakikipag-ayos sa halip na ang linya ng address.

Ipinapaliwanag ng ayos na iyon kung bakit walang binabago ang pag-reset ng password, bagong local na user o muling pag-install dito. Autorisado na ang client; naghihintay na ito ng lease na dapat ibigay ng gateway o ng DHCP partner nito. Kahit ang patakarang nagpapahintulot sa user pero walang itinatalagang saklaw ng address ay gumagawa ng eksaktong screen na ito.

Kaya ang unang kapaki-pakinabang na tanong ay hindi kung tama ang kredensyal, kundi aling patakaran ang itinalaga at ano ang sinasabi nito tungkol sa pag-address ng virtual adapter. Basahin ang aktwal na configuration ng koneksyong iyon sa halip na ang gumaganang screenshot ng katrabaho.

Saan talaga galing ang lease

Karaniwan ang dalawang modelo. Maaaring magpatakbo mismo ang firewall ng DHCP scope para sa mga VPN client, o ipasa nito ang kahilingan sa external na DHCP server sa internal network. Ang modelo ang tumutukoy kung aling log ang mahalaga at sino ang tatawagan.

Sa internal na modelo, tiyakin na umiiral pa ang scope, kabilang ito sa tamang interface at may libreng lease. Ang naubos na scope ay gumagawa ng client na perpektong nagpapatunay at hindi kailanman nakakatanggap ng address, at ang log ng gateway ay maaaring ipakita lamang ang kahilingan. Sa modelo ng pagpapasa, ang target ng pagpapasa, ang ruta pabalik sa saklaw ng VPN client at anumang internal na DHCP authorization ay dapat magtugma.

Isulat kung aling modelo ang ginagamit ng iyong deployment bago subukan ang anuman. Kalahati ng magkakasalungat na payo online ay ipinapalagay ang isa pa.

Maaaring nakaupo ang tunnel at nawawala pa rin ang lease

Ang naitatag na control connection ay nagpapatunay na gumana ang pakikipag-ayos, hindi na dumadaan ang tunnel data sa dalawang direksyon. Kailangan ng DHCP exchange ang kahilingan at tugon upang malampasan ang data path, at doon naninirahan ang mga setting ng encryption, patakaran para sa VPN zone at mga problema sa MTU.

Ang payo tungkol sa NAT traversal ang pinakamalinaw na halimbawa na mahalaga ang konteksto. Kailangan ng ilang landas na naka-on ito, ang iba ay gumagana lamang kapag naka-off, at ang NAT sa gitna kasama ang napagkasunduang koneksyon ang magpapasya kung alin. Ang bulag na pagbabago nito habang binabago rin ang mga setting ng client ay nangangahulugang hindi mo malalaman kung aling pagbabago ang nagbigay ng resulta. Itala ang napagkasunduang landas at ang ebidensya bago baguhin ang encapsulation.

Ang pag-restart ng home router ay kabilang sa parehong kategorya. Minsan inaalis nito ang sintomas, ngunit hindi tinutukoy kung bakit nabigo ang lease, at bumabalik ang problema sa susunod na koneksyon.

Lakarin ang landas ng lease nang sunod-sunod

Magsimula sa adapter at lumabas, upang ang bawat hakbang ay maaaring mabigo sa isang dahilan lamang:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

Ang address na gaya ng 169.254.x.x ay nangangahulugang umiiral ang adapter at wala itong natanggap na tugon, na tumuturo sa pinagmulan ng lease o sa data path. Ang tamang address sa saklaw ng VPN na may maling DNS entry ay ibang depekto: gumana ang lease at nagbigay ang patakaran ng hindi kumpletong setting. Ang adapter na hindi kailanman lumilitaw ay nangangahulugang hindi umabot ang client sa paggawa nito.

Kapag lumitaw ang lease, subukan ang aktwal na resource sa halip na magdeklara ng tagumpay sa linya ng address. Kung nabibigo pa rin ang access sa file o intranet, itago ang matagumpay na lease bilang ebidensya at magpatuloy sa paglutas ng pangalan o patakaran, dahil naiwan mo na ang orihinal na depekto.

Ang tala ng SonicWall tungkol sa virtual adapter naglilista ito ng ilang hiwalay na sangay, at ang mga lumang screenshot nito ay hindi dapat basahin bilang kasalukuyang mapa ng menu. Gamitin ito upang kumpirmahin ang yugtong naabot mo, hindi bilang checklist na ilalapat nang buo.