Cisco ASA către Azure VPN: perechi de prefixe ale selectorului de trafic

Tunelul urcă, IKE pare sănătos și nimic nu trece prin el. Aceasta este forma obișnuită a unei probleme de selector ASA–Azure, și de aceea scriu contractul înainte de a atinge oricare dintre console. Contractul are patru lucruri: obiectele care identifică fiecare peer, modelul conexiunii, perechile exacte de prefixe și verificarea care dovedește fiecare pereche. Greșiți aici și fiecare comandă ulterioară va depana o configurație pe care nu ar fi trebuit să o construiți. Acest runbook este ordinea pe care o folosesc, împreună cu comenzile care arată ce obiect este cu adevărat greșit.

Notați cele patru obiecte înainte de a configura

Începeți cu versiunea și platforma ASA, endpointul public, tipul și SKU-ul gateway-ului Azure VPN și gateway-ul de rețea locală care reprezintă partea dumneavoastră. Aceste patru nume sunt vocabularul pentru tot ce urmează, iar fiecare are un alt proprietar când ceva se strică.

Dacă două dintre ele sunt încă presupuneri, opriți-vă. O listă greșită de prefixe pe gateway-ul de rețea locală nu este o problemă de reglaj.

Alegeți un singur model de conexiune și nu mai amestecați șabloane

Un proiect crypto map și un proiect tunnel interface sunt configurații diferite, iar șablonul unuia nu devine valid pentru celălalt prin editarea adresei peer-ului. Notați pe care îl construiți înainte de a lipi ceva, pentru că nepotrivirea apare mai târziu ca problemă de selector, nu ca eroare de configurare. Ghidul de interoperabilitate ASA al Microsoft acoperă ambele modele și spune ce model de gateway Azure presupune fiecare. Dacă notițele nu numesc modelul, încă nu aveți un proiect.

Un gateway Azure bazat pe rute cu selectori de trafic bazați pe politici este o opțiune specifică documentată, nu implicită. Dacă proiectul depinde de ea, proiectul trebuie să spună asta, pentru că modelul implicit de selector bazat pe rute se comportă diferit pe partea Azure.

Limitele de versiune fac și ele parte din contract. Un raport vechi de teren despre o limită a domeniilor de criptare este un punct de date despre versiuni anume, nu o proprietate permanentă a fiecărui ASA.

Enumerați perechile de prefixe, nu agregările

Scrieți matricea. De la A și B locale la X și Y în Azure sunt patru perechi, iar fiecare are nevoie de acoperire sau de o excludere explicită. Unirea lui A și B într-o singură agregare include și tot ce se află între ele, și astfel proiectul crește în liniște o gaură.

Verificați ce au negociat peer-urile, nu ce ați salvat. Lista de rețele locale și la distanță de pe ASA este intenția; CHILD SA-urile sunt rezultatul.

Când lipsește o pereche, corecția este de obicei o linie access-list sau o intrare de selector, nu un tunel nou.

Verificați cu comenzi care numesc obiectul

Pe ASA confirmați sesiunea IKE, apoi SA-urile IPsec, apoi perechile de selector. Fiecare comandă răspunde la o altă întrebare, iar rularea doar a primeia este modul în care „tunelul este sus” devine o concluzie falsă. Citiți ieșirea pentru peer-ul pe care l-ați configurat efectiv, nu pentru SA-ul care se întâmplă să fie primul în listă. Partea Azure răspunde la aceleași trei întrebări din propriul punct de vedere.

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

Apoi întrebați Azure despre starea conexiunii cu az network vpn-connection show --name <connection> --query connectionStatus. Conectat cu zero octeți pe calea de date este o problemă de selector, nu de rutare.

Testați un flux permis pe pereche, inspectați adresa sursă văzută pe partea cealaltă și încercați o resursă care ar trebui refuzată. Doar acel ultim test dovedește că granița încă există.

Țineți domeniul de criptare separat de permisiunea de acces

Un selector larg nu este permisiune. Dacă aspectul acceptat este mai larg decât politica aplicației, țineți serviciile înguste în regulile de firewall și lăsați domeniul de criptare acolo unde trebuie să fie.

Rutele sarcinilor de lucru Azure și rutele de întoarcere locale sunt revizuite separat. Anunțurile BGP, domeniul de rețea static și rutele definite de utilizator trebuie să descrie aceeași cale, și niciuna dintre ele nu poate captura recursiv transportul peer-ului.

Revenirea și dovada că a funcționat

Păstrați configurația de rulare anterioară înainte de a schimba selectorii și știți singura comandă care o readuce. Pe ASA aceasta înseamnă o copie salvată și calea de restaurare corespunzătoare, nu memoria a ceea ce ați editat. Scrieți comanda de restaurare în tichetul de schimbare cât timp schimbarea este încă ipotetică. Apoi rulați din nou aceleași trei verificări: starea IKE, perechile SA IPsec, un flux permis pe pereche.

Dacă o pereche încă eșuează după restaurare, schimbarea nu a fost cauza, și tocmai v-ați cruțat de o a doua întrerupere.