VM de GCP con varias NIC: por que as respostas saen pola interface incorrecta

Engadir unha segunda interface a unha VM de Compute Engine dálle outro enlace de rede, non unha ruta de retorno simétrica. O convidado segue escollendo unha interface e unha dirección de orixe a partir das súas propias rutas e regras. Google Cloud aplica despois o encamiñamento de VPC e a política de firewall arredor da interface pola que saíu o paquete. Cando esas dúas decisións non coinciden, as solicitudes chegan por unha NIC e as respostas saen pola outra, e a sucursal ve unha conversa medio aberta.

Percorra a ruta en cinco pasos e a discrepancia aparecerá antes de que escriba unha regra de política.

Paso 1: asigne as NIC da nube aos dispositivos do convidado

A nube nomea as interfaces nic0, nic1 e así sucesivamente, e o convidado ve nomes de dispositivo que non teñen por que coincidir. Resolva a correspondencia a partir dos metadatos da instancia ou da dirección propia da interface antes que nada. A ruta predeterminada habitual que fornece DHCP está asociada con nic0, e por iso o camiño cara a internet gaña tantas veces por accidente. Escribir política contra un nome de dispositivo suposto é como unha regra correcta acaba na interface incorrecta.

Anote as direccións, os nomes de dispositivo e a VPC á que pertence cada un. Ese mapa de tres columnas é a entrada de cada paso posterior.

Paso 2: nomee as dúas decisións de encamiñamento

A primeira decisión pertence ao convidado: que interface e que dirección de orixe para este paquete. A segunda pertence á nube: que permiten as rutas da VPC e a política de firewall arredor desa interface.

Unha ruta visible na VPC orientada á VPN non se converte nunha ruta do convidado que escolla esa NIC. A ruta da nube describe o que a rede pode entregar, mentres que a ruta do convidado decide o que fai o paquete.

Paso 3: escolla unha política de ruta de retorno

Para un conxunto pequeno e estable de prefixos de sucursal, as rutas de destino explícitas no convidado son a expresión máis simple: as respostas a eses prefixos saen pola interface orientada á VPN. Cando varios servizos usan a propósito direccións de orixe locais diferentes, as regras baseadas na orixe que escollen unha táboa por interface manteñen cada resposta no contexto correcto. A documentación sobre varias interfaces describe o nomeado das NIC e o comportamento da ruta predeterminada no que se basean estes deseños.

Cada táboa necesita rutas conectadas válidas e saltos seguintes, ademais dos destinos que se lle pedirán. Unha regra que apunta a unha táboa incompleta non é un deseño de ruta de retorno. Use a pasarela documentada para esa NIC en lugar de inventar unha pasarela Ethernet a partir do aspecto da subrede.

Paso 4: revise os filtros propios do convidado

Comprobe onde escoita o servidor e que orixe local leva a resposta. Un receptor comodín non anula a política de encamiñamento, así que ligarse a todas as direccións non cambia nada sobre a interface pola que sae a resposta.

En Linux, revise a validación de ruta inversa fronte ao deseño previsto. Desactivala globalmente como primeiro movemento cambia un erro de encamiñamento por unha exposición a suplantación, e oculta a asimetría que intentaba atopar.

Paso 5: probe un fluxo por ruta

Verifique por separado unha solicitude de sucursal permitida e unha solicitude de internet non relacionada, cada unha coa súa orixe e destino reais. Capture en ambas interfaces cando poida, porque a evidencia útil é que interface levou a resposta. Despois confirme que a política do lado da nube respectou a ruta que deseñou. Unha solicitude correcta demostra un fluxo, non un deseño simétrico.

Manteña as dúas probas separadas nas súas notas, xa que exercitan rutas distintas e regras de firewall distintas.

O que non lle dá unha segunda NIC

Unha segunda interface engade un enlace de rede e outra dirección. Non engade encamiñamento simétrico automático nin evita a política de firewall. Tratala como unha solución de encamiñamento é a razón pola que os deseños con varias NIC acumulan regras que despois ninguén pode explicar.

Se a VM debe reenviar o tráfico doutras máquinas, planifique ese papel de router de forma explícita, incluído o axuste da nube que permite o reenvío e os filtros do convidado que o acompañan.