Il ping dal gateway IPsec usa un altro indirizzo sorgente
Un ping avviato sul gateway stesso sceglie la propria sorgente, e quella sorgente cambia la policy e il percorso di ritorno. Scegliete il test che dimostra ciò che vi serve.
Eseguite il ping verso il lato remoto dal gateway IPsec, non ricevete risposta e concludete che il tunnel è guasto, mentre ogni carico di lavoro dietro il gateway passa traffico normalmente. I due risultati non si contraddicono. Un ping avviato sul gateway è un pacchetto con sorgente locale, e il gateway sceglie un indirizzo sorgente dalla propria tabella di routing. Questa scelta può differire dagli indirizzi usati dal traffico reale del sito, il che cambia quale policy corrisponde e quale percorso di ritorno si applica. Decidete cosa deve dimostrare il test prima di leggere qualcosa nel suo risultato.
Tre domande diverse a cui un ping può rispondere
La prima domanda è se il lato remoto è raggiungibile da questo host. La seconda è se i selettori del tunnel o la policy basata sulle rotte ammettono traffico da una sorgente specifica. La terza è se il traffico inoltrato da un carico di lavoro dietro il gateway funziona da un capo all’altro. Un solo comando non può rispondere a tutte e tre, e l’indirizzo sorgente è ciò che le separa.
Scegliete prima la domanda. Altrimenti un ping fallito diventa la prova della teoria che avevate già.
Perché il gateway sceglie un indirizzo che non vi aspettavate
Quando fate ping a una destinazione, lo stack locale sceglie una sorgente dalla rotta che vi corrisponde. Su un tunnel basato sulle rotte può essere l’indirizzo di collegamento dell’interfaccia del tunnel, che in molti progetti di sito è una coppia 169.254.x.x scelta per il salto punto a punto. Questi indirizzi esistono per far funzionare il collegamento; non vengono annunciati come reti sorgente delle applicazioni sul lato remoto.
Quindi il lato remoto può ricevere una richiesta di echo da un indirizzo verso cui non ha una rotta di ritorno, o da uno che nessun selettore corrisponde. Il tunnel può essere sano e il ping può comunque fallire, ed è esattamente il falso negativo di cui tratta questo articolo.
Scegliete la sorgente deliberatamente
Su un gateway Linux controllato, scegliete una sorgente già assegnata localmente: ping -c 4 -I 10.30.0.1 10.40.0.20. Gli indirizzi qui sono illustrativi, quindi sostituiteli con l’indirizzo interno reale del gateway e una destinazione remota reale, e verificate che la sorgente scelta appartenga a questo dispositivo e sia ammessa dalla policy del sito.
Non prendete in prestito l’indirizzo di un carico di lavoro per il test. Impersonare un host non assegnato al gateway crea un risultato che nessuno può riprodurre, e su alcuni stack fallisce in modi che sembrano un guasto del tunnel.
Leggete il percorso di ritorno, non solo la richiesta
Verificate quale sorgente arriva davvero alla destinazione remota, compresa qualsiasi traduzione deliberata lungo il percorso. Poi verificate la rotta di ritorno del lato remoto verso quella sorgente e i selettori o la policy che la consentono. Una richiesta che arriva con una sorgente inattesa è una questione di routing e policy, non di crittografia.
È anche qui che una cattura aiuta più di un altro ping: mostra la sorgente che il lato remoto ha visto, ed è l’indirizzo che la sua risposta deve raggiungere.
Poi provate il carico di lavoro
Il test decisivo è un ping da un host normale dietro il gateway a un host normale dietro il gateway remoto. Questo esercita il ruolo di inoltro del gateway, la vera sorgente dell’applicazione e il vero percorso di ritorno, che è il flusso a cui tengono gli utenti.
Tenete i risultati separati nelle vostre note: raggiungibilità dal gateway, ammissione della policy per una sorgente scelta e traffico inoltrato. Un ping fissato con successo è una prova utile che il tunnel trasporta qualcosa; non è la prova che ogni flusso inoltrato funzioni. E una sorgente del gateway scelta automaticamente che non è raggiungibile non è la prova che il tunnel del sito sia caduto.
Non aggiungete una rotta generale per 169.254.0.0/16 solo per ottenere una risposta diagnostica. Questo scambia un test fuorviante con una decisione di routing permanente, e la persona successiva la eredita senza il contesto.