Split Tunneling basado en Procesos/Namespaces
Sammi De Blas “PoisonXPloIT 2>/dev/null”
Raspberry Pi 5 (ARM64) - Kali Linux
1. Contexto y Justificación
El objetivo de esta configuración es profesionalizar el entorno de laboratorio de ciberseguridad sobre una Raspberry Pi 5. En lugar de enrutar todo el tráfico del dispositivo a través de una VPN (lo cual afectaría a servicios como SSH, actualizaciones o navegación personal), implementamos **“Process-Based Split Tunneling”** mediante **Linux Network Namespaces**.
¿Por qué esta arquitectura en la Pi 5?
1. Aislamiento (Sandboxing): Creamos un contenedor lógico (`hacker_lab`) sin la sobrecarga de Docker. Las herramientas ofensivas ejecutadas aquí no tienen acceso directo a la red local doméstica.
2. OpSec (Managed Attribution):
Identidad Host: La Pi mantiene su IP pública real (ISP España) para gestión y tareas administrativas.
Identidad Lab: El namespace utiliza una VPN (Francia) para anonimizar escaneos y ataques.
3. Prevención de Fugas: Se implementa un *Hardening* de DNS específico para evitar que las peticiones de resolución de nombres escapen por el ISP local (DNS Leak Protection).
2. Diagrama de Arquitectura
El siguiente esquema detalla el flujo de tráfico dividido entre la interfaz física (`eth0`) y la interfaz virtual del túnel (`tun1`).
Ver Esquema Gráfico: [Mermaid]{.underline}
3. Implementación Técnica
Fase 0: Prerrequisitos (IP Estática)
*Nota: Configuración necesaria para garantizar acceso SSH estable al dispositivo.*
En Kali Linux (basado en Debian), usamos **NetworkManager** para fijar la IP. Asumiendo que tu interfaz es `eth0` y tu red es `192.168.1.x`.
1. Identificar la conexión activa
nmcli connection show
2. Configurar IP Fija (Ejemplo: 192.168.1.50)
Reemplaza ‘Wired connection 1’ con el nombre real de tu conexión
sudo nmcli con mod “Wired connection 1” ipv4.addresses 192.168.1.50/24
sudo nmcli con mod “Wired connection 1” ipv4.gateway 192.168.1.1
sudo nmcli con mod “Wired connection 1” ipv4.dns “1.1.1.1,8.8.8.8”
sudo nmcli con mod “Wired connection 1” ipv4.method manual
3. Aplicar cambios
sudo nmcli con up “Wired connection 1”
Fase 1: Creación del Namespace
Creamos el espacio aislado y las interfaces virtuales (veth) para conectarlo con el sistema principal.
Crear el namespace llamado ‘hacker_lab’
sudo ip netns add hacker_lab
Crear el par de cables virtuales
sudo ip link add veth_host type veth peer name veth_guest
Mover un extremo del cable dentro del namespace
sudo ip link set veth_guest netns hacker_lab
Asignar IPs a las interfaces virtuales (Red interna de enlace 10.10.10.x)
sudo ip addr add 10.10.10.1/24 dev veth_host
sudo ip netns exec hacker_lab ip addr add 10.10.10.2/24 dev veth_guest
Levantar las interfaces
sudo ip link set veth_host up
sudo ip netns exec hacker_lab ip link set veth_guest up
sudo ip netns exec hacker_lab ip link set lo up
Habilitar enrutamiento en el namespace hacia el host
sudo ip netns exec hacker_lab ip route add default via 10.10.10.1
Habilitar NAT en el host (IP Masquerade) para que el namespace tenga internet
sudo iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
sudo sysctl -w net.ipv4.ip_forward=1
Fase 2: Despliegue de VPN (OpenVPN)
Ejecutamos la conexión VPN exclusivamente dentro del proceso del namespace.
Entrar al directorio de configuración VPN
cd /home/sammi/vpnbook-openvpn-fr231
Ejecutar OpenVPN dentro del namespace
Flags importantes:
—config: archivo .ovpn
& : Ejecutar en segundo plano (opcional si se usa tmux/screen)
sudo ip netns exec hacker_lab openvpn —config vpnbook-fr231-tcp443.ovpn
Fase 3: Hardening de DNS (Prevención de Fugas)
Por defecto, el namespace hereda el /etc/resolv.conf del host, lo que provocaría una fuga de DNS (el ISP vería las peticiones). Usamos bind mount para forzar DNS seguros solo en el entorno aislado.
Crear directorio para configuraciones específicas de netns
sudo mkdir -p /etc/netns/hacker_lab
Crear archivo resolv.conf aislado
Usamos Cloudflare (1.1.1.1) para privacidad
echo “nameserver 1.1.1.1” | sudo tee /etc/netns/hacker_lab/resolv.conf
echo “nameserver 8.8.8.8” | sudo tee -a /etc/netns/hacker_lab/resolv.conf
Fase 4: Automatización y Persistencia (Alias)
Para facilitar el acceso operativo (“Entrar en la Matrix”), creamos un alias en Zsh que carga una configuración de Bash con prompt distintivo.
1. Archivo de entorno (~/.hacker_rc):
cat << ‘EOF’ > ~/.hacker_rc
# Cargar colores estándar
if [ -f /etc/bash.bashrc ]; then
source /etc/bash.bashrc
fi
# Prompt ROJO para alerta visual de entorno activo
export PS1=”\[\e[31m\](HACKER_LAB) \[\e[0m\]\u@\h:\w# ”
EOF
2. Configuración del Alias (~/.zshrc):
# Añadir al final de ~/.zshrc
alias lab=‘sudo ip netns exec hacker_lab /bin/bash —rcfile ~/.hacker_rc’
3. Recargar: source ~/.zshrc
4. Verificación y Pruebas
Para confirmar que el sistema funciona correctamente, ejecutamos los siguientes comandos desde dentro del entorno (lab):
Verificar IP Pública (Debe ser francesa/VPN):
curl [ifconfig.me]{.underline}
Resultado esperado: 5.196.64.231 (o similar de la VPN)
Verificar DNS (Debe ser Cloudflare/Google):
cat /etc/resolv.conf
Resultado esperado: nameserver 1.1.1.1
Prueba de Escaneo (Bypass de bloqueo ICMP): Dado que la VPN bloquea Ping (ICMP), usamos Nmap en modo TCP puro.
nmap -Pn -p 80,443 [scanme.nmap.org]{.underline}
Resultado esperado: Host up, latencia alta (>100ms indicando ruta VPN)