Quale fase della VPN ha fallito: IPsec, il controllo L2TP o l’autenticazione PPP

Avete cambiato la password e nulla si è mosso, perché il guasto non è mai stato in PPP. L2TP/IPsec segnala un solo errore di connessione per cinque consegne molto diverse, e ogni consegna ha la sua riparazione. Lavorate all’indietro: trovate l’ultima fase riuscita e cambiate solo ciò che viene dopo. L’ordine qui sotto decide anche quali prove raccogliete per prime.

Rispondete a quattro domande in ordine

Forzate un tentativo nuovo, perché alcuni client continuano a mostrare l’errore precedente finché il profilo non viene disconnesso e riconnesso. Poi rispondete: c’era un’associazione di sicurezza IPsec, sono comparsi una connessione di controllo L2TP e una chiamata, PPP è arrivato a un verdetto di autenticazione e IPCP ha dato un indirizzo al client? Il primo no è la fase che correggete. Tutto ciò che segue non è testato, quindi un nome utente rifiutato non dimostra nulla quando non è mai esistita un’associazione.

Sincronizzate gli orologi dei due estremi prima di confrontare. Un nuovo tentativo che ha ripulito IPsec e ha fallito su PPP sembra un solo guasto quando il client mostra solo il messaggio finale e il registro del server conserva ancora il tentativo precedente. Leggete per marca temporale, non per la riga più rumorosa.

Quando avete solo lo screenshot dell’utente, affidatevi alla separazione più economica: una chiave precondivisa sbagliata e un xl2tpd che non risponde mai producono lo stesso testo nella finestra di Windows, ma uno richiede un segreto cambiato a entrambi gli estremi e l’altro un demone avviato o una regola del firewall sul server stesso. Un dispositivo in mezzo non può scartare il 1701 interno una volta che IPsec in modalità trasporto lo ha avvolto, quindi non cercate un filtro di percorso che non esiste.

Che cosa possiede davvero ogni strato

IPsec protegge i pacchetti tra i due peer; L2TP trasporta una sessione PPP dentro quel percorso protetto, per questo RFC 3193 prescrive la modalità trasporto invece di un tunnel proprio. L’etichetta del client dice L2TP, quindi tunnel e accesso sembrano un unico meccanismo. Non lo sono: la connessione di controllo L2TP autentica gli estremi del tunnel dove un’implementazione lo abilita, e PPP autentica separatamente l’utente con CHAP, PAP o MS-CHAPv2 secondo la politica del server.

Questa separazione spiega i due segreti che le persone continuano a confondere. Una chiave precondivisa autentica i peer IPsec. Un nome utente e una password identificano l’utente davanti a PPP. Riscrivere il segreto condiviso di Windows su un profilo che si autentica con certificati non cambia nulla nella fase che fallisce, e modificare la password PPP non può fornire un canale protetto mancante. La stessa moderazione vale per il controllo d’identità: non disattivate l’identità del peer o la convalida del certificato per ottenere un tunnel, perché allora ciò che si connette è il percorso, non il peer.

Neanche l’autenticazione è la fine di PPP. Dopo che l’utente è accettato, IPCP negozia l’indirizzo del client e le opzioni DNS e WINS che il server è disposto a consegnare. Un client può superare CHAP o MS-CHAPv2 e restare senza indirizzo, il che è un guasto dentro PPP e non un problema di routing. L2TP semplice senza IPsec resta valido e non protetto, quindi una connessione riuscita non dimostra mai che il traffico sia protetto; controllate ciò che il server impone, non l’etichetta del client.

Decidete dalla prima fase mancante

Leggete la tabella per il primo elemento mancante, da sinistra a destra. La colonna di destra è l’unico lavoro che vale la pena in quel momento; tutto ciò che sta alla sua sinistra è già dimostrato, e ritestarlo brucia la finestra di interruzione senza aggiungere informazioni.

Tre righe meritano un avvertimento. La riga 1701 è dove di solito atterrano i client Windows dietro NAT: l’associazione si completa, poi non arriva nulla, e la causa è l’incapsulamento, non una password sbagliata. La riga IPCP è quella letta male come problema di rotta, perché Windows avvolge l’indirizzo mancante nell’errore 720 e l’icona della barra dice solo che la connessione è fallita; quel guasto sta dopo l’autenticazione e prima del routing. L’ultima riga non è affatto un guasto IPsec, anche se l’icona dice disconnesso.

Comandi che separano gli strati

