Split tunneling por proceso

Ejecutar solo las herramientas de auditoría dentro de un namespace conectado a VPN, dejando el resto del sistema con su conexión normal. La parte de infraestructura está en Split tunneling - implementacion avanzada; aquí va el uso diario: lanzar procesos dentro, automatizar y comprobar que no hay fugas.

Por qué por proceso

• Aislamiento: lo que corre dentro no ve la red domestica ni sus servicios.
• OpSec: la sesión de auditoría sale con otra IP; la gestion del equipo mantiene la suya.
• Fugas controladas: el DNS del namespace es propio, no el del ISP.
• Sin coste de virtualización: no hay hipervisor ni contenedores de por medio.

Prerrequisito: IP fija en el host

En una Raspberry o en un equipo de laboratorio conviene fijar la IP por NetworkManager antes de construir nada. Si el host cambia de IP, el NAT y las rutas del namespace quedan inconsistentes.

nmcli connection show
sudo nmcli con mod "Wired connection 1" ipv4.addresses 10.10.10.50/24
sudo nmcli con mod "Wired connection 1" ipv4.gateway 10.10.10.1
sudo nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1,9.9.9.9"
sudo nmcli con mod "Wired connection 1" ipv4.method manual
sudo nmcli con up "Wired connection 1"

Lanzar una herramienta dentro

# Una orden suelta
sudo ip netns exec hacker_lab nmap -sT -Pn -sV objetivo.example
 
# Shell interactiva en el namespace
sudo ip netns exec hacker_lab /bin/bash
 
# Con prompt distinto para no confundir entornos
sudo ip netns exec hacker_lab /bin/bash --rcfile ~/.hacker_rc

~/.hacker_rc es un rc mínimo que carga los colores del sistema y deja el prompt en rojo mientras el entorno está activo:

cat << 'EOF' > ~/.hacker_rc
if [ -f /etc/bash.bashrc ]; then source /etc/bash.bashrc; fi
export PS1="(HACKER_LAB) \u@\h:\w\$ "
EOF

Alias en el shell del host:

echo "alias lab='sudo ip netns exec hacker_lab /bin/bash --rcfile ~/.hacker_rc'" >> ~/.zshrc
source ~/.zshrc

Reparto de identidades

Tarea	Donde se ejecuta	IP de salida
SSH al equipo, updates, descargas de herramientas	Host	ISP
Navegación personal, correo, paneles propios	Host	ISP
Escaneos, enumeración web, fuerza bruta autorizada	Namespace	VPN
Clientes con sesión (browser con perfil de investigación)	Namespace	VPN

Regla práctica: si una herramienta necesita credenciales reales, no entra en el namespace.

Comprobar que no hay fugas

# IP de salida en cada contexto
curl -s https://api.ipify.org
sudo ip netns exec hacker_lab curl -s https://api.ipify.org
 
# DNS: debe resolver con el del namespace
sudo ip netns exec hacker_lab cat /etc/resolv.conf
sudo ip netns exec hacker_lab dig +short example.com
 
# Estado del tunel antes de empezar
sudo ip netns exec hacker_lab wg show
 
# Procesos vivos dentro del namespace
sudo ip netns pids hacker_lab

Si las dos IP salen iguales, el túnel no está arriba y cualquier prueba esta quedando registrada con la IP real.

Limpieza al terminar

sudo ip netns exec hacker_lab wg-quick down ./lab.conf
sudo ip netns pids hacker_lab | xargs -r sudo kill
sudo ip netns del hacker_lab

Limitaciones

• Tor y VPN solo cubren TCP de forma fiable: nmap -sS, UDP y algunos protocolos no funcionan por proxy.
• Las aplicaciones con su propia pila de red (WebRTC, algunos agentes Java) pueden escapar del namespace.
• Dentro del namespace no hay acceso a servicios del host por localhost; hay que usar la IP del veth (10.10.10.1).
• La latencia de la VPN condiciona los escaneos: acotar puertos y usar -T3 como máximo.