Quale VRF raggiunge il peer VPN e quale trasporta il pacchetto?

Ogni tunnel all’interno di un contesto di routing del cliente deve comunque raggiungere il proprio peer remoto, e quella ricerca può avvenire in una tabella completamente diversa. Sbagliare qui produce uno dei guasti più confusi nell’IPsec consapevole del VRF: il tunnel sale, le rotte sembrano presenti e il traffico muore perché una delle due ricerche ha usato il contesto sbagliato. Eseguite i quattro passaggi seguenti in ordine e annotate le due destinazioni separatamente.

Due ricerche, un tunnel

Il pacchetto incapsulato esterno è indirizzato all’indirizzo di trasporto del peer ed è instradato prima che esista qualsiasi protezione. Il pacchetto interno è indirizzato a un server del cliente ed è instradato dopo la decapsulazione, all’interno del contesto del cliente. Sono due destinazioni, due ricerche e spesso due tabelle diverse.

La documentazione Cisco per l’IPsec consapevole del VRF li chiama VRF della porta d’ingresso e VRF interno. La porta d’ingresso trasporta il traffico cifrato e il contesto interno trasporta il traffico protetto. Nulla, nel dare a un tunnel il nome di un cliente, fa comparire una delle due rotte.

Quindi elencate quattro fatti prima di modificare una configurazione: l’indirizzo di trasporto del peer e il contesto che lo raggiunge, poi il prefisso del server e il contesto che lo raggiunge. Se non riuscite a compilare tutti e quattro, state per tirare a indovinare. Indovinare in questo campo costa caro, perché una rotta aggiunta alla tabella sbagliata può far funzionare un flusso e romperne un altro in silenzio. I quattro fatti richiedono dieci minuti per essere raccolti e fanno risparmiare un giorno di analisi delle catture.

Confermate la ricerca di trasporto del peer

Cominciate dalla porta d’ingresso, perché un tunnel che non raggiunge il proprio peer non lascerà mai passare un solo pacchetto protetto. Su IOS chiedete la rotta verso il peer all’interno del VRF di trasporto anziché nella tabella globale.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

Il primo comando risponde se l’indirizzo del peer è raggiungibile in quel contesto, il secondo elenca i VRF realmente esistenti e il terzo mostra se si è formata un’associazione di sicurezza. Un indirizzo del peer che si risolve solo nella tabella globale è l’errore classico della porta d’ingresso, e si presenta come una negoziazione IKE che non inizia mai.

Controllate anche l’assegnazione dell’interfaccia. Il comportamento documentato richiede che il VRF della porta d’ingresso del tunnel e il VRF dell’interfaccia WAN coincidano; una discrepanza può lasciar uscire un pacchetto e comunque impedire che la risposta venga elaborata nel contesto corretto.

Confermate la ricerca interna del server

Una volta dimostrata la porta d’ingresso, passate al contesto del cliente e ponete la stessa domanda sul prefisso del server. Questa ricerca decide se un pacchetto decapsulato può essere inoltrato.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

Il primo comando mostra la rotta interna, e il secondo mostra lo stato della sessione insieme ai contesti che la piattaforma vi ha associato. Se la rotta esiste ma il dettaglio della sessione nomina il contesto interno sbagliato, il tunnel sta inoltrando verso una tabella che non conosce il prefisso del cliente.

Una rotta nella tabella globale non è prova per nessuna delle due ricerche. Le rotte globali si usano quando un pacchetto non è associato a un VRF, e un’interfaccia di tunnel assegnata a un contesto cliente cambia quell’associazione. Se manca la rotta interna, il pacchetto viene decapsulato e poi scartato per mancanza di una voce di inoltro, il che sembra una perdita di pacchetti e non un errore di routing.

Mettete l’impostazione dove il modello se l’aspetta

La stessa documentazione distingue modelli di configurazione, e un’impostazione che appartiene a uno non appartiene necessariamente all’altro. Per le interfacce di tunnel con protezione del tunnel, il VRF interno è definito sull’interfaccia di tunnel. Per i progetti basati su crypto map, il VRF interno fa parte della voce crypto map. Spostare un comando dal nome simile tra modelli senza verificarne il ruolo è il modo in cui un progetto funzionante diventa intermittente.

Routing e identità sono questioni separate. La raggiungibilità non sostituisce mai un profilo peer che il dispositivo accetterà, e una rinomina di VRF non deve alterare le credenziali offerte. Verificate entrambe dopo ogni modifica, perché un tunnel che negozia con il profilo sbagliato può comunque formare un’associazione e non inoltrare nulla.

Infine, registrate i quattro fatti e i comandi che li hanno dimostrati nel registro delle modifiche. Il prossimo ingegnere erediterà il tunnel e non il ragionamento, e una breve nota che nomina entrambi i contesti vale più di un diagramma che nessuno aggiorna.