Add-VpnConnection: kial la PSK rompiĝas kaj la adreso restas

Windows VPN-profilo estas enskribo en telefona libro, kaj PowerShell estas unu maniero redakti tiun enskribon. Du fiaskoj devenas de tiu distingo: antaŭe kunhavata ŝlosilo, kiu alvenas al la servilo jam difektita, kaj servila adreso, kiu aspektas ĝisdatigita sed ne estas la adreso, kiun la sekva tunelo vokos. Ambaŭ pli facile videblas, se vi traktas la profilon kiel konservitan staton, ne kiel komandon, kiun vi ruligis. La trairo sekvas la ordon de la redaktoj: krei, ŝanĝi, amplekso, relegi.

Konstruu la profilon per laŭvorta ŝlosilo

Add-VpnConnection akceptas la antaŭe kunhavatan L2TP-ŝlosilon per -L2tpPsk. PowerShell prilaboras la ĉenon antaŭ ol la cmdlet ricevas ĝin, kaj ene de duoblaj citiloj dolarsigno komencas variablreferencon dum backtick komencas eskapon. Ŝlosilo enhavanta iun el ili alvenas pli mallonga aŭ kun alia signo, kaj la profilo sukcese kreiĝas kun la malĝusta sekreto.

Poste la fiasko aperas ĉe IPsec-aŭtentigo, kie la tunelo rifuzas leviĝi. Tial citila eraro tiel ofte raportiĝas kiel problemo ĉe la servila flanko: la profilo ekzistas, la nomo ĝustas, kaj la sekreto estas silente malĝusta.

Unuopaj citiloj estas la solvo, kaj ili devas ĉirkaŭi la tutan valoron. Se la enskribo jam ekzistas kun malbona ŝlosilo, -Force anstataŭigas ĝin, aŭ forigu kaj rekreu la profilon kaj poste testu per nova konekto:

Add-VpnConnection -Name "Contoso-L2TP" -ServerAddress vpn.contoso.example -TunnelType L2tp -L2tpPsk 'n3w$ecret!2026' -AuthenticationMethod Pap -RememberCredential -Force

Tenu la veran sekreton ekster la ŝela historio kaj kunhavataj skriptoj. Legu ĝin dum rultempo el la aprobita konservejo kaj transdonu la variablon anstataŭ la laŭvortan valoron, kio tute evitas la citilan problemon.

Ŝanĝu la adreson, poste rekonektiĝu

Set-VpnConnection prenas parametrojn apartigitajn per spacoj, ne asignan sintakson. Verki -ServerAddress = "203.0.113.10" transdonas plian ĵetonon, kaj la cmdlet aŭ eraras aŭ konservas ion, kion vi ne intencis. La ĝusta formo estas -Name "Office L2TP" -ServerAddress 203.0.113.10.

Eĉ kun la ĝusta sintakso, la ŝanĝo ne atingas tunelon jam levitan. Starigita konekto tenas la adreson, kiun ĝi vokis, ĝis ĝi malkonektiĝas, do testi la saman sesion pruvas nenion pri la nova valoro. Malkonektiĝu, redaktu, rekonektiĝu, kaj konfirmu la adreson de la partnero en la konektaj detaloj.

Iuj ecoj ne ŝanĝeblas surloke. Kiam la cmdlet rifuzas, notu la ekzistantajn parametrojn, forigu la profilon kaj rekreu ĝin kun la korektitaj valoroj, kaj konservu la originajn agordojn de tunelo kaj aŭtentigo. Skripto, kiu devas ŝanĝi nur la telefonnumeron, povas redakti la enskribon de la telefona libro per la RAS API anstataŭ rekrei ĉion. Kiun ajn vojon vi elektos, konfirmu la konservitajn valorojn poste anstataŭ fidi la silenton de la komando.

Sciu, kiun telefonan libron vi redaktis

Profilo por unu uzanto loĝas en la retkonekta dosierujo de tiu uzanto, kaj profilo por ĉiuj uzantoj loĝas en la tutmaŝina dosierujo sub la programdatenarbo. Ili estas malsamaj enskriboj kun malsamaj ampleksoj, kaj redakti unu lasas la alian netuŝita.

Tial ŝanĝo povas ŝajni malaperi: la skripto rulis sub unu konto, kaj la testo sub alia. Uzu -AllUserConnection kiam la profilo apartenas al la maŝino, kaj kontrolu la saman amplekson kiam vi relegas ĝin.

Relegu la profilon antaŭ ol testi

Demandu Windows, kion ĝi konservis, ne kion vi transdonis:

Get-VpnConnection -Name "Office L2TP" | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod

Komparu tiun eligon kun la intenco, poste komencu novan konekton. Se la vokado malsukcesas, kontrolu la protokolon de la RAS-kliento en Event Viewer antaŭ ol denove ŝanĝi la profilon, ĉar la protokolo nomas la etapon, kiu malsukcesis.

Tenu la aŭtentigan dezajnon sendifekta dum redaktado. Komando, kiu ŝanĝas la adreson sed forlasas la atestilon aŭ la EAP-agordon, produktas fiaskon, kiu aspektas ne ligita al la redakto, kaj eksporti la funkciantan profilon antaŭe donas al vi ion por restarigi anstataŭ konjekton.