Encaminar el trànsit entre dues sucursals a través d’una passarel·la VPN d’Azure
Dues connexions de lloc a lloc en una mateixa passarel·la VPN d’Azure poden passar el trànsit de les sucursals, però només quan tots dos extrems aprenen el prefix i existeix el camí de tornada a la LAN.
Dues sucursals poden intercanviar trànsit a través d’una passarel·la VPN d’Azure sense cap túnel directe entre elles. Cada sucursal obre una connexió de lloc a lloc cap a la mateixa passarel·la, i la passarel·la transmet els prefixos apresos entre les dues connexions. El que fa que això funcioni no és el segon túnel, sinó l’intercanvi de rutes: la sucursal A ha d’aprendre el prefix de la B, i la B ha d’aprendre el de la A. Recorreu les comprovacions següents en ordre i atureu-vos a la primera que falli, perquè cada pas posterior en depèn.
Requisits previs, abans de configurar res
Quatre condicions decideixen si aquest disseny pot funcionar. La passarel·la ha de ser basada en rutes i en una SKU que admeti BGP, les dues connexions han de tenir BGP activat, els espais d’adreces de les sucursals no s’han de superposar, i cap dels dos costats no pot dependre de NAT per amagar el seu prefix real.
Planifiqueu els ASN amb cura. El valor predeterminat documentat d’Azure és 65515, i cada encaminador de sucursal necessita el seu propi ASN privat que no xoqui amb la passarel·la ni amb l’altra sucursal. Reutilitzar un valor predeterminat sense comprovar la configuració existent de la passarel·la és com un camí AS acaba sent rebutjat més endavant.
Confirmeu també que no espereu el comportament de l’emparellament de VNet. La passarel·la intercanvia rutes entre les dues connexions que heu configurat; no fa transitius els emparellaments arbitraris. Si una tercera xarxa ha d’arribar a totes dues sucursals, necessita la seva pròpia connexió o el seu propi camí de ruta, no el supòsit que la passarel·la repartirà el trànsit. Anoteu aquesta frontera abans de la primera finestra de canvi, perquè és la decisió de disseny a què la gent torna quan més endavant s’afegeix un lloc.
Configureu en aquest ordre
Cada pas té un resultat observable, així que no continueu fins que aparegui.
- Activeu BGP a la passarel·la de xarxa virtual i anoteu-ne l’ASN i l’adreça de parell.
- Creeu una passarel·la de xarxa local per a cada sucursal amb l’espai d’adreces real d’aquesta sucursal, el seu ASN i la seva adreça de parell BGP.
- Creeu cada connexió de lloc a lloc i activeu BGP a la mateixa connexió.
- Configureu l’encaminador de la sucursal per emparellar-se amb l’adreça de passarel·la que Azure ha assignat, no amb el punt final IKE públic de la passarel·la per suposició.
El quart pas és on s’encallen la majoria dels intents. L’adreça de parell BGP que Azure indica és la que l’encaminador de la sucursal ha d’usar com a veí, i no sempre és l’adreça que la gent espera del diagrama del túnel.
Anuncieu el prefix de la sucursal mateix, per exemple 10.10.0.0/16 des d’A i 10.20.0.0/16 des de B. No anuncieu una ruta per defecte ni un agregat ampli per cobrir una xarxa específica que falta; el buit torna més endavant com un forat negre silenciós.
Verifiqueu l’intercanvi de rutes als dos extrems
L’estat de la connexió no és la comprovació. IPsec pot estar actiu a les dues connexions mentre cap prefix no creua entre elles. Llegiu els parells BGP de la passarel·la i les seves rutes apreses, i després confirmeu que la ruta cap a l’altra sucursal apareix com un camí utilitzable.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Un prefix present en una taula BGP encara pot perdre la decisió d’enviament davant d’una ruta estàtica o d’un prefix més específic. Comproveu la ruta seleccionada, no només la rebuda.
Seguiu el camí de tornada al costat de la LAN
Aquesta és la part que sembla correcta a Azure i falla al lloc. Un equip de la sucursal A envia el seu paquet a l’encaminador VPN d’A només si aquest encaminador és la seva passarel·la predeterminada, o si l’equip o la seva passarel·la té una ruta per al prefix de B. El mateix ha de ser cert en l’altra direcció.
Si un commutador central separat és la passarel·la predeterminada de la LAN, necessita la ruta cap a l’altra sucursal apuntant a l’encaminador VPN. Sense ella, la petició arriba i la resposta surt pel camí d’Internet, i l’usuari veu una connexió que s’obre i després es penja.
No recurreu a un grup de seguretat de xarxa a la subxarxa de la passarel·la per arreglar-ho. Aquesta subxarxa té els seus propis requisits i un NSG allà no és un substitut admès de la política del costat de la sucursal. El filtratge pertoca als tallafocs de les sucursals i a les càrregues de treball mateixes, on les regles poden ser revisades per les persones que les posseeixen. Moure aquestes regles a un NSG de subxarxa també les amaga de l’equip que depurarà la propera caiguda.
Admeteu l’operació i després demostreu-la amb una prova denegada
Una ruta apresa no és un permís. Permeteu l’origen, la destinació i el servei que realment necessiteu a través dels tallafocs de les sucursals i de la política del punt final, i deixeu la resta denegada.
Proveu des d’una càrrega de treball corrent de la sucursal A cap a un servei real de la sucursal B, confirmeu la resposta i després intenteu una operació que ha de romandre prohibida. El trànsit generat pel propi aparell VPN pot usar una altra adreça d’origen i saltar-se l’etapa d’encaminament de la LAN, així que un ping correcte des de l’encaminador demostra menys del que sembla.
Acabeu anotant quatre fets: els prefixos intercanviats, els ASN en ús, el camí de tornada a la LAN de cada costat i la política que admet el servei. Si falta un d’ells, la configuració funciona fins al primer canvi, i llavors ningú no sap explicar per què.