Proba o encamiñamento VPN en espazos de nomes sen tocar as rutas do host
Tres papeis simulados, tres contextos illados e un veth por ligazón. Compara un laboratorio de espazos de nomes cun laboratorio de rutas do host antes de tocar o host.
Dous laboratorios poden modelar a mesma topoloxía VPN e fallar de xeitos completamente distintos: un vive en espazos de nomes de rede, o outro nas rutas propias do host. A versión con espazos de nomes mantén cada interface, ruta e socket nun contexto que podes borrar, mentres que a versión co host arrinca máis rápido e deixa estado detrás. Ese estado residual é a razón pola que o segundo laboratorio é difícil de repetir un mes despois. Compara primeiro a limpeza, porque decide se podes executar o experimento dúas veces.
Dous xeitos de construír o mesmo laboratorio, e cando gaña cada un
Nun laboratorio de rutas do host engades unha interface de túnel e rutas á máquina na que traballas, así que o experimento comparte sorte coa túa shell, o teu xestor de paquetes e calquera outra conexión. Nun laboratorio de espazos de nomes cada papel recibe a súa propia pila de interfaces, enderezos, rutas e sockets, e borrar o espazo de nomes elimina todo iso. Ningún modelo é máis correcto, porque responden a preguntas distintas. Elixe espazos de nomes cando o tema sexa o encamiñamento e o reenvío, e un laboratorio co host cando o tema sexa como se integra un cliente de escritorio.
| Aspect | Namespace lab | Host-route lab |
|---|---|---|
| Isolation | Full stack per role | Shares the host stack |
| Cleanup | Delete named namespaces | Manual route and rule removal |
| Realism | Strong for routing | Needed for GUI clients |
Mesturar os dous é o erro habitual: un laboratorio de espazos de nomes probado contra un cliente só do host non demostra nada sobre ningunha das dúas disposicións. Decide que pregunta fas antes de crear a primeira ligazón.
Un contexto por papel, conectado a propósito
Crea un espazo de nomes por papel e move cada extremo de cada par veth ao contexto que o posúe. Os catro primeiros comandos abondan para ver a forma:
ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns clientDálle ao laboratorio rangos que non se solapen con nada do host, e anota antes de comezar que espazo de nomes posúe que enderezo. Un laboratorio que funcione necesita dous camiños separados: un exterior para que o extremo VPN chegue ao seu par, e un camiño de retorno para o recurso que se protexe. Modélaos como dúas decisións, porque un laboratorio que só constrúe a metade de saída pasa unha proba de aperta de mans e falla unha proba de aplicación.
O papel de reenvío é onde os laboratorios se volven interesantes
Un papel ten que reenviar, o que significa habilitar o reenvío dentro dese espazo de nomes e engadir a regra que o deseño necesite. O estado de reenvío é por espazo de nomes, así que a configuración do host é irrelevante para o laboratorio e a configuración do laboratorio non se filtra cara fóra, como describe a documentación sobre espazos de nomes de rede. WireGuard documenta que unha interface e o seu socket exterior poden vivir en espazos de nomes distintos, o que é un truco útil e unha excelente maneira de confundirte. Non asumas que mover unha interface move cada parte da conexión da mesma forma.
Comproba o contador de reenvío despois dun paquete de proba, porque unha regra que nunca coincidiu e unha regra que descartou ven idénticas na táboa de rutas. Só os contadores as separan.
Rexistra unha liña base, logo rompe unha ruta
Comeza rexistrando o que existe, co contexto escrito xunto a cada liña. Le os espazos de nomes, logo a ruta que tomaría un destino de proba dentro dun deles, logo os contadores na ligazón que a transporta:
ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-gO terceiro comando é o que a xente omite, e aí é onde vive a evidencia: os contadores de descartes e erros dícenche se un paquete chegou sequera ao papel de reenvío. Captura as mesmas tres vistas despois dun cambio, e deixa que o diff sexa a evidencia en lugar da túa memoria. Logo rompe exactamente unha cousa, sexa borrando unha ruta ou engadindo unha regra de denegación no camiño de reenvío, e confirma o síntoma que predixeras: unha aperta de mans completada sen resposta, ou un fallo de resolución en lugar dun tempo de espera esgotado. Un laboratorio que só demostra éxito ensina moi pouco.
A limpeza é o que fai repetible a seguinte execución
Mantén a limpeza limitada aos recursos que nomeaches, porque un reinicio xeral do cortafogos ou a eliminación dunha ruta do host non é reproducibilidade, é un segundo incidente. Garda a topoloxía, os comandos exactos e as observacións que esperabas, para que a seguinte execución reproduza o mesmo fallo en lugar de adiviñar que contexto tiña o estado anterior. Sen ese rexistro, o laboratorio é unha historia e non un procedemento.
Usa credenciais xeradas localmente para o laboratorio e mantén as contas de produción fóra dos exemplos compartidos. Logo borra cada espazo de nomes e confirma que a vista do host non cambiou, que é toda a razón para elixir este modelo. Un laboratorio que non podes eliminar limpamente é un cambio no host con pasos extra.