Su un server Linux con strongSwan, swanctl --list-sas elenca le associazioni stabilite con l’identità del peer, e ipsec statusall copre host strongSwan e libreswan più vecchi. Sotto, ip xfrm state mostra le associazioni reali del kernel, mentre ss -lunp | grep 1701 prova dove è legato xl2tpd. Avviate xl2tpd -D in primo piano per vedere apparire connessioni di controllo e chiamate, e attivate il debug di pppd in /etc/ppp/options.xl2tpd per vedere il metodo offerto e la risposta.

Quando i registri mostrano un’autenticazione riuscita, la domanda successiva è se IPCP si è completato. Verificate che ip range nella sezione [lns default] di /etc/xl2tpd/xl2tpd.conf abbia ancora indirizzi liberi, e che /etc/ppp/options.xl2tpd porti davvero ms-dns e ms-wins se il client se li aspetta. Un pool esaurito e un’opzione DNS mancante si vedono diversi sul filo: il primo lascia il client senza indirizzo e con un 720, il secondo dà un indirizzo ma nessun resolver, quindi i nomi falliscono mentre i ping verso indirizzi grezzi funzionano. Nessuno dei due si ripara reinserendo la password.

Sul client il plugin L2TP di NetworkManager scrive la conversazione pppd nel journal, quindi journalctl -u NetworkManager -b di solito separa tunnel attivo, autenticazione rifiutata da nessun tunnel. Su Windows, Get-VpnConnection riporta le impostazioni reali di autenticazione del profilo, e gli eventi RasClient sotto Application nel Visualizzatore eventi nominano il componente che fallisce. Quando la finestra è troppo vaga, attivate netsh ras set tracing * enable.

Le catture richiedono una precauzione. Con IPsec in modalità trasporto l’UDP 1701 interno è cifrato, quindi una cattura sull’interfaccia esterna mostra ESP, o UDP 4500 sotto NAT-T, e nessun L2TP. Che 1701 manchi in una cattura è atteso e non è prova di una porta bloccata; osservate se i contatori ESP o 4500 si muovono.

NAT, MTU e rotte: dove lo stack vi inganna

NAT rompe le ipotesi prima che qualcosa sia autenticato. ESP è un protocollo IP a sé, quindi un dispositivo che traduce lo scarta a meno che i peer non incapsulino; è ciò che fornisce l’UDP 4500. Su un server Windows che sta esso stesso dietro un router domestico o un gateway NAT cloud, la fase IPsec fallisce con l’errore 789 finché AssumeUDPEncapsulationContextOnSendRule non viene impostato a 2 sotto la chiave PolicyAgent e la macchina non si riavvia, e il guasto resta indistinguibile da una porta chiusa. I client dietro NAT sono più facili: con un indirizzo pubblico sul server, NAT-T su UDP 4500 li trasporta e quel valore non entra in gioco.

Una volta attivo PPP, un MTU con buco nero imita un tunnel morto: i pacchetti piccoli passano, una stretta di mano TLS o il caricamento di una pagina si bloccano, e il client può ancora mostrare connesso. Abbassate l’MTU dell’interfaccia o fissate l’MSS sul gateway prima di incolpare il server. Il routing a tunnel diviso è l’altro impostore; una sottorete inviata con la maschera sbagliata lascia il tunnel sano e un’applicazione irraggiungibile. Un nome host privato aggiunge il suo salto: se la query esce dal resolver locale, il nome non si risolve prima che venga provata qualsiasi rotta.

Lista di controllo prima di toccare le credenziali

Percorrete la lista in ordine e fermatevi al primo elemento che fallisce. Ogni passo costa poco, e ciascuno esclude un’intera classe di modifiche.

1. Confermate che l’associazione esiste a entrambi gli estremi, accoppiata per identità del peer e non per un’etichetta connesso.
2. Confermate che l’UDP 1701 raggiunge xl2tpd; un’associazione senza chiamata è il vostro guasto.
3. Leggete il verdetto di PPP e, se ha autenticato, il risultato di IPCP, prima di supporre che la password sia sbagliata.
4. Solo ora reinserite le credenziali nel formato atteso dal server, perché un prefisso di dominio cambia l’account.
5. Se fallisce ancora, catturate entrambi gli estremi con marche temporali allineate e confrontate fase per fase.

Fermarsi al secondo passo significa un problema di percorso o di incapsulamento, e nessuna modifica della password lo sposterà. Fermarsi al terzo passo significa che il registro nomina già il metodo o il pool di indirizzi da correggere. In entrambi i casi il prossimo cambiamento è uno che potete giustificare, e smettete di girare intorno a impostazioni che non sono mai state coinvolte.