Encamiñar o tráfico entre dúas sucursais a través dunha pasarela VPN de Azure
Dúas conexións de sitio a sitio nunha mesma pasarela VPN de Azure poden pasar o tráfico das sucursais, pero só cando ambos os extremos aprenden o prefixo e existe a ruta de retorno na LAN.
Dúas sucursais poden intercambiar tráfico a través dunha pasarela VPN de Azure sen ningún túnel directo entre elas. Cada sucursal abre unha conexión de sitio a sitio cara á mesma pasarela, e a pasarela transmite os prefixos aprendidos entre as dúas conexións. O que fai que isto funcione non é o segundo túnel, senón o intercambio de rutas: a sucursal A ten que aprender o prefixo da B, e a B o da A. Percorra as comprobacións seguintes en orde e detéñase na primeira que falle, porque cada paso posterior depende dela.
Requisitos previos, antes de configurar nada
Catro condicións deciden se este deseño pode funcionar sequera. A pasarela debe estar baseada en rutas e nunha SKU que admita BGP, as dúas conexións deben ter BGP activado, os espazos de enderezos das sucursais non deben solaparse, e ningún lado pode depender de NAT para ocultar o seu prefixo real.
Planifique os ASN con coidado. O valor predeterminado documentado de Azure é 65515, e cada encamiñador de sucursal necesita o seu propio ASN privado que non colida coa pasarela nin coa outra sucursal. Reutilizar un valor predeterminado sen comprobar unha configuración de pasarela existente é como unha ruta AS acaba sendo rexeitada máis adiante.
Confirme tamén que non espera o comportamento do emparellamento de VNet. A pasarela intercambia rutas entre as dúas conexións que configurou; non fai transitivos os emparellamentos arbitrarios. Se unha terceira rede ten que chegar a ambas as sucursais, necesita a súa propia conexión ou a súa propia ruta, non a suposición de que a pasarela repartirá o tráfico. Anote ese límite antes da primeira xanela de cambio, porque é a decisión de deseño á que a xente volve cando máis adiante se engade un sitio.
Configure nesta orde
Cada paso ten un resultado observable, así que non continúe ata que apareza.
- Active BGP na pasarela de rede virtual e anote o seu ASN e o seu enderezo de par.
- Cree unha pasarela de rede local por sucursal co espazo de enderezos real desa sucursal, o seu ASN e o seu enderezo de par BGP.
- Cree cada conexión de sitio a sitio e active BGP na propia conexión.
- Configure o encamiñador da sucursal para emparellarse co enderezo de pasarela que asignou Azure, non co punto de conexión IKE público da pasarela por suposición.
O cuarto paso é onde se atascan a maioría dos intentos. O enderezo de par BGP que Azure informa é o que debe usar o encamiñador da sucursal como veciño, e non sempre é o enderezo que a xente espera do diagrama do túnel.
Anuncie o prefixo da sucursal mesmo, por exemplo 10.10.0.0/16 desde A e 10.20.0.0/16 desde B. Non anuncie unha ruta predeterminada nin un agregado amplo para cubrir unha rede específica que falta; o oco volve máis adiante como un burato negro silencioso.
Verifique o intercambio de rutas nos dous extremos
O estado da conexión non é a comprobación. IPsec pode estar activo nas dúas conexións mentres ningún prefixo cruza entre elas. Lea os pares BGP da pasarela e as súas rutas aprendidas, e logo confirme que a ruta cara á outra sucursal aparece como un camiño utilizable.
| 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 prefixo presente nunha táboa BGP aínda pode perder a decisión de envío fronte a unha ruta estática ou un prefixo máis específico. Comprobe a ruta seleccionada, non só a recibida.
Siga a ruta de retorno no lado da LAN
Esta é a parte que parece correcta en Azure e falla no sitio. Un host da sucursal A envía o seu paquete ao encamiñador VPN de A só se ese encamiñador é a súa pasarela predeterminada, ou se o host ou a súa pasarela ten unha ruta para o prefixo de B. O mesmo debe ser certo na outra dirección.
Se un conmutador central separado é a pasarela predeterminada da LAN, necesita a ruta cara á outra sucursal apuntando ao encamiñador VPN. Sen ela, a solicitude chega e a resposta sae pola ruta de Internet, e o usuario ve unha conexión que se abre e logo se colga.
Non recorra a un grupo de seguridade de rede na subrede da pasarela para arranxar isto. Esa subrede ten os seus propios requisitos e un NSG alí non é un substituto admitido da política do lado da sucursal. O filtrado corresponde aos cortafuegos das sucursais e ás cargas de traballo mesmas, onde as regras poden ser revisadas polas persoas que as posúen. Mover esas regras a un NSG de subrede tamén as oculta do equipo que depurará a próxima caída.
Admita a operación e logo demóstreo cunha proba denegada
Unha ruta aprendida non é un permiso. Permita a orixe, o destino e o servizo que realmente necesita a través dos cortafuegos das sucursais e da política do punto de conexión, e deixe o resto denegado.
Probe desde unha carga de traballo normal da sucursal A ata un servizo real da sucursal B, confirme a resposta e logo intente unha operación que deba seguir prohibida. O tráfico xerado polo propio dispositivo VPN pode usar outro enderezo de orixe e saltarse a etapa de encamiñamento da LAN, así que un ping correcto desde o encamiñador demostra menos do que parece.
Remate anotando catro feitos: os prefixos intercambiados, os ASN en uso, a ruta de retorno da LAN de cada lado e a política que admite o servizo. Se falta un deles, a configuración funciona ata o primeiro cambio, e entón ninguén sabe explicar por que.