Un port în câmpul de adresă al VPN-ului Windows funcționează doar cu SSTP

Un server VPN răspunde pe TCP 10443, clientul integrat din Windows are acreditările corecte, iar conexiunea tot cade după o pauză care arată ca un timeout DNS. Cauza este de obicei câmpul de adresă: tastarea vpn.example.com:10443 în Nume server sau adresă face Windows să citească întregul șir ca nume de gazdă, pentru că acea casetă nu este o intrare host:port generală. Dacă un port poate fi exprimat acolo depinde de tipul de tunel folosit de profil, iar doar unul din cele patru tipuri tratează valoarea ca pe ceva ce poate analiza.

De ce câmpul de adresă nu este o casetă host:port

Proprietatea profilului din spatele acelui câmp este ServerAddress, iar fiecare tip de tunel decide ce face cu șirul. Trei dintre ele nu au niciun parametru de port de completat, așa că două puncte și un număr sunt doar caractere într-un nume care nu va fi rezolvat niciodată. Al patrulea rulează peste HTTPS, unde un port face parte din URL, deci valoarea trebuie scrisă într-o formă care se analizează ca URL.

De aceea eșecul arată ca o rezolvare de nume și nu ca o conexiune refuzată. Nu există niciun port greșit de raportat, doar un nume de gazdă care nu există, iar eroarea apare după ce resolverul renunță. Înainte de a atinge serverul, verificați ce tip de tunel declară profilul că folosește.

Cele trei tipuri cu port fix

PPTP se conectează la TCP 1723 și apoi transportă tunelul în GRE, protocolul IP 47. L2TP/IPsec folosește UDP 1701 pentru tunel și UDP 500 plus 4500 pentru IPsec, iar 4500 este portul de traversare NAT. IKEv2 folosește și el UDP 500 și 4500. Niciunul dintre aceste profiluri nu expune un câmp de port nicăieri în interfață și niciunul nu va negocia un port nestandard.

Un server care ascultă pe un port personalizat este, prin urmare, inaccesibil acelor profiluri, indiferent cum este scrisă adresa. Răspunsurile practice sunt înguste: publicați portul standard pe server sau traduceți portul standard în cel personalizat pe routerul din fața lui. Ambele lasă profilul clientului neatins, ceea ce valorează mult atunci când profilul este implementat prin politică și nu tastat manual.

SSTP are nevoie de un URL, nu de un nume

SSTP este excepția pentru că rulează într-o sesiune TLS. Câmpul trebuie analizat ca URL: mai întâi schema https://, apoi gazda, apoi două puncte și portul. Fără schemă, Windows continuă să trateze valoarea ca un nume simplu și conexiunea eșuează înainte de orice schimb TLS.

Motivul pentru care acest lucru surprinde este că portul implicit acceptă numele de gazdă gol. Un profil care nu a avut niciodată nevoie de un port personalizat nu învață niciodată regula, iar prima persoană care adaugă unul o descoperă eșuând. După salvare, citiți valoarea stocată în loc să aveți încredere în dialog:

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

ServerAddress arată exact ce a fost stocat. Dacă este citit ca un nume de gazdă gol cu două puncte în el, profilul nu a primit niciodată un URL și nicio cantitate de reîncercări nu va repara asta.

Sintaxa producătorului care se lipește în aceeași casetă

Unele gateway-uri documentează convenții suplimentare pentru acel câmp, cum ar fi un realm adăugat după port sau parametri de interogare care schimbă tratarea certificatelor. Sunt înțelese de serverul acelui producător și, în unele build-uri, de propriul său client. Nu fac parte din formatul de profil Windows, iar lipirea lor într-un profil integrat produce de obicei același eșec silențios de nume.

Tratați un parametru care dezactivează validarea certificatului ca un avertisment și nu ca o soluție. Dacă un profil se conectează doar cu acel parametru, certificatul nu corespunde numelui folosit, iar reparația corectă este pe gateway, nu în client. Un realm după port are aceeași proprietate: face ceva doar dacă serverul de cealaltă parte îl așteaptă.

Demonstrați portul, apoi citiți etapa care eșuează

Confirmați că ceva acceptă TCP pe acel port din rețeaua clientului înainte de a da vina pe profil:

Test-NetConnection vpn.example.com -Port 10443

Succesul dovedește un ascultător, nu SSTP. Un server web, un proxy invers sau un balancer de încărcare pot finaliza strângerea de mână TCP și totuși să nu vorbească SSTP, așa că un test verde cu un VPN roșu este o combinație reală. Comparați subiectul certificatului cu numele din profil și verificați jurnalul RasClient în build-urile care îl livrează, pentru că înregistrează etapa care a eșuat în loc de un timeout generic.

Apoi luați în considerare opțiunea care elimină problema în loc să o documenteze: redirecționați TCP 443 din exterior către 10443 pe serverul VPN. Clientul folosește atunci profilul implicit fără niciun port, ceea ce este de obicei cea mai curată aranjare pentru o flotă gestionată și lasă portul personalizat ca detaliu intern.