Cisco ASA verso Azure VPN: coppie di prefissi del selettore di traffico

Il tunnel si alza, IKE sembra sano e nulla lo attraversa. È la forma abituale di un problema di selettore da ASA ad Azure, ed è per questo che scrivo il contratto prima di toccare una delle due console. Il contratto è fatto di quattro cose: gli oggetti che identificano ciascun peer, il modello di connessione, le coppie di prefissi esatte e la verifica che prova ogni coppia. Sbaglia queste e ogni comando successivo eseguirà il debug di una configurazione che non avresti dovuto costruire. Questo runbook è l’ordine che uso, con i comandi che mostrano quale oggetto è davvero errato.

Annota i quattro oggetti prima di configurare

Parti dalla release e dalla piattaforma ASA, dall’endpoint pubblico, dal tipo e dallo SKU del gateway VPN di Azure e dal gateway di rete locale che rappresenta il tuo lato. Quei quattro nomi sono il vocabolario di tutto ciò che segue, e ciascuno ha un proprietario diverso quando qualcosa si rompe.

Se due di essi sono ancora supposizioni, fermati. Un elenco di prefissi errato nel gateway di rete locale non è un problema di tuning.

Scegli un solo modello di connessione e smetti di mescolare i template

Un progetto con crypto map e un progetto con tunnel interface sono configurazioni diverse, e un template per l’uno non diventa valido per l’altro modificando l’indirizzo del peer. Registra quale stai costruendo prima di incollare qualsiasi cosa, perché la discordanza emerge più tardi come problema di selettore anziché come errore di configurazione. La guida all’interoperabilità ASA di Microsoft copre entrambi i modelli e indica quale modello di gateway Azure presuppone ciascuno. Se le tue note non nominano il modello, non hai ancora un progetto.

Un gateway Azure route-based con selettori di traffico policy-based è un’opzione specifica documentata, non il default. Se il tuo progetto dipende da essa, il progetto deve dirlo, perché il modello di selettore route-based predefinito si comporta diversamente sul lato Azure.

Anche i limiti di versione fanno parte del contratto. Un vecchio rapporto sul campo relativo a un limite dei domini di cifratura è un dato su release particolari, non una proprietà permanente di ogni ASA.

Elenca le coppie di prefissi, non gli aggregati

Scrivi la matrice. Da A e B on-premises verso X e Y di Azure sono quattro coppie, e ciascuna richiede copertura o un’esclusione esplicita. Ridurre A e B a un unico aggregato include anche tutto ciò che sta tra loro, ed è così che un progetto si ritrova silenziosamente un buco.

Controlla ciò che i peer hanno negoziato, non ciò che hai salvato. L’elenco delle reti locali e remote sull’ASA è l’intenzione; i CHILD SA sono il risultato.

Quando manca una coppia, di solito la correzione è una riga di access-list o una voce del selettore, non un nuovo tunnel.

Verifica con comandi che nominano l’oggetto

Sull’ASA conferma la sessione IKE, poi gli SA IPsec, poi le coppie di selettori. Ogni comando risponde a una domanda diversa, ed eseguire solo il primo è il modo in cui «il tunnel è attivo» diventa una conclusione falsa. Leggi l’output per il peer che hai davvero configurato, non per l’SA che capita per primo nell’elenco. Il lato Azure risponde alle stesse tre domande dal proprio punto di vista.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

Poi chiedi ad Azure lo stato della connessione con az network vpn-connection show --name <connection> --query connectionStatus. Connesso con zero byte nel percorso dati è un problema di selettore, non di routing.

Prova un flusso consentito per coppia, ispeziona l’indirizzo sorgente visto sul lato remoto e prova una risorsa che dovrebbe essere negata. Solo quest’ultimo test dimostra che il confine esiste ancora.

Tieni l’ambito di cifratura separato dal permesso di accesso

Un selettore ampio non è un permesso. Se il layout supportato è più ampio della policy applicativa, tieni i servizi ristretti nelle regole del firewall e lascia l’ambito di cifratura dove deve stare.

Le route dei workload Azure e le route di ritorno on-premises vengono esaminate separatamente. Gli annunci BGP, l’ambito di rete statico e le route definite dall’utente devono descrivere lo stesso percorso, e nessuno di essi può catturare in modo ricorsivo il trasporto del peer.

Rollback e la prova che ha funzionato

Conserva la configurazione running precedente prima di cambiare i selettori e conosci l’unico comando che la ripristina. Sull’ASA significa una copia salvata e il relativo percorso di ripristino, non un ricordo di ciò che hai modificato. Scrivi il comando di ripristino nel ticket di modifica mentre la modifica è ancora ipotetica. Poi riesegui gli stessi tre controlli: stato IKE, coppie di SA IPsec, un flusso consentito per coppia.

Se una coppia fallisce ancora dopo il ripristino, la modifica non era la causa, e ti sei appena risparmiato un secondo disservizio.