A Windows VPN címmezőjében megadott port csak SSTP esetén működik

Egy VPN-kiszolgáló a TCP 10443-on válaszol, a beépített Windows-ügyfél hitelesítő adatai helyesek, a kapcsolat mégis megszakad egy DNS-időtúllépésre hasonlító szünet után. Az ok általában a címmező: ha a Kiszolgálónév vagy cím mezőbe vpn.example.com:10443-at írunk, a Windows az egész karakterláncot gazdagépnévként olvassa, mert az a mező nem általános host:port bemenet. Hogy egyáltalán kifejezhető-e ott port, az a profil által használt alagút típusától függ, és a négy típus közül csak egy kezeli úgy az értéket, hogy képes legyen értelmezni.

Miért nem host:port mező a címmező

A mező mögötti profil tulajdonság a ServerAddress, és minden alagút típus maga dönti el, mit tesz a karakterlánccal. Háromnak nincs kitölthető portparamétere, így a kettőspont és egy szám csupán karakterek egy névben, amely soha nem oldódik fel. A negyedik HTTPS fölött fut, ahol a port az URL része, ezért az értéket olyan formában kell írni, amely URL-ként értelmezhető.

Ezért a hiba névfeloldásnak látszik, nem elutasított kapcsolatnak. Nincs rossz port, amit jelenteni lehetne, csak egy nem létező gazdagépnév, és a hiba azután érkezik, hogy a feloldó feladja. Mielőtt a kiszolgálóhoz nyúl, ellenőrizze, milyen alagút típust állít a profil, hogy használ.

A három fix portos típus

A PPTP a TCP 1723-hoz csatlakozik, majd az alagutat GRE-ben, IP 47-es protokollon szállítja. Az L2TP/IPsec UDP 1701-et használ az alagúthoz, valamint UDP 500-at és 4500-at az IPsec-hez, ahol a 4500 a NAT-átjárási port. Az IKEv2 szintén UDP 500-at és 4500-at használ. Egyik ilyen profil sem tesz közzé portmezőt sehol a felületen, és egyik sem tárgyal ki nem szabványos portot.

Egy egyedi porton figyelő kiszolgáló ezért elérhetetlen ezeknek a profiloknak, akárhogyan is van írva a cím. A gyakorlati válaszok szűkek: tegye közzé a szabványos portot a kiszolgálón, vagy fordítsa le a szabványos portot az egyedire az előtte lévő útválasztón. Mindkettő érintetlenül hagyja az ügyfélprofilt, ami sokat ér, ha a profilt házirenddel telepítik, nem kézzel gépelik.

Az SSTP URL-t igényel, nem nevet

SSTP a kivétel, mert TLS-munkameneten belül fut. A mezőt URL-ként kell értelmezni: először a https:// séma, majd a gazdagép, majd egy kettőspont és a port. Séma nélkül a Windows továbbra is egyszerű névként kezeli az értéket, és a kapcsolat még bármilyen TLS-csere előtt meghiúsul.

Azért lepi meg ez az embereket, mert az alapértelmezett port elfogadja a csupasz gazdagépnevet. Egy profil, amelynek soha nem kellett egyedi port, soha nem tanítja meg a szabályt, és az első ember, aki hozzáad egyet, kudarccal fedezi fel. Mentés után olvassa vissza a tárolt értéket ahelyett, hogy megbízna a párbeszédablakban:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

A ServerAddress pontosan azt mutatja, ami tárolva lett. Ha csupasz gazdagépnévként olvasható kettősponttal, a profil soha nem kapott URL-t, és semmilyen számú újrapróbálkozás nem javítja meg.

Gyártói szintaxis, amelyet ugyanabba a mezőbe illesztenek

Egyes átjárók további konvenciókat dokumentálnak ehhez a mezőhöz, például a port után fűzött realmot vagy a tanúsítványkezelést módosító lekérdezési paramétereket. Ezeket az adott gyártó kiszolgálója és bizonyos buildekben a saját ügyfele is érti. Nem részei a Windows profilformátumának, és beépített profilba illesztve általában ugyanazt a csendes névhibát okozzák.

A tanúsítvány-ellenőrzést letiltó paramétert figyelmeztetésként kezelje, ne javításként. Ha egy profil csak azzal a paraméterrel kapcsolódik, a tanúsítvány nem egyezik a használt névvel, és a helyes javítás az átjárón, nem az ügyfélben van. A port utáni realm ugyanezzel a tulajdonsággal rendelkezik: csak akkor tesz valamit, ha a túloldali kiszolgáló számít rá.

Bizonyítsa a portot, majd olvassa ki a meghiúsuló szakaszt

Erősítse meg, hogy valami elfogad TCP-t ezen a porton az ügyfél hálózatából, mielőtt a profilt hibáztatja:

Test-NetConnection vpn.example.com -Port 10443

A siker egy figyelőt bizonyít, nem az SSTP-t. Egy webszerver, egy fordított proxy vagy egy terheléselosztó befejezheti a TCP-kézfogást, és mégis nem beszél SSTP-t, tehát a zöld teszt piros VPN-nel valós kombináció. Hasonlítsa össze a tanúsítvány tárgyát a profilban szereplő névvel, és nézze meg a RasClient naplót azokban a buildekben, amelyek szállítják, mert az rögzíti a meghiúsult szakaszt általános időtúllépés helyett.

Ezután fontolja meg azt a lehetőséget, amely megszünteti a problémát ahelyett, hogy dokumentálná: továbbítsa a TCP 443-at kívülről a VPN-kiszolgáló 10443-as portjára. Az ügyfél ezután port nélkül használja az alapértelmezett profilt, ami általában a legtisztább elrendezés egy felügyelt flotta számára, és az egyedi port belső részlet marad.