Cisco ASA a Azure VPN: parells de prefixos dels selectors de trànsit

El túnel s'aixeca, IKE sembla sa i no hi passa res. Aquesta és la forma habitual d'un problema de selectors d'ASA a Azure, i per això escric el contracte abans de tocar qualsevol de les dues consoles. El contracte són quatre coses: els objectes que identifiquen cada peer, el model de connexió, els parells de prefixos exactes i la verificació que demostra cada parell. Si us equivoqueu en això, cada ordre posterior depura una configuració que no hauríeu d'haver construït. Aquest runbook és l'ordre que faig servir, amb les ordres que mostren quin objecte és realment incorrecte.

Anoteu els quatre objectes abans de configurar

Comenceu per la versió i la plataforma d'ASA, el punt de connexió públic, el tipus i l'SKU de la passarel·la VPN d'Azure, i la passarel·la de xarxa local que representa el vostre costat. Aquests quatre noms són el vocabulari de tot el que segueix, i cada un té un propietari diferent quan alguna cosa es trenca.

Si dos d'ells encara són suposicions, atureu-vos. Una llista de prefixos incorrecta a la passarel·la de xarxa local no és un problema d'ajust.

Trieu un model de connexió i deixeu de barrejar plantilles

Un disseny amb crypto map i un disseny amb tunnel interface són configuracions diferents, i una plantilla per a un no esdevé vàlida per a l'altre editant l'adreça del peer. Anoteu quin esteu construint abans d'enganxar res, perquè la discrepància apareix més tard com un problema de selectors i no com un error de configuració. La guia d'interoperabilitat d'ASA de Microsoft cobreix els dos patrons i indica quin model de passarel·la d'Azure pressuposa cada un. Si les vostres notes no nomenen el model, encara no teniu un disseny.

Una passarel·la d'Azure basada en rutes amb selectors de trànsit basats en polítiques és una opció documentada específica, no la predeterminada. Si el vostre disseny en depèn, el disseny ho ha de dir, perquè el model de selectors predeterminat basat en rutes es comporta de manera diferent al costat d'Azure.

Els límits de versió també formen part del contracte. Un informe de camp antic sobre un sostre als dominis de xifratge és una dada sobre versions concretes, no una propietat permanent de cada ASA.

Enumereu els parells de prefixos, no els agregats

Escriviu la matriu. A i B locals cap a X i Y d'Azure són quatre parells, i cada un necessita cobertura o una exclusió explícita. Col·lapsar A i B en un sol agregat també inclou tot el que hi ha entremig, i així és com un disseny es queda silenciosament amb un forat.

Comproveu què han negociat els peers, no què heu desat. La llista de xarxes locals i remotes a l'ASA és la intenció; els CHILD SA són el resultat.

Quan falta un parell, la solució és normalment una línia d'access-list o una entrada de selector, no un túnel nou.

Verifiqueu amb ordres que nomenen l'objecte

A l'ASA, confirmeu la sessió IKE, després els SA d'IPsec i després els parells de selectors. Cada ordre respon una pregunta diferent, i executar només la primera és com l'afirmació que el túnel està aixecat es converteix en una conclusió falsa. Llegiu la sortida del peer que heu configurat realment, no del SA que casualment sigui el primer de la llista. El costat d'Azure respon les mateixes tres preguntes des del seu punt de 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

Després pregunteu a Azure l'estat de la connexió amb az network vpn-connection show --name <connection> --query connectionStatus. Connected amb zero bytes al camí de dades és un problema de selectors, no de routing.

Proveu un flux permès per parell, inspecteu l'adreça d'origen vista a l'altre costat i proveu un recurs que hauria de ser denegat. Aquesta última prova és l'única que demostra que el límit encara existeix.

Manteniu l'abast del xifratge separat del permís d'accés

Un selector ampli no és un permís. Si el disseny suportat és més ampli que la política de l'aplicació, manteniu els serveis estrets a les regles del tallafoc i deixeu l'abast del xifratge on ha d'estar.

Les rutes de càrrega de treball d'Azure i les rutes de retorn locals es revisen per separat. Els anuncis BGP, l'abast de xarxa estàtic i les rutes definides per l'usuari han de descriure tots el mateix camí, i cap d'ells no pot capturar recursivament el transport del peer.

Reversió i la prova que ha funcionat

Guardeu la configuració en execució anterior abans de canviar els selectors i sapigueu quina és l'única ordre que la torna a posar. A l'ASA això vol dir una còpia desada i el camí de restauració corresponent, no un record del que heu editat. Escriviu l'ordre de restauració al tiquet de canvi mentre el canvi encara és hipotètic. Després torneu a executar les mateixes tres comprovacions: estat d'IKE, parells d'IPsec SA i un flux permès per parell.

Si un parell encara falla després de la restauració, el canvi no n'era la causa, i us acabeu d'estalviar una segona caiguda.