VPN de sitio a sitio entre AWS e Azure: escriba primeiro a ruta de volta
Un túnel conectado entre nubes non demostra nada ata que cada subrede de carga encamiña cara ao prefixo remoto. Execute o plan en orde e despois probe o servizo.
O túnel subirá. Adoita facelo, porque IKE só necesita propostas coincidentes e un enderezo de par accesible. O que falla despois é o camiño de volta: a carga de AWS envía paquetes a un túnel, pero nada do lado de Azure sabe como responder a 10.10.0.0/16, ou a ruta de Azure existe nunha táboa que a subrede de carga non usa. Escriba o plan de rutas antes de tocar calquera consola e o túnel converterase na parte menos interesante do traballo.
Paso 1: conxele o plan de enderezos
Traballo con valores concretos. Unha carga de AWS está en 10.10.1.20 dentro de 10.10.0.0/16 e necesita TCP 443 cara a un servizo de Azure en 10.20.1.30 dentro de 10.20.0.0/16. Os dous rangos non deben solaparse, e a proba de aceptación é o par de servizos, non o túnel.
Anote eses catro feitos antes que calquera outra cousa, porque cada paso posterior compróbase contra eles.
Paso 2: nomee a pasarela que posúe cada extremo
AWS Site-to-Site VPN pode terminar nunha pasarela privada virtual ou nunha pasarela de tránsito, e son propietarios de encamiñamento distintos. Azure ofrece a súa VPN Gateway xestionada e, por separado, aparellos baseados en VM que os clientes executan eles mesmos. Rexistre que par ten, porque o seguinte salto difire en cada combinación.
Para unha pasarela xestionada, non copie unha ruta que apunte a un enderezo suposto de aparello privado. Para un aparello, non supoña que a propagación de rutas na nube configura o sistema operativo convidado, porque non o fai.
Equivocarse aquí produce un plan que parece completo e envía paquetes a un enderezo que nunca responde.
Paso 3: escriba a ruta que cada carga realmente usa
Cada fronteira de abaixo é unha consulta separada, e unha ruta nunha delas non é unha ruta para o paquete. Encha a táboa cos seus propios valores antes de que o túnel entre en servizo.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
En AWS, a táboa de rutas da subrede de carga é súa para actualizar incluso despois de que BGP ou un túnel estean sans; a visión xeral do encamiñamento considérao parte da conexión. En Azure, unha táboa de rutas definidas polo usuario asóciase a unha subrede en lugar de ligarse á rede virtual, así que comprobe a ruta efectiva na NIC da carga e non na folla de VNet.
Unha pasarela de Azure xestionada pode aprender o prefixo remoto mediante a propagación da pasarela, e unha UDR pode anular esa decisión. Engada a UDR cando teña un motivo, non por reflexo. Se a engade, apúntea ao seguinte salto que a pasarela publica para o camiño VPN en lugar de inventar un enderezo de aparello. Despois volva ler as rutas efectivas na NIC, porque a NIC é onde se toma realmente a decisión.
Paso 4: reconcilie o alcance
Para BGP, compare o que anuncia cada lado co que o outro lado aprendeu realmente, prefixo por prefixo. Para o encamiñamento estático, compare os rangos remotos configurados coas rutas de carga que escribiu no paso 3.
Unha relación IKE que coincide en criptografía non é proba de que algún lado aprendese 10.10.0.0/16 ou 10.20.0.0/16. Dous túneles poden estar activos mentres un lado anuncia un só /24 en lugar do /16 que planeou. Comprobe o prefixo na táboa de encamiñamento, non no estado do túnel. A discrepancia aparece despois como unha subrede que funciona e outra que nunca responde.
Paso 5: probe o servizo, desde a fonte real
Permita o fluxo previsto nos grupos de seguranza e as ACL de rede de AWS, nos NSG de Azure e en calquera filtro de aparello do camiño. Despois abra unha conexón desde 10.10.1.20 ao enderezo e porto aprobados do servizo e confirme que a resposta volve á mesma fonte.
Tanto os grupos de seguranza da nube como os NSG son stateful, así que un paquete de volta denegado é un síntoma de encamiñamento, non unha regra que esqueceu escribir ao revés.
Un ping desde calquera pasarela non resolve nada. ICMP ao enderezo dunha pasarela exercita o camiño do plano de control, non o servizo TCP reenviado que a carga necesita.
Reversión e rexistros
Rexistre os propietarios de rutas xunto aos identificadores do túnel e conserve as táboas de rutas anteriores ao cambio. Se o cambio ten que saír, elimine as rutas de carga antes de desmontar o túnel, para que ningunha subrede quede apuntando a un seguinte salto que xa non existe.
Así, un traslado posterior de subrede ou unha conexión spoke ten un lugar definido onde actualizar, en lugar dun túnel que funciona e carga a culpa dunha ruta que nunca poseeu.