Bakit hindi naaabot ng built-in na VPN ng Windows ang SSL gateway ng isang vendor

May apat na uri ng tunnel ang Windows, at ang SSL gateway ng vendor ay wala sa mga ito. Ituro mo man ang built-in na profile sa isa, nabibigo ang koneksyon bago pa hilingin ang kredensyal, kadalasan may mensaheng tinapos ng lokal na sistema ang koneksyon. Ang tekstong iyon ay senyales ng hindi pagtutugma, hindi diagnosis. Dapat magtugma ang uri ng profile at ang kliyenteng nagmamay-ari ng protocol, at kulang ang isa sa kanila.

Apat na uri at isang dialog

Bawat naka-save na profile ay may uri ng tunnel. Tinatanggap ng built-in na kliyente ang PPTP, L2TP, IKEv2 at SSTP, kasama ang awtomatikong mode na sinusubukan sila nang sunod-sunod. Walang pangkalahatang entry para sa SSL VPN, at walang paraan para magdagdag nito sa pamamagitan ng dialog. Nagsasalita ang gateway ng vendor ng sarili nitong protocol ng aplikasyon sa ibabaw ng TLS, na ang kliyente lamang ng vendor na iyon ang nagpapatupad.

Isang utos lang ang layo ng listahan, at sulit itong patakbuhin bago ang anumang iba pang pag-aayos ng problema dahil tumatagal ito ng isang segundo at inaalis ang isang buong klase ng maling palagay:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Kung sinasabi ng profile na SSTP at ang gateway ay hindi RRAS server, naitatag na ang hindi pagtutugma. Walang gawaing certificate o firewall ang makakabago nito.

Magkamukha ang SSTP at ang TLS ng vendor sa port 443

Binabalot ng SSTP ang isang PPP session sa loob ng TLS at dumadaan sa TCP 443. Sa stack ng Microsoft, tinatapos ito ng RRAS, na nagpapakita ng certificate ng server na binibigyang-bisa ng kliyente. Tinatapos din ng aparatong Fortinet, Citrix o Pulse ang TLS sa 443, at bumubukas ang portal nito sa anumang browser nang walang reklamo.

Pinatutunayan ng pagsubok sa browser na iyon ang maabot, hindi ang pagiging tugma. Pag-aari ng vendor ang protocol ng session sa likod ng portal, at walang anumang pagpapatupad nito ang built-in na kliyente. Kung may sariling kliyente ang vendor, sinasabi nito kung aling kalahati ng hindi pagtutugma ang hinaharap mo.

Nangyayari rin ang kabaligtarang pagkalito. Ang profile na naka-configure bilang SSTP laban sa tunay na RRAS server ay maaaring mabigo sa pagpapatunay ng certificate habang maayos ang portal, at iyon ay problema sa certificate, hindi problema sa protocol.

Mga error na lumilitaw bago magkaroon ng tunnel

Ang mga code ng seryeng 800 ay iniuulat bago pa maitatag ang anumang tunnel, kaya bihirang mapagalaw sila ng mga patakaran ng firewall. Ang error 812 ay patakaran sa panig ng server na tumatanggi sa paraan ng pagpapatotoo na inalok ng kliyente. Ang iba pa sa saklaw ay nagmumula sa lokal na tagapamahala ng koneksyon at hindi sa network.

I-on ang pagsubaybay bago muling buuin ang anuman. Pinapangalanan ng pagsubaybay ang yugtong nabibigo, at mas mahalaga ang pangalan ng yugto kaysa teksto ng dialog:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Napupunta ang mga trace sa ilalim ng direktoryo ng pagsubaybay at nananatili roon hanggang linisin mo ang mga ito, kaya patayin ito pagkatapos sa halip na hayaang tumakbo nang ilang linggo.

Ang konektadong profile ay maaari pa ring sirain ang lahat

Ang profile na kumokonekta at pagkatapos ay sumisira sa pag-browse, lokal na sharing o container engine ay may problema sa routing, hindi problema sa tunnel. Lumipat ang default gateway sa tunnel, kaya dumadaan na ngayon ang bawat destinasyon sa isang kapares na maaaring hindi ito i-route.

Dalawang kontrol ang nagpapasya nito. Isa ang property ng split tunneling sa profile. Ang isa pa ay ang opsyon sa bawat adapter na gamitin ang default gateway sa malayong network, na nasa advanced na setting ng IPv4.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Ang pag-on ng split tunneling nang walang idinagdag na ruta ay gumagawa ng tunnel na kumokonekta at walang naaabot. Ang pag-off nito nang hindi tinitingnan ang DNS ay gumagawa ng mga panloob na pangalan na nagiging pampublikong sagot, dahil hindi ginagamit ang sariling suffix at mga server ng adapter.

Tiyakin ang pagkaplumbing, pagkatapos ang uri

Magtrabaho sa ayos na ito, at huminto kapag may yugtong nabigo sa halip na isaayos ang lahat nang sabay:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

Hinihiwalay ng unang utos ang maabot mula sa protocol. Kinukumpirma ng pangalawa kung ano ang sinasabi ng profile na siya. Ipinapakita ng talahanayan ng ruta kung nakuha ng tunnel ang default na ruta. Iniulat ng utos ng dial ang sariling error ng tagapamahala ng koneksyon, na kadalasang mas malinaw kaysa dialog.

Itala sa ticket ang uri ng tunnel, produkto ng gateway at eksaktong error. Malalaman ng susunod na tao sa loob ng isang minuto kung hindi pagtutugma ng protocol, pagkabigo ng certificate o desisyon sa routing ito, sa halip na magsimula sa “hindi gumagana ang VPN”.