Dos VPN en una sola máquina Linux: prueba cada una sin mezclar resultados

Dos iconos verdes de conexión parecen una comparación y normalmente son una casualidad. Si la petición de prueba podía haber usado cualquiera de los dos túneles, el resultado describe como mucho uno de ellos y como mínimo ninguno. Da a cada observación un contexto de red, un destino previsto y una expectativa escrita antes de que se ejecute la prueba. En una máquina Linux autogestionada, los espacios de nombres de red con nombre son la forma más barata de comprar esa separación.

Dos luces verdes no son una comparación

Un espacio de nombres separa tablas de enrutamiento, interfaces y el estado de la pila de red, así que una petición iniciada dentro de uno no puede tomar en silencio el túnel de otro. Lo que no separa es una CPU, un enlace físico de subida o el demonio resolutor que se ejecuta en el anfitrión. Es justo en esa última brecha donde la mayoría de estas pruebas fallan sin que nadie lo note. Una consulta que abandona el espacio de nombres y pregunta al resolutor del anfitrión devuelve una respuesta sin relación alguna con el túnel en prueba.

Este procedimiento supone dos espacios de nombres de prueba ya preparados y aprobados, con conectividad exterior funcional y clientes compatibles. No crea nada, no inscribe nada y no reemplaza ninguna configuración. Las máquinas virtuales separadas siguen siendo la opción honesta cuando un cliente necesita una sesión de escritorio completa o se niega a ejecutarse fuera de una.

Fija la expectativa antes de la primera ejecución

Decide por contexto cómo se ve el éxito: el resolutor, el nombre del servicio, la dirección esperada y el comportamiento exigido cuando cae el túnel. Guarda esos valores planificados en su propia columna, porque un registro que mezcla plan y observación es ficción con marca de tiempo. La lista de comprobación de abajo es la forma que necesita el registro, y cada fila debe poder rellenarse antes de la primera conexión.

El cableado del resolutor necesita su propia línea en ese registro, porque es el campo que más probablemente miente. Los archivos vinculados al espacio de nombres, como /etc/netns/vpn-a/resolv.conf aparecen en sus rutas habituales cuando un comando se ejecuta dentro del espacio de nombres, tal como la referencia de iproute2 sobre espacios de nombres describe, pero la configuración de conmutación del servicio de nombres y cualquier resolutor local que esta inicie todavía pueden arrastrar una consulta de vuelta al anfitrión.

Un túnel a la vez, el otro desconectado

Conecta A a través de su propietario existente mientras B permanece caído, y luego inspecciona la política, las rutas y la ruta seleccionada desde el contexto de administración. Tres de los comandos de abajo leen estado; solo el último contacta con un servicio de nombres, y ninguno de ellos envía una petición de aplicación.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

Una consulta de ruta responde a una pregunta hipotética sobre un destino, así que no puede demostrar que el servicio acepte tráfico. Guarda esos dos tipos de evidencia en columnas separadas, porque una ruta sana junto a una conexión rechazada es un resultado real y frecuente. Luego envía una petición autorizada e inofensiva con la aplicación real, lanzada en el contexto de A como su usuario normal sin privilegios con la validación de certificados y la autenticación de aplicación intactas, y registra el resultado junto con la dirección de origen que observó el servicio. Desconecta A a través de su propietario y repite toda la línea base para B, anotando cualquier cambio de configuración que hagas, o las dos líneas base dejan de ser comparables.

Ambos arriba, luego uno abajo cada vez

El estado estable es la parte fácil. Con ambos túneles conectados, repite la consulta y la petición de aplicación de cada contexto, luego rompe un túnel y comprueba el otro. Reconecta en la secuencia inversa cuando el propio orden de conexión es la pregunta.

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

La captura resuelve discusiones que un resultado de aplicación no puede: muestra si la petición salió por la interfaz que esperabas o por algo completamente distinto. Para cada transición registra la acción del propietario, la marca de tiempo, el resultado de la ruta, el resultado del nombre y el desenlace de la aplicación. Después comprueba el requisito de cierre seguro dentro del espacio de nombres afectado, porque el aislamiento no es un interruptor de emergencia. Un espacio de nombres mantiene dos túneles separados; no evita que cualquiera de los dos lleve tráfico cuando su perfil dice que el tráfico debe detenerse.

Qué puede y qué no puede afirmar este registro

Un aprobado demuestra esas observaciones para esta disposición, en este anfitrión, en ese momento. No dice nada sobre dos clientes que comparten una tabla de enrutamiento de escritorio, ni sobre el rendimiento mientras ambos túneles llevan carga. Son preguntas separadas con pruebas separadas, y una comparación es tan buena como el contexto adjunto a cada fila.

Guarda los fallos en el registro junto a los éxitos, etiquetados con qué túnel estaba activo en ese momento. Una página limpia que oculta el estado en el momento de la medición es peor que una fea que lo muestra. Lo que hace reutilizable el registro más adelante es el contexto, no la puntuación.

Dos túneles en una máquina se pueden comparar con honestidad, pero solo dentro de tantos contextos como realmente controlaste. Cualquier cosa más allá es un deseo con un icono verde al lado.