Inspección de NVA en Azure: por que a resposta pasa por outro firewall

Un fluxo da sucursal a Azure pode encamiñarse correctamente nos dous sentidos e aínda así fallar, porque os dous sentidos empregan aparellos distintos. A petición sae da sucursal pola VPN, aterra en NVA A e chega á carga de traballo. A resposta sae da carga de traballo, coincide cunha ruta que apunta a NVA B e morre alí. Todas as rutas desa imaxe son válidas, e a sesión TCP segue rota.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Ese oco é todo o tema aquí: a converxencia de encamiñamento e a propiedade do estado de sesión son problemas distintos que nun diagrama parecen idénticos.

Que programa realmente Route Server

Azure Route Server establece peering cos falantes BGP admitidos, aprende as súas rutas e prográmaas nas rutas efectivas da rede virtual. É un traballo de plano de control. Non le a táboa de sesións dun firewall de provedor e non ten idea de que aparello admitiu unha conexión concreta. Dous saltos seguintes de igual custo son, para este tecido, simplemente dúas formas de acadar o mesmo prefixo, e usará calquera das dúas.

Aprender unha ruta demostra, xa que logo, accesibilidade. Non demostra nada sobre se o dispositivo do outro extremo viu antes este fluxo.

Lea os dous sentidos antes de deseñar

Comece por anotar o direccionamento que realmente ten en cada sentido, non o que pretendía. As rutas BGP máis específicas, as rutas definidas polo usuario e o comportamento da pasarela compiten todas, e o gañador decídese por destino, non por sesión. Unha ruta predeterminada na NVA non significa que todos os prefixos privados pasen por ela.

Unha comprobación útil é preguntar, para unha IP concreta de carga de traballo, a que salto seguinte resolve cada sentido. Se a resposta son dous aparellos distintos, ten un problema de asimetría tanto se xa apareceu como se non.

Onde vive o estado

Un firewall con estado admite unha conexión e mantén unha entrada de táboa con clave da quíntupla. A resposta debe chegar ao dispositivo que ten esa entrada, ou ese dispositivo debe obter o estado doutro xeito. Nada no plano de datos de Azure reenvía a entrada entre aparellos. Ou o tráfico diríxese de volta ao propietario, ou os aparellos comparten estado mediante un mecanismo do provedor, ou o deseño non funciona.

Por iso dous NVA sanas non son unha comprobación de saúde para a inspección. A saúde trata da accesibilidade; a inspección trata de que instancia ten a sesión.

Modelos de HA admitidos e que promete cada un

Microsoft's guidance on a intención de encamiñamento de Virtual WAN describe un comportamento limitado para a conectividade de dobre rol e as NVA de firewall, onde o encamiñamento directo pode eludir a aplicación simétrica normal do concentrador. Lea esas notas como restricións á topoloxía elixida, non como unha prohibición dos deseños activo-activo. Un par de provedor que sincroniza estado ou direcciona por fluxo pode admitirse. Un par de igual custo que non fai ningunha das dúas cousas non o é.

Despois defina que ocorre coas sesións existentes cando falla un nodo. A converxencia de rutas restaura a accesibilidade para os fluxos novos en segundos, mentres que o estado antigo do firewall simplemente desaparece. A reconexión do cliente pode ser o resultado documentado, e esa é unha decisión que se toma antes do incidente, non durante.

Que probar antes de confiar nel

Test with inspection enabled and a política de acceso da carga de traballo no seu sitio, porque calquera das dúas pode ocultar a asimetría. Envíe un fluxo autorizado novo nos dous sentidos e confirme que o mesmo aparello viu as dúas metades. Despois execute tráfico sostido e active a conmutación por erro aprobada, observando se as sesións establecidas sobreviven ou se reconectan.

Correlacione cada fluxo co aparello que o xestionou. Unha captura de paquetes nunha NVA non lle di case nada se a resposta nunca volveu a ela.

Por último, escriba o plan en tres liñas separadas: propiedade das rutas, direccionamento do tráfico e propiedade do estado de sesión. Os deseños rompen cando as dúas primeiras están resoltas e a terceira se dá por suposta.