Dues VPN en una sola màquina Linux: prova cada una sense barrejar resultats

Dues icones verdes de connexió semblen una comparació i normalment són una casualitat. Si la petició de prova podia haver fet servir qualsevol dels dos túnels, el resultat descriu un d’ells en el millor cas i cap en el pitjor. Dona a cada observació un context de xarxa, una destinació prevista i una expectativa escrita abans que s’executi la prova. En una màquina Linux autogestionada, els espais de noms de xarxa amb nom són la manera més barata de comprar aquesta separació.

Dues llums verdes no són una comparació

Un espai de noms separa les taules d’encaminament, les interfícies i l’estat de la pila de xarxa, de manera que una petició iniciada dins d’un no pot manllevar en silenci el túnel d’un altre. El que no separa és una CPU, un enllaç físic ascendent o el dimoni resolutor que s’executa a l’amfitrió. És precisament en aquest darrer buit on la majoria d’aquestes proves fallen sense que ningú se n’adoni. Una consulta que surt de l’espai de noms i pregunta al resolutor de l’amfitrió retorna una resposta sense cap relació amb el túnel que s’està provant.

Aquest procediment assumeix dos espais de noms de prova ja preparats i aprovats, amb connectivitat exterior funcional i clients suportats. No crea res, no inscriu res i no substitueix cap configuració. Les màquines virtuals separades continuen sent l’opció honesta quan un client necessita una sessió d’escriptori completa o es nega a executar-se fora d’una.

Fixa l’expectativa abans de la primera execució

Decideix per a cada context com es veu l’èxit: el resolutor, el nom del servei, l’adreça esperada i el comportament exigit quan el túnel cau. Guarda aquests valors planificats a la seva pròpia columna, perquè un registre que barreja pla i observació és ficció amb una marca de temps. La llista de comprovació de sota és la forma que necessita el registre, i cada fila ha de poder omplir-se abans de la primera connexió.

El cablejat del resolutor necessita la seva pròpia línia en aquest registre, perquè és el camp que més probablement menteix. Els fitxers vinculats a l’espai de noms, com ara /etc/netns/vpn-a/resolv.conf apareixen als seus camins habituals quan una ordre s’executa dins de l’espai de noms, tal com la referència d’iproute2 sobre espais de noms descriu, però la configuració de commutació del servei de noms i qualsevol resolutor local que aquest iniciï encara poden estirar una consulta de tornada a l’amfitrió.

Un túnel alhora, l’altre desconnectat

Connecta A a través del seu propietari existent mentre B roman aturat, i després inspecciona la política, les rutes i el camí seleccionat des del context d’administració. Tres de les ordres de sota llegeixen estat; només l’última contacta amb un servei de noms, i cap d’elles envia una petició d’aplicació.

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 respon una pregunta hipotètica sobre una destinació, així que no pot demostrar que el servei accepti trànsit. Guarda aquests dos tipus de proves en columnes separades, perquè una ruta sana al costat d’una connexió rebutjada és un resultat real i freqüent. Després envia una petició autoritzada i inofensiva amb l’aplicació real, llançada en el context d’A com el seu usuari normal sense privilegis amb la validació de certificats i l’autenticació d’aplicació intactes, i registra el resultat juntament amb l’adreça d’origen que el servei va observar. Desconnecta A a través del seu propietari i repeteix tota la línia base per a B, anotant qualsevol canvi de configuració que facis, o les dues línies base deixaran de ser comparables.

Tots dos amunt, després un avall alhora

L’estat estacionari és la part fàcil. Amb tots dos túnels connectats, repeteix la consulta i la petició d’aplicació de cada context, i després trenca un túnel i comprova l’altre. Torna a connectar en la seqüència inversa quan l’ordre de connexió mateix és 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 resol discussions que un resultat d’aplicació no pot: mostra si la petició va sortir per la interfície que esperaves o per una altra cosa completament diferent. Per a cada transició registra l’acció del propietari, la marca de temps, el resultat de la ruta, el resultat del nom i la conclusió de l’aplicació. Després comprova el requisit de tancament segur dins de l’espai de noms afectat, perquè l’aïllament no és un interruptor d’emergència. Un espai de noms manté dos túnels separats; no impedeix que cap dels dos porti trànsit quan el seu perfil diu que el trànsit ha d’aturar-se.

Què pot i què no pot afirmar aquest registre

Un aprovat demostra aquestes observacions per a aquesta disposició, en aquest amfitrió, en aquell moment. No diu res sobre dos clients que comparteixen una taula d’encaminament d’escriptori, ni sobre el rendiment mentre tots dos túnels porten càrrega. Són preguntes separades amb proves separades, i una comparació és tan bona com el context adjunt a cada fila.

Guarda els fracassos al registre al costat dels èxits, etiquetats amb quin túnel estava actiu en aquell moment. Una pàgina neta que amaga l’estat en el moment del mesurament és pitjor que una de lletja que el mostra. El que fa reutilitzable el registre més endavant és el context, no la puntuació.

Dos túnels en una màquina es poden comparar honestament, però només dins de tants contextos com realment has controlat. Qualsevol cosa més enllà és un desig amb una icona verda al costat.