Una connessione VPN di Windows fallisce, una ricerca restituisce un valore di registro e il valore viene inserito insieme a un riavvio. Quella sequenza a volte funziona e non spiega mai nulla. L’impostazione in questione risponde a una domanda su dove si trovi il server rispetto a un dispositivo NAT, ed è priva di senso finché non sai quale protocollo è fallito e in quale fase.

Che cosa seleziona davvero il valore

AssumeUDPEncapsulationContextOnSendRule stabilisce se un’implementazione IPsec di Windows tenterà associazioni con un peer dietro un dispositivo NAT. Il valore predefinito documentato 0 non consente quel caso, 1 lo consente quando il server è il lato dietro il NAT e 2 copre la traduzione di entrambe le estremità. Sono affermazioni di topologia su chi sta dove.

Letti come una sequenza, i numeri descrivono sempre più traduzione, non sempre più affidabilità. Impostare 2 su una rete in cui nulla viene tradotto non rende la connessione più veloce o stabile e non ripara un fallimento di autenticazione. La guida NAT di Microsoft per L2TP/IPsec documenta la politica e il suo contesto storico di piattaforma. Confronta quel contesto con la versione e il ruolo di Windows che esegui davvero, perché un documento sopravvissuto a diverse versioni non è un’affermazione su ogni build attuale.

Allinea la topologia prima del numero

Disegna il percorso e segna i punti di traduzione: il client è dietro un router domestico, il server è dietro un bilanciatore di carico o un firewall che riscrive gli indirizzi, e una delle estremità è dietro una traduzione dell’operatore che non controlli. Solo dopo quel disegno puoi decidere se il valore si applica e a quale estremità.

L’affermazione secondo cui le versioni attuali di Windows Server arrivino semplicemente con il NAT traversal disattivato è troppo ampia per agirvi. Conta la politica sul tuo sistema, la topologia davanti a esso e lo scambio che è fallito, in quest’ordine. Se entrambe le estremità hanno indirizzi pubblici, l’impostazione non è il tuo problema. Guarda invece la proposta, il certificato o l’account, e lascia stare il registro.

Controlla prima la fase del fallimento

L2TP/IPsec produce almeno tre fallimenti distinti: il peer non è raggiungibile, la protezione IPsec non può essere stabilita e l’autenticazione utente PPP viene rifiutata dopo che il tunnel esiste. Un account rifiutato non si ripara cambiando la politica NAT, e una discordanza di proposte non si ripara con un riavvio.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Un timeout senza risponditore suggerisce raggiungibilità o filtraggio più che politica. Un rifiuto rapido con un messaggio di proposta indica gli algoritmi. Un fallimento dopo che il tunnel è attivo appartiene alla fase di autenticazione, che è un altro proprietario e un’altra correzione.

SSTP su HTTPS e IKEv2 nativo hanno i propri log e i propri controlli. Nulla di ciò diventa un caso di NAT traversal solo perché gira anche su Windows.

Fai la modifica con una via di ritorno

Se la politica documentata e la topologia osservata lo richiedono entrambe, annota il valore precedente, applica la modifica tramite la configurazione gestita e non tramite uno script per profilo, e pianifica il riavvio. Su un server che ospita altri carichi di lavoro, questa non è una modifica innocua.

Il dispositivo NAT deve comunque trasportare il traffico incapsulato e il traffico di ritorno. Un valore di registro non crea alcuna regola di inoltro, non allinea alcuna proposta e non convalida alcuna identità, quindi una connessione che inizia a funzionare dopo la modifica può funzionare per un motivo del tutto diverso. Riprova il protocollo originale con la topologia originale, poi annota quale fase è fallita e perché ci si aspettava che il valore la risolvesse. Quella frase è ciò che trasforma una voce di internet in una configurazione che puoi difendere.

Articoli correlati