L’errore 789 su una connessione L2TP di Windows significa che il tunnel è morto dentro lo scambio di sicurezza IPsec, cosa che avviene molto prima che Windows invii una password utente da qualche parte. Riprovare la password, o reimpostarla nella directory, non può far avanzare quella fase. Ciò che la fa avanzare è ricostruire la connessione da PowerShell con la proposta che il gateway offre davvero, perché la procedura guidata di Impostazioni sceglie le trasformazioni IPsec in silenzio e non vi mostra mai cosa ha scelto. Questo è il runbook per farlo: create il profilo, fissate la proposta, poi usate una tabella delle fasi così il codice successivo vi dice qualcosa.

Create il profilo senza la procedura guidata

Add-VpnConnection scrive una voce nativa della rubrica telefonica, quindi il risultato è lo stesso oggetto che l’app Impostazioni modificherà più tardi. Eseguitelo da una sessione elevata quando la connessione deve esistere per ogni account della macchina, o dal contesto utente quando deve restare privata:

Add-VpnConnection -Name "Contoso L2TP" `
  -ServerAddress 203.0.113.10 `
  -TunnelType L2tp `
  -EncryptionLevel Required `
  -AuthenticationMethod MSChapv2 `
  -RememberCredential -Force

Fate corrispondere -AuthenticationMethod a ciò che offre il gateway. MSChapv2, EAP e PAP non sono intercambiabili, e un profilo che richiede un metodo che il server non accetterà fallisce prima che venga consultato qualsiasi record utente. Mantenete -EncryptionLevel Required per qualunque cosa reale; Optional lascia che Windows accetti un tunnel non crittografato se la controparte ne offre uno, il che è una scorciatoia da laboratorio e non un’impostazione da distribuire.

Se passate -L2tpPsk, quella chiave precondivisa viene scritta nel profilo sul disco, da dove chiunque possa leggere il profilo su quella macchina può recuperarla. Usate un certificato per l’autenticazione della controparte quando il gateway lo supporta, e quando una PSK è inevitabile tenetela fuori dal repository e fuori dalla cronologia della shell invece di incollarla in ogni esecuzione di provisioning.

Fissate la proposta invece di accettare i valori predefiniti

Windows compila da solo le trasformazioni IPsec, ed è per questo che due macchine con una connessione apparentemente identica possono fallire in modo diverso contro lo stesso gateway. Set-VpnConnectionIPsecConfiguration è il modo supportato per fissarle:

Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso L2TP" `
  -AuthenticationTransformConstants SHA256128 `
  -CipherTransformConstants AES128 `
  -EncryptionMethod AES128 `
  -IntegrityCheckMethod SHA256 `
  -DHGroup Group14 `
  -PfsGroup None `
  -PassThru -Force

Quel set è una disposizione L2TP/IPsec comune, non una risposta universale. Ogni parametro accetta un elenco fisso di valori, e una combinazione che la piattaforma non riesce a mappare torna come errore del cmdlet invece che come profilo silenziosamente indebolito. Trattate un errore simile come un’affermazione sui valori, non sui vostri permessi.

Copiate la proposta dalla documentazione del gateway o dalle sue impostazioni attive di fase 1 e fase 2, e cambiate un campo alla volta solo mentre il gateway registra le trasformazioni che rifiuta. Passare in rassegna cinque campi produce una connessione che funziona per caso e un registro che non spiega nulla alla persona successiva.

Leggete un errore per fase, non per il testo dell’errore

789 appartiene a una famiglia di codici che nella finestra del client sembrano tutti uguali. Collocate il codice davanti alla fase a cui appartiene prima di toccare di nuovo il profilo:

What you seeStage that failedCheck first
Nothing happens, then a timeoutNo IKE response at allServer address, UDP 500 and 4500 reachability, NAT traversal on the gateway
Error 789IKE security exchangeProposal, pre-shared key, certificate trust and client clock
Error 691 or a repeated password promptUser authenticationAccount state, domain, RADIUS or NPS policy
Tunnel up, some hosts unreachableRouting or DNS after PPPSplit-tunnel routes, pushed DNS, remote subnet mask

Le due funzioni delle credenziali contano qui. Una chiave precondivisa o un certificato autentica i peer tra loro, mentre MSChapv2 o EAP autentica voi dentro il tunnel. Reimpostare una password utente non può correggere la prima, un nuovo segreto condiviso non può correggere la seconda, e cambiare entrambe insieme distrugge la prova di quale fosse sbagliata.

Sul percorso del certificato, controllate l’orologio del client, la catena di fiducia e l’identità che il gateway si aspetta prima di considerare di allentare la convalida. Disattivare la convalida trasforma un 789 visibile in un tunnel che si connette fidandosi del peer sbagliato, e nulla nel client vi dirà che è successo. elenco degli errori di accesso remoto di Microsoft è il riferimento per i codici stessi, e separa i guasti del livello di sicurezza dai guasti di accesso.

Verificate da entrambi i lati prima di dichiararlo risolto

Rileggete il profilo, ma non aspettatevi la proposta nell’output. Get-VpnConnection riporta nome, indirizzo del server, tipo di tunnel, livello di crittografia e metodo di autenticazione, e non sa nulla delle trasformazioni, quindi la rilettura conferma che la voce esiste e punta all’host giusto:

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

Componete dalla riga di comando per ottenere un numero invece di una finestra: rasdial "Contoso L2TP" restituisce lo stesso codice di errore che restituirebbe l’interfaccia, e rasdial "Contoso L2TP" /disconnect lo cancella tra i tentativi. Poi leggete il lato gateway per quello stesso tentativo. Un ipsec statusall di strongSwan o un log IKE del router indica quale proposta è arrivata e quale è stata rifiutata, e confrontarlo con i valori del cmdlet è l’unico passo che dimostra davvero che i due estremi si sono accordati.

Una connessione riuscita non è il traguardo. Aprite l’applicazione che conta per l’utente, perché rotte, DNS spinto e impostazioni del tunnel diviso falliscono dopo che il tunnel è attivo e non producono alcuna finestra di errore.

Automatizzatelo e tornate indietro in modo pulito

L’installazione senza sorveglianza è la ragione per scrivere uno script, e il passo di composizione è dove trapelano le credenziali. rasdial le prende sulla sua riga di comando, dove altri utenti locali e la maggior parte dei raccoglitori di log possono leggerle:

subprocess.run(["rasdial", "Contoso L2TP"], check=True)

Preferite una credenziale limitata all’account che esegue il lavoro, o lasciate che il profilo la memorizzi con -RememberCredential, invece di passare una password come argomento in un’attività pianificata. I comandi di provisioning stessi sono sicuri da ripetere con -Force, ma sovrascriveranno volentieri una vecchia proposta, quindi una riesecuzione aiuta solo se lo script porta i valori attuali.

I profili persistono tra i riavvii e sopravvivono alla configurazione del gateway per cui sono stati creati. Quando la proposta del gateway si sposta, rimuovete la voce e ricreatela invece di sovrapporre un secondo set di valori: Remove-VpnConnection -Name "Contoso L2TP" -Force, poi ripetete i due cmdlet con il nuovo set.

Chiudete il ciclo con quattro controlli che vivono accanto allo script: Get-VpnConnection mostra il tipo di tunnel e il livello di crittografia attesi; il gateway registra una fase 1 e una fase 2 completate per l’indirizzo del vostro client; rasdial restituisce successo e l’applicazione si apre; e la proposta registrata nello script corrisponde all’impostazione attuale del gateway. Quando arriva il prossimo 789, quel confronto richiede minuti invece di un pomeriggio.

Articoli correlati