L2TP/IPsec si connette su una rete e va in timeout su un’altra

Lo stesso portatile, lo stesso profilo e la stessa password funzionano in un edificio e falliscono in un altro. Quel confronto è la prova più utile del ticket, ed è di solito la prima cosa che viene scartata. Tra due reti di accesso lo scambio passa attraverso una traduzione degli indirizzi diversa, filtri diversi e helper del router diversi. Tenere fisso il client e cambiare solo la rete è il modo per scoprire quale di questi elementi conta.

Fissa il client prima di confrontare le reti

Non cambiare nulla sul dispositivo finché non hai registrato il caso funzionante: versione del client, contenuto del profilo, nome del server e ora della connessione riuscita. Poi riproduci il guasto sulla seconda rete durante la stessa sessione, così lo stato del client è il più possibile identico. Un profilo modificato tra i due tentativi invalida l’intero confronto. L’obiettivo è una sola variabile, e quella variabile è la rete.

Verifica prima l’accesso internet ordinario sulla rete che non funziona, incluso un portale ospiti se presente. Un portale mai soddisfatto produce un timeout che somiglia esattamente a un tunnel filtrato, e quel controllo richiede un minuto.

Quattro fasi, quattro messaggi di errore diversi

Una connessione L2TP/IPsec attraversa quattro fasi, e RFC 3193 descrive la disposizione che lega le prime due. La negoziazione IKE è il punto in cui un percorso filtrato produce un timeout silenzioso. L’autenticazione IPsec è il punto in cui una discordanza di certificato o di chiave precondivisa produce invece un rifiuto esplicito. L’impostazione del tunnel L2TP è il punto in cui un’associazione di sicurezza già stabilita può comunque non portare da nessuna parte, e il login PPP è il punto in cui una credenziale errata produce finalmente un guasto visibile. Leggi il log della fase che si è fermata, non dell’ultima riga stampata.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

Il log di strongSwan mostra se lo scambio IKE ha raggiunto una proposta e se il peer ha risposto del tutto, il che separa la raggiungibilità dalla policy. Il log di xl2tpd riprende dove finisce IPsec, quindi un’associazione di sicurezza stabilita senza nulla in quel log indica la fase L2TP. L’interrogazione della rotta conferma che il client sta inviando verso l’indirizzo server che pensi, il che intercetta una risposta DNS obsoleta ereditata dalla rete precedente. Insieme, i tre output nominano una fase invece di un sintomo.

Confronta la profondità NAT e il comportamento dell’helper

La traversata NAT sposta il traffico protetto sull’incapsulamento UDP quando viene rilevata una traduzione, per cui i numeri di porta che trasportano una sessione funzionante possono differire da quelli di uno schema statico. Consentire un solo pacchetto di configurazione non dimostra nulla sul resto dello scambio, e una scansione delle porte esterna non può dirti come il peer tratta il traffico autenticato valido. Un secondo strato di traduzione cambia di nuovo il quadro, perché la mappatura ora esiste due volte e scade secondo due calendari diversi. La traduzione di livello operatore su una connessione mobile è la ragione abituale per cui un profilo di ufficio funzionante fallisce su un hotspot del telefono.

Gli helper del router variano quanto le reti. Alcuni firmware intercettano e riscrivono lo scambio, altri smettono soltanto di scartarlo, e altri applicano l’impostazione solo in una modalità precedente. Leggi la descrizione che il firmware stesso dà della casella, e dove esiste una modalità di compatibilità, provala come una modifica deliberata invece di tre in una volta.

Client in uscita, server in entrata: due problemi diversi

Un client in uscita e un server in entrata richiedono una raggiungibilità a monte diversa, e una funzione di passaggio che aiuta il primo non fa nulla per il secondo. Un router domestico che lascia al portatile raggiungere un gateway remoto non accetta per questo connessioni in entrata verso un server dietro di sé. Confondere i due ti manda a cercare un inoltro delle porte che non è mai stato il problema. Dichiara quale ruolo ha il dispositivo che fallisce prima di confrontare qualsiasi cosa.

Dopo una modifica supportata, ripeti la stessa connessione e annota la fase raggiunta. Tieni insieme il profilo funzionante e la nota sulla rete che fallisce, e non reimpostare le credenziali né reinstallare il client, perché questo scarta la prova su cui era costruito il confronto.