Dous VPN nunha soa máquina Linux: proba cada un sen mesturar resultados

Dous ícones verdes de conexión parecen unha comparación e normalmente son unha casualidade. Se a petición de proba puido usar calquera dos dous túneles, o resultado describe como moito un deles e como mínimo ningún. Dalle a cada observación un contexto de rede, un destino previsto e unha expectativa escrita antes de que se execute a proba. Nunha máquina Linux autoxestionada, os espazos de nomes de rede con nome son a forma máis barata de mercar esa separación.

Dúas luces verdes non son unha comparación

Un espazo de nomes separa táboas de enrutamento, interfaces e o estado da pila de rede, así que unha petición iniciada dentro dun non pode tomar en silencio o túnel doutro. O que non separa é unha CPU, unha ligazón física de subida ou o daemon resolutor que se executa no anfitrión. É xusto nesa última fenda onde fallan a maioría destas probas sen que ninguén o note. Unha consulta que abandona o espazo de nomes e pregunta ao resolutor do anfitrión devolve unha resposta sen relación algunha co túnel en proba.

Este procedemento supón dous espazos de nomes de proba xa preparados e aprobados, con conectividade exterior funcional e clientes compatibles. Non crea nada, non inscribe nada e non substitúe ningunha configuración. As máquinas virtuais separadas seguen sendo a opción honesta cando un cliente necesita unha sesión de escritorio completa ou se nega a executarse fóra dunha.

Fixa a expectativa antes da primeira execución

Decide por contexto como se ve o éxito: o resolutor, o nome do servizo, o enderezo esperado e o comportamento esixido cando cae o túnel. Garda eses valores planificados na súa propia columna, porque un rexistro que mestura plan e observación é ficción con marca de tempo. A lista de comprobación de abaixo é a forma que necesita o rexistro, e cada fila debe poder encherse antes da primeira conexión.

O cableado do resolutor necesita a súa propia liña nese rexistro, porque é o campo que máis probablemente mente. Os ficheiros vinculados ao espazo de nomes, como /etc/netns/vpn-a/resolv.conf aparecen nas súas rutas habituais cando un comando se executa dentro do espazo de nomes, tal como a referencia de iproute2 sobre espazos de nomes describe, pero a configuración de conmutación do servizo de nomes e calquera resolutor local que esta inicie aínda poden arrastrar unha consulta de volta ao anfitrión.

Un túnel á vez, o outro desconectado

Conecta A a través do seu propietario existente mentres B permanece caído, e despois inspecciona a política, as rutas e a ruta seleccionada desde o contexto de administración. Tres dos comandos de abaixo len estado; só o último contacta cun servizo de nomes, e ningún deles envía unha 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

Unha consulta de ruta responde a unha pregunta hipotética sobre un destino, así que non pode demostrar que o servizo acepte tráfico. Garda eses dous tipos de evidencia en columnas separadas, porque unha ruta saúdable xunto a unha conexión rexeitada é un resultado real e frecuente. Despois envía unha petición autorizada e inofensiva coa aplicación real, lanzada no contexto de A como o seu usuario normal sen privilexios coa validación de certificados e a autenticación de aplicación intactas, e rexistra o resultado xunto co enderezo de orixe que observou o servizo. Desconecta A a través do seu propietario e repite toda a liña base para B, anotando calquera cambio de configuración que fagas, ou as dúas liñas base deixan de ser comparables.

Ambos arriba, despois un abaixo á vez

O estado estable é a parte fácil. Con ambos os túneles conectados, repite a consulta e a petición de aplicación de cada contexto, despois rompe un túnel e comproba o outro. Reconecta na secuencia inversa cando o propio orde de conexión é a 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

A captura resolve discusións que un resultado de aplicación non pode: mostra se a petición saíu pola interface que esperabas ou por algo completamente distinto. Para cada transición rexistra a acción do propietario, a marca de tempo, o resultado da ruta, o resultado do nome e o desenlace da aplicación. Despois comproba o requisito de peche seguro dentro do espazo de nomes afectado, porque o illamento non é un interruptor de emerxencia. Un espazo de nomes mantén dous túneles separados; non impide que calquera deles leve tráfico cando o seu perfil di que o tráfico debe deterse.

Que pode e que non pode afirmar este rexistro

Un aprobado demostra esas observacións para esta disposición, neste anfitrión, naquel momento. Non di nada sobre dous clientes que comparten unha táboa de enrutamento de escritorio, nin sobre o rendemento mentres ambos os túneles levan carga. Son preguntas separadas con probas separadas, e unha comparación é tan boa como o contexto adjunto a cada fila.

Garda os fallos no rexistro xunto aos éxitos, etiquetados con que túnel estaba activo naquel momento. Unha páxina limpa que oculta o estado no momento da medición é peor ca unha fea que o mostra. O que fai reutilizable o rexistro máis adiante é o contexto, non a puntuación.

Dous túneles nunha máquina pódense comparar con honestidade, pero só dentro de tantos contextos como realmente controlaches. Calquera cousa máis aló é un desexo cun ícone verde ao lado.