VPN-ul integrat din Windows nu ajunge la o poartă SSL de furnizor: de ce

Windows vine cu patru tipuri de tunel, iar o poartă SSL de furnizor nu este niciunul dintre ele. Îndreptați totuși un profil integrat către una, iar conexiunea eșuează înainte de solicitarea acreditărilor, de obicei cu un mesaj că sistemul local a încheiat conexiunea. Acel text este un semnal de nepotrivire, nu un diagnostic. Tipul profilului și clientul care deține protocolul trebuie să coincidă, iar unul dintre ele lipsește.

Patru tipuri și o casetă de dialog

Fiecare profil salvat poartă un tip de tunel. Clientul integrat acceptă PPTP, L2TP, IKEv2 și SSTP, plus un mod automat care le încearcă în ordine. Nu există nicio intrare generică SSL VPN și nu există nicio cale de a adăuga una prin caseta de dialog. O poartă de furnizor vorbește propriul protocol de aplicație peste TLS, pe care îl implementează doar clientul acelui furnizor.

Lista este la o comandă distanță și merită rulată înaintea oricărei alte depanări, pentru că durează o secundă și elimină o întreagă clasă de presupuneri greșite:

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

Dacă profilul spune SSTP iar poarta nu este un server RRAS, nepotrivirea este deja stabilită. Nicio lucrare la certificate sau firewall nu o schimbă.

SSTP și TLS-ul furnizorului arată la fel pe portul 443

SSTP împachetează o sesiune PPP în TLS și merge pe TCP 443. În stiva Microsoft este încheiată de RRAS, care prezintă un certificat de server pe care clientul îl validează. Un echipament Fortinet, Citrix sau Pulse încheie și el TLS pe 443, iar portalul său se deschide în orice browser fără reclamații.

Acest test în browser dovedește accesibilitatea, nu compatibilitatea. Protocolul de sesiune din spatele portalului aparține furnizorului, iar clientul integrat nu are nicio implementare a lui. Dacă furnizorul livrează un client propriu vă spune cu ce jumătate a nepotrivirii aveți de-a face.

Se întâmplă și confuzia inversă. Un profil configurat ca SSTP față de un server RRAS autentic poate eșua la validarea certificatului în timp ce portalul este în regulă, iar aceasta este o problemă de certificat, nu de protocol.

Erori care apar înainte de a exista un tunel

Codurile din seria 800 sunt raportate înainte de stabilirea oricărui tunel, de aceea regulile de firewall rareori le mișcă. Eroarea 812 este o politică de partea serverului care respinge metoda de autentificare oferită de client. Celelalte din interval vin de la managerul de conexiuni local, nu de la rețea.

Activați urmărirea înainte de a reconstrui ceva. Urmărirea numește etapa care eșuează, iar un nume de etapă valorează mai mult decât textul din caseta de dialog:

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

Urmăririle ajung în directorul de urmărire și rămân acolo până le ștergeți, așa că dezactivați urmărirea după aceea, în loc să o lăsați să ruleze săptămâni întregi.

Un profil conectat poate totuși strica totul

Un profil care se conectează și apoi strică navigarea, o partajare locală sau un motor de containere are o problemă de rutare, nu de tunel. Gatewayul implicit s-a mutat în tunel, așa că fiecare destinație trece acum printr-un partener care poate nu o rutează.

Două setări decid acest lucru. Una este proprietatea de split tunneling din profil. Cealaltă este opțiunea per adaptor de a folosi gatewayul implicit în rețeaua îndepărtată, care se află în setările avansate IPv4.

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

Activarea split tunneling fără adăugarea de rute produce un tunel care se conectează și nu ajunge nicăieri. Dezactivarea lui fără verificarea DNS produce nume interne care se rezolvă în răspunsuri publice, pentru că sufixul și serverele adaptorului nu sunt folosite.

Verificați instalația, apoi tipul

Lucrați în această ordine și opriți-vă când un pas eșuează, în loc să ajustați totul deodată:

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

Prima comandă separă accesibilitatea de protocol. A doua confirmă ce pretinde a fi profilul. Tabela de rutare arată dacă tunelul a capturat ruta implicită. Comanda de apelare raportează eroarea proprie a managerului de conexiuni, care este adesea mai clară decât caseta de dialog.

Notați în tichet tipul tunelului, produsul gatewayului și eroarea exactă. Următoarea persoană știe atunci într-un minut dacă este o nepotrivire de protocol, o defecțiune de certificat sau o decizie de rutare, în loc să înceapă cu „VPN-ul nu funcționează”.