Windows VPN adreso lauke nurodytas prievadas veikia tik su SSTP

VPN serveris atsako TCP 10443 prievadu, integruotas Windows klientas turi teisingus prisijungimo duomenis, o ryšys vis tiek nutrūksta po pauzės, kuri atrodo kaip DNS skirtojo laiko pabaiga. Priežastis paprastai yra adreso laukas: įrašius vpn.example.com:10443 į Serverio pavadinimas arba adresas, Windows visą eilutę nuskaito kaip pagrindinio kompiuterio vardą, nes tas laukas nėra bendra host:port įvestis. Ar prievadą ten apskritai galima išreikšti, priklauso nuo tunelio tipo, kurį naudoja profilis, ir tik vienas iš keturių tipų traktuoja reikšmę kaip kažką, ką gali išanalizuoti.

Kodėl adreso laukas nėra host:port laukas

Profilio savybė už šio lauko yra ServerAddress, ir kiekvienas tunelio tipas sprendžia, ką daro su eilute. Trys iš jų neturi prievado parametro, kurį būtų galima užpildyti, todėl dvitaškis ir skaičius yra tiesiog ženklai varde, kuris niekada nebus išspręstas. Ketvirtasis veikia per HTTPS, kur prievadas yra URL dalis, todėl reikšmė turi būti parašyta tokia forma, kuri analizuojama kaip URL.

Štai kodėl gedimas atrodo kaip vardų sprendimas, o ne kaip atmestas ryšys. Nėra blogo prievado, apie kurį pranešti, tik neegzistuojantis pagrindinio kompiuterio vardas, o klaida ateina po to, kai sprendėjas pasiduoda. Prieš liesdami serverį, patikrinkite, kokį tunelio tipą profilis teigia naudojantis.

Trys tipai su fiksuotu prievadu

PPTP jungiasi prie TCP 1723 ir tada perneša tunelį GRE, IP protokolu 47. L2TP/IPsec naudoja UDP 1701 tuneliui ir UDP 500 bei 4500 IPsec, o 4500 yra NAT perėjimo prievadas. IKEv2 taip pat naudoja UDP 500 ir 4500. Nė vienas iš šių profilių niekur sąsajoje nerodo prievado lauko, ir nė vienas nesiderės dėl nestandartinio prievado.

Serveris, klausantis pasirinktiniame prievade, todėl yra nepasiekiamas tiems profiliams, nesvarbu, kaip parašytas adresas. Praktiniai atsakymai siauri: paskelbkite standartinį prievadą serveryje arba išverskite standartinį prievadą į pasirinktinį maršrutizatoriuje priešais jį. Abiem atvejais kliento profilis lieka nepaliestas, o tai daug verta, kai profilis diegiamas politika, o ne rašomas ranka.

SSTP reikia URL, o ne vardo

SSTP yra išimtis, nes veikia TLS sesijos viduje. Laukas turi būti analizuojamas kaip URL: pirmiausia https:// schema, tada pagrindinis kompiuteris, tada dvitaškis ir prievadas. Be schemos Windows toliau traktuoja reikšmę kaip paprastą vardą, ir ryšys nutrūksta prieš bet kokį TLS pasikeitimą.

Priežastis, kodėl tai stebina, yra ta, kad numatytasis prievadas priima nuogą pagrindinio kompiuterio vardą. Profilis, kuriam niekada nereikėjo pasirinktinio prievado, niekada neišmoksta taisyklės, o pirmasis žmogus, kuris jį pridėjo, atranda tai nepavykus. Išsaugoję perskaitykite išsaugotą reikšmę, o ne pasitikėkite dialogu:

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

ServerAddress rodo tiksliai tai, kas buvo išsaugota. Jei jis skaitomas kaip nuogas pagrindinio kompiuterio vardas su dvitaškiu, profilis niekada negavo URL ir joks kartojimų skaičius to nepataisys.

Gamintojo sintaksė, kuri įklijuojama į tą patį lauką

Kai kurie tinklų sietuvai dokumentuoja papildomas konvencijas šiam laukui, pavyzdžiui, po prievado pridėtą sritį arba užklausos parametrus, keičiančius sertifikatų tvarkymą. Juos supranta to gamintojo serveris ir kai kuriuose builduose jo paties klientas. Jie nėra Windows profilio formato dalis, o įklijavus juos į integruotą profilį paprastai gaunama ta pati tyli vardo klaida.

Parametrą, kuris išjungia sertifikato tikrinimą, traktuokite kaip įspėjimą, o ne kaip pataisą. Jei profilis jungiasi tik su tuo parametru, sertifikatas neatitinka naudojamo vardo, o teisinga pataisa atliekama sietuvo, o ne kliento pusėje. Sritis po prievado turi tą pačią savybę: ji ką nors daro tik jei serveris kitoje pusėje jos tikisi.

Įrodykite prievadą, tada perskaitykite nepavykusį etapą

Prieš kaltindami profilį patvirtinkite, kad kažkas priima TCP tame prievade iš kliento tinklo:

Test-NetConnection vpn.example.com -Port 10443

Sėkmė įrodo klausytoją, o ne SSTP. Žiniatinklio serveris, atvirkštinis tarpininkas arba apkrovos balansuotojas gali užbaigti TCP rankos paspaudimą ir vis tiek nekalbėti SSTP, todėl žalias testas su raudonu VPN yra realus derinys. Palyginkite sertifikato subjektą su vardu profilyje ir patikrinkite RasClient žurnalą builduose, kuriuose jis pateikiamas, nes jis fiksuoja nepavykusį etapą, o ne bendrą skirtąjį laiką.

Tada apsvarstykite variantą, kuris pašalina problemą, o ne ją dokumentuoja: peradresuokite TCP 443 iš išorės į 10443 VPN serveryje. Tada klientas naudoja numatytąjį profilį visai be prievado, o tai paprastai yra švariausias sprendimas valdomam parkui ir palieka pasirinktinį prievadą kaip vidinę detalę.