L2TP, GRE o IPsec: quale livello deve trasportare la sessione?

Due domande si intrecciano ogni volta che L2TP, GRE e IPsec finiscono nella stessa nota di progetto: quale sessione sto trasportando, e quale livello la protegge? Se si sbaglia la prima, tutto ciò che sta a valle resta internamente coerente mentre si risolve il problema sbagliato — una sovrapposizione instradata costruita dove gli utenti dovevano collegarsi in remoto, oppure un concentratore di accesso remoto che sostituisce un gateway da sito a sito. Il foglio di lavoro qui sotto impone questa distinzione prima che qualcuno acceda a un dispositivo. Compilalo in ordine e ogni riga diventa qualcosa che puoi verificare da sola.

Parti dalla sessione, non dall’elenco dei protocolli

Un utente remoto con una sessione PPP e una sovrapposizione instradata tra due gateway sono relazioni di rete diverse, anche quando entrambe finiscono avvolte in IPsec. La prima termina un collegamento per utente e richiede assegnazione di indirizzi, autenticazione di una persona o di un dispositivo e una politica che indichi quali reti interne quell’utente può raggiungere. La seconda inoltra pacchetti tra siti in cui nessuno si collega.

Scrivi una frase che indichi quale delle due stai costruendo, poi rileggila come se fossi la persona che deve gestirla. Se la frase ha bisogno della parola 'e', stai costruendo entrambe, e il foglio ha bisogno di due colonne invece di una colonna di compromesso che serve a metà ciascuna. Se nomina un utente ma nessun pool di indirizzi, o un prefisso ma nessuna politica di inoltro, la frase è ancora incompleta. La formulazione suona burocratica, ma è il punto più economico per intercettare un progetto che altrimenti verrebbe scoperto da un ticket al supporto.

Assegna a ogni livello esattamente un compito

L2TPv2 trasporta sessioni PPP tra i suoi due estremi. PPP esegue la negoziazione del collegamento e, quando viene negoziata, l’autenticazione dell’utente; L2TP non aggiunge alcuna crittografia, quindi un demone L2TP nudo non implementa nulla della relazione di sicurezza IPsec e appartiene solo a un collegamento di cui ti fidi già.

GRE è un incapsulamento tra due indirizzi. Trasporta pacchetti del livello di rete su una sovrapposizione logica e, da solo, non offre né riservatezza né un’identità del peer autenticata. Non è un difetto: l’intestazione è stata progettata semplice per restare economica da elaborare sull’hardware di inoltro. La conseguenza è che GRE risponde a 'come sposto questo pacchetto tra due indirizzi' e a nient’altro — esattamente la domanda che dovresti porgli.

Resta quindi IPsec come il livello che seleziona il traffico, autentica i peer e cifra ciò che gli è stato detto di proteggere. Quale traffico protegge è una decisione di configurazione che deve corrispondere all’incapsulamento che gli estremi generano davvero, perché una politica scritta per l’indirizzo esterno di GRE si comporta diversamente da una scritta per i prefissi interni. La specifica GRE tiene visibilmente separati payload, intestazione GRE e protocollo di consegna esterno, e la tua politica ha bisogno della stessa separazione.

Scrivi il percorso del pacchetto prima della configurazione

Prendi un pacchetto ed elenca ogni intestazione aggiunta, nell’ordine in cui viene aggiunta, indicando il dispositivo che la aggiunge. Per un utente in accesso remoto di solito è PPP dentro L2TP dentro IPsec; per una sovrapposizione tra siti, il pacchetto IP interno dentro GRE dentro IPsec. Se due dispositivi aggiungono la stessa intestazione, hai un loop o un tunnel duplicato, e nessuna modifica alla politica lo risolve.

La stessa lista fissa la MTU, perché la dimensione interna utilizzabile è la MTU di percorso misurata meno le intestazioni appena elencate e nient’altro. Non copiare un numero da un post di un forum: somma l’overhead di IP esterno, UDP ed ESP, poi GRE o L2TP, poi PPP dove si applica, e sottrailo dalla MTU di percorso che hai davvero misurato. I sintomi che compaiono solo sui trasferimenti grandi, o le sessioni che si stabiliscono e poi muoiono alla prima risposta grande, di solito risalgono a quella somma fatta a occhio.

Verifica ogni livello separatamente, dall’esterno verso l’interno

Esegui i controlli in ordine e fermati al primo che fallisce. Ogni riga risponde a una domanda diversa, quindi un guasto indica una colonna del foglio invece di dire che il tunnel è rotto.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Su un apparato Cisco l’equivalente dipende dal ruolo, e la sintassi esatta varia con la piattaforma e la release: show crypto session per i peer IPsec, i contatori dell’interfaccia per l’interfaccia GRE o tunnel, e la verifica VPDN o PPP per il ruolo di accesso remoto. Un insieme di comandi che termina PPP non dimostra nulla sul supporto GRE, e un’interfaccia GRE funzionante non dimostra nulla sul servizio PPP, quindi verifica il ruolo che hai davvero configurato invece di quello nel diagramma.

Annota ogni output accanto alla riga del foglio a cui appartiene. Le note prese mentre il guasto è attivo valgono più di una topologia ridisegnata dopo a memoria.

Ordina lo smontaggio, poi verifica di nuovo

Lo smontaggio procede al contrario per un motivo: togli il traffico protetto dalla politica IPsec prima di rimuovere l’incapsulamento per cui è stata scritta, altrimenti la politica continua a puntare a un’interfaccia che non esiste più e il successivo caricamento della configurazione fallisce in un punto che sembra non correlato. Su Linux questo significa eliminare le voci di stato e di politica prima dell’interfaccia di tunnel; su un router, rimuovere la voce crypto map o di profilo prima del tunnel.

Dopo la ricostruzione, ripeti le quattro osservazioni di accettazione una alla volta: raggiungibilità esterna, un’associazione IPsec stabilita, una sessione PPP stabilita dove il progetto ne prevede una, e inoltro interno verso un indirizzo di destinazione reale. Una luce verde non è prova per le altre tre, e quel divario è il guasto che sopravvive più a lungo in produzione — un tunnel attivo, cifrato e che non inoltra nulla perché la rotta interna non è mai stata aggiunta.

Tieni il foglio compilato accanto alla configurazione del dispositivo. Ogni colonna che non riesci a compilare è un livello senza compito assegnato, e un livello senza compito assegnato di solito è un livello che non dovrebbe stare nello stack.