La enkonstruita VPN de Windows ne atingas SSL-pordegon de vendisto: kial
Windows venas kun kvar tunelaj tipoj, kaj pordego de vendisto estas neniu el ili. Kontrolu la profilan tipon antaŭ ol tuŝi atestilojn, vojojn aŭ akreditaĵojn.
Windows venas kun kvar tunelaj tipoj, kaj pordego de vendisto estas neniu el ili. Direktu enkonstruitan profilon al unu tamen, kaj la konekto malsukcesas antaŭ la akreditaĵa prompto, kutime kun mesaĝo ke la konekton finis la loka sistemo. Tiu teksto estas signalo de miskongruo, ne diagnozo. La profila tipo kaj la kliento, kiu posedas la protokolon, devas kongrui, kaj unu el ili mankas.
Kvar tipoj kaj unu dialogo
Ĉiu konservita profilo portas tunelan tipon. La enkonstruita kliento akceptas PPTP, L2TP, IKEv2 kaj SSTP, plus aŭtomata reĝimo, kiu provas ilin laŭvice. Mankas ĝenerala SSL VPN-ero, kaj mankas maniero aldoni unu per la dialogo. Pordego de vendisto parolas sian propran aplikaĵan protokolon super TLS, kiun nur la kliento de tiu vendisto realigas.
La listo estas unu komando for, kaj indas ruli ĝin antaŭ ajna alia problemtaksado, ĉar ĝi daŭras sekundon kaj forigas tutan klason de malĝustaj supozoj:
Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling Get-VpnConnection -Name "Office" | Format-List
Se la profilo diras SSTP kaj la pordego ne estas RRAS-servilo, la miskongruo jam konstatatas. Neniu atestila aŭ fajroŝirma laboro ŝanĝas tion.
SSTP kaj vendista TLS aspektas same sur pordo 443
SSTP volvas PPP-sesion en TLS kaj veturas sur TCP 443. En la Microsoft-stako ĝin finas RRAS, kiu prezentas servilan atestilon, kiun la kliento validigas. Aparato Fortinet, Citrix aŭ Pulse ankaŭ finas TLS sur 443, kaj ĝia portalo malfermiĝas en ajna retumilo sen plendo.
Tiu retumila testo pruvas atingeblon, ne kongruecon. La sesia protokolo malantaŭ la portalo apartenas al la vendisto, kaj la enkonstruita kliento havas neniun realigon de ĝi. Ĉu la vendisto liveras propran klienton, diras al vi, pri kiu duono de la miskongruo vi okupiĝas.
La inversa konfuzo ankaŭ okazas. Profilo agordita kiel SSTP kontraŭ vera RRAS-servilo povas malsukcesi ĉe atestila validigo dum la portalo estas en ordo, kaj tio estas atestila problemo kaj ne protokola problemo.
Eraroj, kiuj aperas antaŭ ol tunelo ekzistas
La kodoj de la 800-serio raportatas antaŭ ol iu tunelo establiĝas, tial fajroŝirmaj reguloj malofte movas ilin. Eraro 812 estas servila politiko, kiu rifuzas la aŭtentigan metodon, kiun la kliento proponis. La aliaj en la gamo venas de la loka konekta administranto kaj ne de la reto.
Ŝaltu spuradon antaŭ ol rekonstrui ion ajn. La spurado nomas la malsukcesan etapon, kaj etapa nomo valoras pli ol la dialoga teksto:
netsh ras set tracing * enable Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5
Spuroj finiĝas sub la spura dosierujo kaj restas tie ĝis vi forviŝos ilin, do malŝaltu la spuradon poste anstataŭ lasi ĝin funkcii semajnojn.
Konektita profilo ankoraŭ povas rompi ĉion
Profilo, kiu konektiĝas kaj poste rompas retumadon, lokan kunhavaĵon aŭ ujujan motoron, havas vojigan problemon, ne tunelan problemon. La implicita pordego translokiĝis al la tunelo, do ĉiu celo nun iras tra samtavolano, kiu eble ne vojigas ĝin.
Du regiloj decidas tion. Unu estas la eco de dividita tunelado en la profilo. La alia estas la opcio por adaptilo uzi la implicitan pordegon en la fora reto, kiu troviĝas sub la altnivelaj agordoj de IPv4.
Set-VpnConnection -Name "Office" -SplitTunneling $true Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16
Ŝalti dividitan tuneladon sen aldoni vojojn produktas tunelon, kiu konektiĝas kaj atingas nenion. Malŝalti ĝin sen kontroli DNS produktas internajn nomojn, kiuj solviĝas al publikaj respondoj, ĉar la propra sufikso kaj serviloj de la adaptilo ne estas uzataj.
Kontrolu la tubaron, poste la tipon
Laboru laŭ ĉi tiu ordo, kaj haltu kiam paŝo malsukcesas anstataŭ ĝustigi ĉion samtempe:
Test-NetConnection vpn.example.net -Port 443 Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix netsh interface ipv4 show route rasdial Office
La unua komando apartigas atingeblon de protokolo. La dua konfirmas, kion la profilo asertas esti. La voja tabelo montras, ĉu la tunelo kaptis la implicitan vojon. La voka komando raportas la propran eraron de la konekta administranto, kiu ofte estas pli klara ol la dialogo.
Notu la tunelan tipon, la pordegan produkton kaj la precizan eraron en la bileto. La sekva persono tiam scias ene de minuto, ĉu temas pri protokola miskongruo, atestila fiasko aŭ vojiga decido, anstataŭ komenci de “la VPN ne funkcias”.