Port Windowsi VPN-i aadressiväljal töötab ainult SSTP puhul
Väli Serveri nimi ei ole host:port. PPTP-l, L2TP-l ja IKEv2-l on fikseeritud pordid; SSTP võtab porti vastu ainult täieliku https:// URL-ina ja 443 edasisuunamine on puhtam.
VPN-server vastab TCP 10443 pordil, Windowsi sisseehitatud kliendil on õiged mandaadid ja ühendus sureb ikkagi pärast pausi, mis näeb välja nagu DNS-i ajapiiang. Põhjus on tavaliselt aadressiväli: kui sisestada Serveri nimi või aadress väljale vpn.example.com:10443, loeb Windows kogu stringi hostinimena, sest see kast ei ole üldine host:port-sisend. Kas porti saab seal üldse väljendada, sõltub profiili kasutatavast tunnelitüübist ja ainult üks neljast tüübist käsitleb väärtust millegi sellisena, mida ta suudab parsida.
Miks aadressiväli ei ole host:port-kast
Selle välja taga olev profiiliomadus on ServerAddress ja iga tunnelitüüp otsustab, mida ta stringiga teeb. Kolmel neist ei ole täitmiseks pordiparameetrit, seega on koolon ja number lihtsalt tähemärgid nimes, mida ei lahendata kunagi. Neljas töötab HTTPS-i kaudu, kus port on URL-i osa, seega tuleb väärtus kirjutada kujul, mis parsitakse URL-ina.
Seetõttu näeb tõrge välja nagu nimelahendus, mitte nagu tagasi lükatud ühendus. Pole ühtegi halba porti, millest teatada, on ainult hostinimi, mida ei ole olemas, ja viga saabub pärast seda, kui resolver alla annab. Enne kui serverit puutute, kontrollige, millist tunnelitüüpi profiil väidab end kasutavat.
Kolm fikseeritud pordiga tüüpi
PPTP ühendub TCP 1723-ga ja kannab seejärel tunnelit GRE-s, IP-protokollis 47. L2TP/IPsec kasutab tunneli jaoks UDP 1701 ja IPsec-i jaoks UDP 500 pluss 4500, kusjuures 4500 on NAT-i läbimise port. IKEv2 kasutab samuti UDP 500 ja 4500. Ükski neist profiilidest ei paljasta liideses kuskil pordivälja ja ükski ei kaubelda välja mittestandardset porti.
Kohandatud pordil kuulav server on seega nende profiilide jaoks kättesaamatu, ükskõik kuidas aadress on kirjutatud. Praktilised vastused on kitsad: avaldage serveris standardport või tõlkige standardport kohandatud pordiks selle ees olevas ruuteris. Mõlemad jätavad kliendiprofiili puutumata, mis on palju väärt, kui profiil juurutatakse poliitikaga, mitte käsitsi trükkides.
SSTP vajab URL-i, mitte nime
SSTP on erand, sest see töötab TLS-i sessiooni sees. Väli tuleb parsida URL-ina: kõigepealt https:// skeem, seejärel host, seejärel koolon ja port. Ilma skeemita jätkab Windows väärtuse käsitlemist lihtsa nimena ja ühendus ebaõnnestub enne, kui toimub mis tahes TLS-i vahetus.
Põhjus, miks see inimesi üllatab, on see, et standardport võtab vastu palja hostinime. Profiil, mis ei ole kunagi kohandatud porti vajanud, ei õpeta seda reeglit kunagi, ja esimene inimene, kes selle lisab, avastab selle ebaõnnestudes. Pärast salvestamist lugege salvestatud väärtus uuesti tagasi, selle asemel et dialoogi usaldada:
Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType
ServerAddress näitab täpselt seda, mis salvestati. Kui see loetakse palja hostinimena, milles on koolon, ei saanud profiil kunagi URL-i ja ükski korduskatsete arv ei paranda seda.
Tarnija süntaks, mis kleebitakse samasse kasti
Mõned lüüsid dokumenteerivad selle välja jaoks lisakonventsioone, näiteks pärast porti lisatud realm või päringuparameetrid, mis muudavad sertifikaadi käsitlemist. Neist saab aru selle tarnija server ja mõnes buildis ka tema enda klient. Need ei ole Windowsi profiilivormingu osa ja sisseehitatud profiili kleebituna tekitavad need tavaliselt sama vaikse nimevea.
Käsitlege parameetrit, mis keelab sertifikaadi valideerimise, hoiatuse, mitte parandusena. Kui profiil ühendub ainult selle parameetriga, ei vasta sertifikaat kasutatavale nimele ja õige parandus on lüüsil, mitte kliendis. Realm pärast porti on sama omadusega: see teeb midagi ainult siis, kui teisel pool olev server seda ootab.
Tõestage port ja lugege siis ebaõnnestuvat etappi
Enne kui profiili süüdistate, kinnitage, et miski võtab kliendi võrgust sellel pordil TCP vastu:
Test-NetConnection vpn.example.com -Port 10443
Edu tõestab kuulajat, mitte SSTP-d. Veebiserver, pöördproxy või koormusjaotur võivad TCP käepigistuse lõpule viia ja ikkagi mitte SSTP-d rääkida, seega roheline test punase VPN-iga on tõeline kombinatsioon. Võrrelge sertifikaadi subjekti profiili nimega ja kontrollige RasClienti logi buildides, mis sellega kaasas on, sest see salvestab ebaõnnestunud etapi üldise ajapiiangu asemel.
Seejärel kaaluge valikut, mis kõrvaldab probleemi, selle dokumenteerimise asemel: suunake väljastpoolt TCP 443 VPN-serveri pordile 10443. Klient kasutab siis standardprofiili ilma ühegi pordita, mis on hallatava laevastiku jaoks tavaliselt puhtaim lahendus ja jätab kohandatud pordi sisemiseks detailiks.