Route predefinita tunneled su Cisco ASA: quando si applica davvero

Un utente in accesso remoto non raggiunge nulla oltre l'ASA, mentre lo stesso server risponde ai ping dalla LAN interna. Il tunnel si alza, il client ottiene un indirizzo dal pool, e il pacchetto esce comunque dalla route predefinita internet o sparisce. Questo schema di solito significa che il traffico decifrato non ha trovato una route propria ed è ricaduto sulla route predefinita ordinaria. La correzione non è un'altra regola NAT; è la route predefinita tunneled.

Parti dal sintomo, non dalla configurazione

Guarda dove va il pacchetto invece di dove ti aspettavi che andasse. Una cattura sull'interfaccia esterna durante una sessione fallita mostra il pacchetto decifrato diretto verso il gateway dell'ISP con l'indirizzo del pool ancora intatto, oppure non mostra nulla perché la ricerca è fallita. In entrambi i casi il tunnel non è il problema.

Il tunnel sembra sano in show vpn-sessiondb, ed è esattamente per questo che le persone continuano a fare debug di IKE.

A distinguerlo da uno scarto ACL è la direzione. Uno scarto ACL viene registrato e conteggiato, mentre una route mancante produce un fallimento di ricerca senza alcuna voce corrispondente. Esegui show route per la destinazione del client e leggi che cosa ha effettivamente selezionato l'ASA, incluso se è stata scelta una route predefinita e quale.

In che cosa la ricerca tunneled è diversa

La guida Cisco alla routing statico su ASA 9.23 documenta una route predefinita separata per il traffico VPN decifrato che non ha route statiche o apprese. La parola chiave tunneled contrassegna quella route, così un pacchetto decifrato può ricadere su un next hop diverso da quello che l'ASA usa per il proprio trasporto. Le route più specifiche vincono comunque, ed è per questo che un client può raggiungere 10.0.0.0/8 attraverso il gateway interno e perdere tutto il resto.

Una configurazione minima mantiene due route predefinite con next hop diversi. Una porta il traffico dell'ASA stesso, l'altra il traffico decifrato che non ha route migliori. Entrambi i next hop devono comunque essere raggiungibili dall'interfaccia a cui li colleghi.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Se entrambe le route predefinite puntano allo stesso next hop, la parola chiave non cambia nulla e il sintomo non si sposta.

Le restrizioni che decidono se funziona

La stessa guida consente una sola route predefinita tunneled e dichiara che ECMP non è supportato per essa, quindi non puoi bilanciare il carico su quel percorso. Elenca anche restrizioni riguardanti il route tracking, la verifica del reverse path e alcuni flussi di ispezione e gestione. Leggile rispetto alla release installata prima di progettare intorno alla funzionalità. Un progetto che le ignora di solito fallisce in un punto preciso anziché ovunque, ed è per questo che il sintomo sembra intermittente.

La verifica del reverse path è quella che morde nei progetti asimmetrici. Se la risposta arrivasse attraverso un'interfaccia diversa da quella che l'ASA si aspetta, il pacchetto viene scartato prima che il routing conti. Correggi la topologia o il percorso di ritorno invece di disattivare la verifica per forzare un next hop.

Il route tracking è una trappola a parte: l'oggetto monitorato di solito protegge la route predefinita ordinaria, non quella tunneled.

Che cosa la parola chiave non fa

Non sceglie l'indirizzo sorgente che l'ASA usa per costruire IKE. L'endpoint esterno del tunnel segue la selezione di interfaccia e sorgente della piattaforma, e la route predefinita tunneled non ha alcun ruolo in quella decisione. Cambiarla non riparerà una phase 1 che origina dall'indirizzo sbagliato.

Non trasforma nemmeno il next hop in un proxy. Se la destinazione si aspetta uno scambio HTTP CONNECT, inviare pacchetti IP grezzi a un host proxy ti dà solo un host che non li instrada. Configura invece il meccanismo proxy supportato dal client.

E non crea forwarding a valle. Il gateway verso cui punti ha comunque bisogno di una route di ritorno verso il pool VPN, più la traduzione di sorgente dove il progetto la richiede.

Verifica il percorso da un capo all'altro

Una volta che la route è a posto, controlla quattro cose in ordine: show route per una destinazione di cui il pool ha bisogno, una cattura sull'interfaccia verso il nuovo next hop, una cattura sul gateway stesso e un percorso di ritorno da quel gateway all'indirizzo del pool. Le prime due dimostrano che l'ASA ha scelto il percorso, le ultime due che qualcuno risponde su di esso.

Se il gateway risponde ma il client non vede mai una risposta, guarda la traduzione di sorgente e la route di ritorno prima di toccare di nuovo la tabella di routing.

Annota la release su cui hai validato, perché l'elenco delle restrizioni dipende dalla versione e un progetto che funziona su un treno può richiedere un percorso diverso su un altro. Quella nota sopravvive allo snippet di configurazione.