Cinque ruoli dell'indirizzo in un profilo IPsec, e quale è sbagliato

Cinque compiti diversi ricevono un indirizzo in una definizione di connessione tipica, e non devono necessariamente concordare tra loro. Gli amministratori si bloccano perché un istinto sensato, far puntare tutti i campi allo stesso host, è sbagliato per almeno tre di essi. La via d'uscita è nominare prima il sintomo e poi guardare il campo o i due campi che potrebbero produrlo.

I cinque compiti, nell'ordine in cui contano

L'endpoint di trasporto è il punto in cui viene consegnato lo scambio IKE. L'identità autenticata è il nome che ciascun lato dimostra, e viene verificata rispetto alla politica, non rispetto a una tabella di routing. Le sottoreti protette sono i selettori che decidono quale traffico interno appartiene al tunnel. Poi c'è l'origine usata quando il gateway stesso avvia una conversazione, e infine il salto successivo del sottolivello per raggiungere il peer.

Le etichette dei partecipanti come left e right sono convenzioni per i due lati di una connessione, non sinonimi di locale e remoto. Leggete il manuale dell'implementazione realmente installata prima di supporre che una chiave significhi ciò che un altro prodotto intendeva con essa.

Decisione uno: non si stabilisce nulla

Quando nei registri non compare alcuno scambio, l'endpoint è il primo sospetto: un indirizzo sbagliato, un percorso filtrato o un'interfaccia su cui il demone non è in ascolto. Passate ai campi dell'identità solo dopo che la stretta di mano è visibile, perché l'identità si giudica dentro lo scambio, non prima. Un percorso filtrato e un indirizzo sbagliato sembrano identici dal lato del client, quindi controllate il lato in ascolto prima di modificare qualsiasi cosa. Confermate che il demone sia legato all'interfaccia che vi aspettate, perché un servizio in ascolto su un indirizzo appare esattamente come un percorso bloccato.

Un indirizzo pubblico osservato attraverso la traduzione non è la stessa cosa dell'identità che un peer dimostra. Cambiare un indirizzo per farlo corrispondere a ciò che una cattura di pacchetti mostra all'estremità remota è una correzione comune e sbagliata.

Decisione due: il tunnel è attivo e il traffico muore

I selettori decidono cosa entra nel tunnel, e una discordanza qui produce una connessione che negozia con successo mentre l'applicazione continua a fallire. Il lato remoto deve indicare il vostro intervallo protetto come suo intervallo remoto, ed è esattamente lì che si insinuano valori invertiti.

Leggete entrambe le configurazioni affiancate prima di modificare. L'intervallo locale su un host è l'intervallo remoto sull'altro, e un solo paio invertito spiega un tunnel che non trasporta nulla. Restringete il paio prima di toccare le chiavi: una sottorete dentro il tunnel e una fuori vi dicono se la colpa è del selettore o dell'instradamento.

Decisione tre: fallisce solo il traffico proprio del gateway

Il traffico inoltrato per i client può funzionare perfettamente mentre una richiesta avviata dal gateway stesso fallisce, perché quel flusso non ha un'origine client da ereditare. L'impostazione dell'origine preferita esiste proprio per questo caso, e non è traduzione di origine: sceglie un indirizzo di origine invece di riscriverne uno.

Un'applicazione che lega esplicitamente un altro indirizzo può scavalcare la preferenza, quindi confermate l'origine effettiva del pacchetto prima di concludere che l'impostazione venga ignorata. Catturate sull'interfaccia propria del gateway invece di fidarvi dell'intenzione della configurazione.

Il salto successivo è un'istruzione locale

Il salto successivo del sottolivello dice a questo host come raggiungere il peer, e il lato remoto non ha bisogno dello stesso valore. Trattarlo come un'impostazione condivisa, o codificare in modo fisso un gateway predefinito, si rompe nel momento in cui la rotta cambia o compare un secondo percorso.

Alcune implementazioni offrono valori speciali qui. Ciò che il manuale elenca per la versione installata è l'unica risposta sicura, e la tabella di routing locale è la prova che ha funzionato. Quando un peer è raggiungibile per nome ma non per indirizzo, quella discordanza è il risultato, non un dettaglio da aggirare.

Leggete il profilo da entrambe le estremità

Invertire i ruoli sulla carta è la revisione più rapida che esista: scambiate gli intervalli protetti, mantenete il salto successivo proprio di ciascun lato e l'identità propria di ciascun lato. Tutto ciò che non sopravvive allo scambio è probabilmente assegnato al compito sbagliato.

Poi provate un flusso per ruolo: raggiungibilità tra peer, un flusso client interno e una richiesta originata dal gateway. Tre test vi dicono quale compito è assegnato male senza riaprire la configurazione. Aggiungete il risultato al ticket accanto al campo che avete modificato, perché il prossimo ingegnere incontrerà lo stesso profilo.