VPN sa Windows: itugma ang kliyente sa profile

Iniuulat ng Windows na konektado ang tunnel habang nag-time out pa rin ang pahina ng intranet, at ang profile ay galing sa taong matagal nang umalis. May dalawang magkahiwalay na pagkakamali sa likod ng estadong iyon: maling kliyente para sa file, at maling inaasahan tungkol sa saklaw ng tunnel. Ang paghihiwalay sa kanila ay tumatagal ng ilang command at nakakatipid ng muling pag-install. Wala sa dalawa ang naaayos sa pamamagitan ng restart.

Ang built-in na kliyente ay nag-aangkat lamang ng sarili nitong mga uri

May kasamang VPN client ang Windows na nakakaunawa ng ilang partikular na uri ng koneksyon, at hindi ito mag-aangkat ng OpenVPN na file o WireGuard configuration, anuman ang pangalan ng file. Ang mga iyon ay nangangailangan ng sarili nilang software, na naka-install mula sa verified na download page ng vendor. Ang pamilyar na entry sa menu ng network ay hindi patunay na sinusuportahan ito ng server, at ang profile na pinangalanang muli gamit ang pamilyar na extension ay maling file pa rin. Dapat tumugma ang uri ng koneksyon sa ibinigay ng operator, hindi sa basta ibinibigay ng menu.

Para sa native na koneksyon, idagdag ito sa mga setting ng network at i-type nang eksakto ang mga value na ibinigay sa iyo. Ang IKEv2 na batay sa certificate at ang entry point na may username at password ay magkaibang configuration kahit pareho silang napupunta sa ilalim ng iisang heading. Kung may koneksyon nang ibinibigay ang managed na device, gamitin iyon sa halip na magtayo ng pangalawa sa tabi nito.

Hindi mapagpapalit ang mga hakbang sa pag-sign in

Maaaring mangailangan ang isang koneksyon ng username at password, client certificate, interactive na prompt o ilan sa mga ito nang sunod-sunod. Ang passphrase ng private key ay nagbubukas ng key at hindi ito ang password ng serbisyo, kahit pareho silang tina-type sa iisang dialog. Ang babala ng certificate ay tungkol sa pagkakakilanlan o pagtitiwala, hindi sa kung tama ang baybay ng pangalan ng account. Ang pagbasa kung alin sa tatlo ang nabigo ang nagtatakda ng susunod na hakbang.

Basahin ang pagtanggi sa halip na ulitin ito. Ang pagkabigo sa authentication at pagkabigo sa pagtitiwala ay magkamukha sa window ng status at walang anumang pagkakapareho sa ilalim: ang una ay nangangailangan ng credential, ang pangalawa ay ng chain na tinatanggap ng kliyente.

Ilayo ang mga credential at materyal ng certificate sa mga screenshot. Ang litrato ng page ng settings ay maaaring maglantad ng address ng server at naka-save na username nang sabay, at ang support thread ay pampublikong dokumento nang mas madalas kaysa inaasahan ng mga tao. I-redact bago i-post, hindi pagkatapos na may sumipi na nito.

Sa PowerShell, inililista ng Get-VpnConnection ang itinuturing ng Windows na naka-configure, kasama ang mga entry na itinatago ng settings window sa paningin. Mula sa cmd prompt, kumokonekta ang rasdial ayon sa pangalan ng koneksyon at ipinapakita ng ipconfig /all ang aktwal na natanggap ng adapter. Hindi nagbabahagi ng parser ang dalawang shell, kaya i-paste ang bawat linya sa tama.

Get-VpnConnection
Get-VpnConnection -Name "Office" | Format-List Name,ServerAddress,AuthenticationMethod

rasdial "Office"
ipconfig /all

Ang routing table ang nagpapasya, hindi ang icon ng adapter

Ang corporate tunnel ay maaaring mag-route lamang ng mga destinasyon sa opisina, iniiwan ang ordinaryong pag-browse sa lokal na koneksyon, samantalang ang full-tunnel profile ay kabaligtaran. Buksan ang tunay na resource bago magpasya na mali ang alinman sa dalawang pag-uugali. Iniulat ng icon ang estado ng adapter, at ang sagot ay nasa routing table. Mas madalas na hindi magkasundo ang dalawang iyon kaysa inaamin ng status window.

Ang mas partikular na mga entry ay maaaring magpadala ng subnet sa loob ng tunnel habang nananatili sa labas ang default route, at ganyan talaga dapat ang hitsura ng split tunnel. Ang nawawalang entry ay ang isa pang karaniwang resulta, at mula sa browser ay mukhang katulad ito ng tunnel na bagsak. Ihambing ang prefix na hindi mo naaabot sa table, hindi sa icon. Iyon ang dahilan kung bakit maaaring hindi magkasundo ang icon at ang table habang pareho silang nagsasabi ng totoo tungkol sa magkaibang bagay.

Huwag magbura ng route dahil may mga adapter sa table na hindi mo nakikilala. Ang virtual machine, filter driver o pangalawang kliyente ay maaaring magdagdag ng tig-iisa, at ang pag-alis nito ay sumisira sa dating gumagana.

route print -4
nslookup intranet.corp.internal

Ang mga pribadong pangalan ay nangangailangan ng resolver ng organisasyon

Ang mga pribadong pangalan ay nangangailangan ng resolver ng organisasyon, at ang browser na may sariling secure na DNS ay maaaring lubusang laktawan ang setting ng system. Nagdudulot ito ng nakalilitong kaso kung saan ang query sa command line ay nagbabalik ng address at ang parehong pangalan ay nabibigo pa rin sa browser.

Suriin kung aling adapter ang nagbigay ng kasalukuyang DNS configuration bago baguhin ang anuman. Panatilihin ang resolver ng organisasyon para sa mga pribadong pangalan sa halip na palitan ito ng pampublikong serbisyo. Ang pagpapalit sa pampublikong resolver ay karaniwang nag-aayos ng pampublikong pangalan at sumisira sa lahat ng panloob, na mas masamang pagkabigo kaysa sa sinimulan mo. Kung nag-uulat ng tagumpay ang koneksyon at walang gumagana, dumaan sa forwarding at DNS bago i-reset ang network stack.

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName intranet.corp.internal

Ang dokumentasyon ng Microsoft tungkol sa mga uri ng koneksyon ng VPN sa Windows at mga plug-in ang sanggunian kung aling kliyente ang humahawak sa aling uri, at walang label sa menu ang nagsasabi nito sa iyo. Kumonekta muli pagkatapos ng anumang pagbabago at subukan muli ang tunay na application sa halip na ang icon ng status. I-save ang gumaganang profile kung saan mo ito muling matatagpuan, at itala ang resolver at route na nagpatakbo nito, dahil kakailanganin ng susunod na makina ang dalawa.