VM de GCP con varias NIC: por qué las respuestas salen por la interfaz equivocada

Adjuntar una segunda interfaz a una VM de Compute Engine le da otro enlace de red, no una ruta de retorno simétrica. El invitado sigue eligiendo una interfaz y una dirección de origen a partir de sus propias rutas y reglas. Google Cloud aplica después el enrutamiento de VPC y la política de firewall alrededor de la interfaz por la que salió el paquete. Cuando esas dos decisiones no coinciden, las solicitudes llegan por una NIC y las respuestas salen por la otra, y la sucursal ve una conversación medio abierta.

Recorra la ruta en cinco pasos y la discrepancia aparecerá antes de que escriba una regla de política.

Paso 1: asigne las NIC de la nube a los dispositivos del invitado

La nube nombra las interfaces nic0, nic1 y así sucesivamente, y el invitado ve nombres de dispositivo que no tienen por qué coincidir. Resuelva la correspondencia a partir de los metadatos de la instancia o de la dirección propia de la interfaz antes que nada. La ruta predeterminada habitual que proporciona DHCP se asocia con nic0, y por eso el camino hacia internet gana tantas veces por accidente. Escribir política contra un nombre de dispositivo supuesto es cómo una regla correcta acaba en la interfaz equivocada.

Anote las direcciones, los nombres de dispositivo y la VPC a la que pertenece cada uno. Ese mapa de tres columnas es la entrada de cada paso posterior.

Paso 2: nombre las dos decisiones de enrutamiento

La primera decisión pertenece al invitado: qué interfaz y qué dirección de origen para este paquete. La segunda pertenece a la nube: qué permiten las rutas de la VPC y la política de firewall alrededor de esa interfaz.

Una ruta visible en la VPC orientada a la VPN no se convierte en una ruta del invitado que elija esa NIC. La ruta de la nube describe lo que la red puede entregar, mientras que la ruta del invitado decide qué hace el paquete.

Paso 3: elija una política de ruta de retorno

Para un conjunto pequeño y estable de prefijos de sucursal, las rutas de destino explícitas en el invitado son la expresión más simple: las respuestas a esos prefijos salen por la interfaz orientada a la VPN. Cuando varios servicios usan a propósito direcciones de origen locales diferentes, las reglas basadas en el origen que eligen una tabla por interfaz mantienen cada respuesta en el contexto correcto. La documentación sobre varias interfaces describe el nombrado de las NIC y el comportamiento de la ruta predeterminada en que se basan estos diseños.

Cada tabla necesita rutas conectadas válidas y saltos siguientes, además de los destinos que se le pedirán. Una regla que apunta a una tabla incompleta no es un diseño de ruta de retorno. Use la puerta de enlace documentada para esa NIC en lugar de inventar una puerta de enlace Ethernet a partir del aspecto de la subred.

Paso 4: revise los filtros propios del invitado

Compruebe dónde escucha el servidor y qué origen local lleva la respuesta. Un receptor comodín no anula la política de enrutamiento, así que enlazarse a todas las direcciones no cambia nada sobre la interfaz por la que sale la respuesta.

En Linux, revise la validación de ruta inversa frente al diseño previsto. Desactivarla globalmente como primer movimiento cambia un error de enrutamiento por una exposición a suplantación, y oculta la asimetría que intentaba encontrar.

Paso 5: pruebe un flujo por ruta

Verifique por separado una solicitud de sucursal permitida y una solicitud de internet no relacionada, cada una con su origen y destino reales. Capture en ambas interfaces cuando pueda, porque la evidencia útil es qué interfaz llevó la respuesta. Después confirme que la política del lado de la nube respetó la ruta que diseñó. Una solicitud correcta demuestra un flujo, no un diseño simétrico.

Mantenga las dos pruebas separadas en sus notas, ya que ejercitan rutas distintas y reglas de firewall distintas.

Lo que no le da una segunda NIC

Una segunda interfaz añade un enlace de red y otra dirección. No añade enrutamiento simétrico automático ni evita la política de firewall. Tratarla como una solución de enrutamiento es la razón por la que los diseños con varias NIC acumulan reglas que luego nadie puede explicar.

Si la VM debe reenviar el tráfico de otras máquinas, planifique ese papel de router de forma explícita, incluido el ajuste de la nube que permite el reenvío y los filtros del invitado que lo acompañan.