eth0:0 es una etiqueta, no un dispositivo: corrige la coincidencia SNAT

Una regla NAT que debía dar a un grupo de clientes VPN su propia dirección pública se queda en cero paquetes, mientras el mismo grupo sigue saliendo con el origen equivocado. La regla normalmente no se equivoca con la dirección; se equivoca con la interfaz. -o eth0:0 apunta a un dispositivo que no existe, porque eth0:0 es una etiqueta asociada a una dirección en eth0. Mirar los contadores es la forma más rápida de confirmarlo, y el arreglo es más pequeño de lo que sugiere la investigación.

Comprueba cómo llama el kernel al dispositivo

Lee las dos vistas por separado antes de cambiar nada:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

El listado de enlaces muestra interfaces. El listado de direcciones puede mostrar una segunda dirección IPv4 que lleva la etiqueta eth0:0, y el dispositivo de esa dirección sigue siendo eth0. El manual de direcciones de iproute2 trata la etiqueta como un nombre de la dirección, no como un segundo enlace, y esa es la distinción en la que gira todo el problema.

La historia explica la confusión. La antigua ifconfig eth0:0 sintaxis realmente parecía una interfaz nueva, y los scripts de esa época todavía se refieren a una. En un sistema actual, el alias es una etiqueta sobre una dirección, y nada en la ruta de enrutamiento o de netfilter lo trata como un punto de salida aparte.

Comprueba con qué coincidió realmente la regla

Lee los contadores junto con la lista de reglas en lugar de tirar de memoria:

iptables -t nat -L POSTROUTING -v -n --line-numbers

Una regla cuyo contador de paquetes se queda a cero mientras fluye tráfico coincidente no se está evaluando, y una condición de interfaz de salida que nombra eth0:0 es una causa habitual. El dispositivo de salida que eligió la ruta es eth0, así que una condición que busca otro nombre nunca se cumple, sea cual sea la dirección de origen que eligió el kernel.

Cambia la condición al dispositivo real y deja la etiqueta fuera. Si necesitas distinguir dos grupos de clientes que comparten ese dispositivo, distínguelos por prefijo de origen, no por un nombre de interfaz que no puede existir. Dos reglas con coincidencias -s que no se solapan son legibles y comprobables; una regla con un dispositivo ficticio no es ni lo uno ni lo otro. Pon a cada regla un comentario que nombre el grupo, porque dentro de seis meses el prefijo por sí solo no le dirá a nadie por qué está ahí.

Comprueba la ruta que eligió el dispositivo

El NAT de postrouting se ejecuta después de que la ruta ya haya elegido una interfaz de salida, así que la interfaz de la regla debe ser la que eligió la ruta. Pregunta directamente al kernel con ip route get para una dirección de cliente representativa y lee tanto el dispositivo como el origen que informa.

Si la respuesta nombra eth0, la parte de interfaz de la regla está resuelta. Si nombra un dispositivo de túnel, el paquete nunca llega a la regla que estás editando, y la búsqueda pasa a la tabla de enrutamiento y a sus prioridades. Una regla que nunca coincide porque el paquete salió por otro lado se ve igual en la salida de contadores que una regla con un dispositivo mal escrito. Confirma cuál de los dos casos tienes antes de editar nada, porque el segundo necesita un cambio de enrutamiento y no un cambio de texto.

Elige el origen traducido a propósito

Una vez que el dispositivo es correcto, la dirección de origen es una decisión aparte. Esto es solo un grupo IPv4 ilustrativo y una dirección de ejemplo:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Escribir una dirección en --to-source no hace que nadie la enrute de vuelta hacia ti. El proveedor de subida o el titular de la dirección tiene que entregar las respuestas de esa dirección a este host, y la dirección tiene que ser una que estés autorizado a usar. Si no lo es, la regla coincidirá y traducirá y las respuestas seguirán yendo a otro sitio.

Cambiar la dirección de origen no es lo mismo que cambiar el enlace de subida. Cuando el requisito real es una ruta física distinta, la política de enrutamiento tiene que seleccionar primero esa ruta; SNAT reescribe después el origen en el dispositivo que haya elegido la política. Añadir más etiquetas a eth0 no aporta ni la ruta ni la autorización.

Verifica con una conexión que acabas de abrir

Abre una conexión de cliente nueva en lugar de reutilizar una existente. El seguimiento de conexiones conserva la traducción que registró cuando empezó el flujo, así que una sesión antigua puede seguir usando la dirección de origen anterior y hacer que una regla nueva correcta parezca rota. Observa cómo sube el contador y luego mira el origen traducido en el cable o en el extremo remoto.

Cuando varios grupos comparten una interfaz, dale a cada uno una coincidencia de origen explícita y su propia dirección de traducción, mantenlos en la configuración gestionada del cortafuegos y anota el orden en que se evalúan. Después registra lo que verificaste: el dispositivo de ip route get, el contador que se movió y el origen que vio el lado remoto. Ese registro responde al siguiente informe sin repetir la confusión de la etiqueta.