Cisco ASA na Azure VPN: presiese pare vir verkeerskeurders
Skryf die ASA-na-Azure-VPN as 'n kontrak: verbindingsmodel, presiese voorvoegselpare, keurderverifikasie en dan terugrol. 'n Runbook wat by die vrystelling pas.
Die tonnel kom op, IKE lyk gesond, en niks beweeg daardeur nie. Dit is die gewone vorm van 'n ASA-na-Azure-keurderprobleem, en dis hoekom ek die kontrak skryf voordat ek enige van die twee konsoles aanraak. Die kontrak bestaan uit vier dinge: die objekte wat elke eweknie identifiseer, die verbindingsmodel, die presiese voorvoegselpare en die verifikasie wat elke paar bewys. Kry dié verkeerd en elke latere opdrag ontfout 'n konfigurasie wat jy nooit moes bou nie. Hierdie runbook is die volgorde wat ek gebruik, saam met die opdragte wat wys watter objek eintlik verkeerd is.
Skryf die vier objekte neer voordat jy konfigureer
Begin met die ASA-vrystelling en -platform, die publieke eindpunt, die Azure VPN-gateway se tipe en SKU, en die plaaslike netwerkgateway wat jou kant verteenwoordig. Daardie vier name is die woordeskat vir alles wat volg, en elkeen het 'n ander eienaar wanneer iets breek.
As twee daarvan nog raaiskote is, stop. 'n Verkeerde voorvoegsellys by die plaaslike netwerkgateway is nie 'n instellingsprobleem nie.
Kies een verbindingsmodel en hou op om sjablone te meng
'n Kripto-kaart-ontwerp en 'n tonnelkoppelvlak-ontwerp is verskillende konfigurasies, en 'n sjabloon vir die een word nie geldig vir die ander deur die eweknie-adres te wysig nie. Teken aan watter een jy bou voordat jy iets plak, want die wanverhouding duik later op as 'n keurderprobleem eerder as 'n konfigurasiefout. Microsoft se ASA-interoperabiliteitsgids dek albei patrone en sê watter Azure-gatewaymodel elkeen veronderstel. As jou notas nie die model noem nie, het jy nog nie 'n ontwerp nie.
'n Roetegebaseerde Azure-gateway met beleidsgebaseerde verkeerskeurders is 'n spesifieke gedokumenteerde opsie, nie die verstek nie. As jou ontwerp daarvan afhang, moet die ontwerp dit sê, want die verstek-roetegebaseerde keurder model werk anders aan die Azure-kant.
Weergawebeperkings hoort ook in die kontrak. 'n Ou veldverslag oor 'n perk op enkripsiedomeine is 'n datapunt oor bepaalde vrystellings, nie 'n permanente eienskap van elke ASA nie.
Lys die voorvoegselpare op, nie die samevoegings nie
Skryf die matriks. Plaaslik A en B na Azure X en Y is vier pare, en elkeen kort óf dekking óf 'n uitdruklike uitsluiting. Om A en B in een samevoeging te verdig, sluit ook in wat tussen hulle sit, en dit is hoe 'n ontwerp stil-stil 'n gat kry.
Kyk wat die eweknieë onderhandel het, nie wat jy gestoor het nie. 'n Lys van plaaslike en afgeleë netwerke op die ASA is bedoeling; die CHILD SA's is die resultaat.
Wanneer 'n paar ontbreek, is die oplossing gewoonlik 'n toegangslys-reël of 'n keurder-inskrywing, nie 'n nuwe tonnel nie.
Verifieer met opdragte wat die objek noem
Op die ASA, bevestig die IKE-sessie, dan die IPsec SA's, dan die keurderpare. Elke opdrag beantwoord 'n ander vraag, en om net die eerste te hardloop, is hoe die verkeerde gevolgtrekking ontstaan dat die tonnel op is. Lees die uitset vir die eweknie wat jy werklik gekonfigureer het, nie die een of ander SA wat eerste in die lys is nie. Die Azure-kant antwoord dieselfde drie vrae uit sy eie oogpunt.
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
Vra Azure dan vir die verbindingstoestand met az network vpn-connection show --name <connection> --query connectionStatus. Connected met nul grepe in die datapad is 'n keurderprobleem, nie 'n roeteprobleem nie.
Toets een toegelate vloei per paar, ondersoek die bronadres wat aan die ander kant gesien word, en probeer een hulpbron wat geweier behoort te word. Daardie laaste toets is die enigste een wat bewys dat die grens nog bestaan.
Hou enkripsiebestek apart van toegangstoestemming
'n Breë keurder is nie toestemming nie. As die ondersteunde uitleg wyer is as die toepassingsbeleid, hou die smal dienste in die brandmuurreëls en laat die enkripsiebestek waar dit moet wees.
Azure-werkladingroetes en plaaslike terugroetes word afsonderlik hersien. BGP-aankondigings, statiese netwerkbestek en gebruikergedefinieerde roetes moet almal dieselfde pad beskryf, en nie een van hulle mag die eweknie-transport herhalend vasvang nie.
Terugrol en die bewys dat dit gewerk het
Hou die vorige lopende konfigurasie voordat jy keurders verander, en weet watter enkele opdrag dit terugplaas. Op die ASA beteken dit 'n gestoorde afskrif en die bypassende herstelpad, nie 'n herinnering van wat jy gewysig het nie. Skryf die herstelopdrag in die veranderingsticket terwyl die verandering nog hipoteties is. Hardloop dan dieselfde drie kontroles weer: IKE-toestand, IPsec SA-pare, een toegelate vloei per paar.
As 'n paar steeds misluk ná die herstel, was die verandering nie die oorsaak nie, en jy het jouself net 'n tweede onderbreking gespaar.