// PROYECTO: Rasperry Pi5
// OS: Kali Linux
// ESTADO: Network Operational
0x00 Contexto y Justificación
En mi proceso de profesionalizar el entorno de laboratorio sobre la Raspberry Pi 5, he descartado la idea de enrutar todo el tráfico del dispositivo a través de una VPN.
Hacerlo comprometería la latencia de servicios administrativos (SSH) y las actualizaciones del sistema base.
He optado por implementar una arquitectura de "Process-Based Split Tunneling" utilizando Linux Network Namespaces.
Esta configuración me permite crear un contenedor lógico (hacker_lab) sin la sobrecarga de recursos de Docker, garantizando dos principios fundamentales:
- Sandboxing: Las herramientas ofensivas residen en un entorno estanco.
- OpSec: La identidad del Host se mantiene con mi IP ISP local (España) para gestión, mientras que el Namespace opera bajo una identidad anonimizada (VPN Francia).
0x01 Configuración Inicial
Fijación de IP Estática
Para garantizar la estabilidad del acceso SSH, he configurado una IP estática mediante NetworkManager.
Es imperativo no depender de DHCP en un dispositivo de infraestructura.
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
sudo nmcli con up "Wired connection 1"
0x02 Despliegue del Namespace
Esta es la fase crítica.
He creado un par de interfaces virtuales (veth) que actúan como un cable de red virtual conectando el kernel principal con el espacio de nombres aislado.
Posteriormente, he configurado iptables para permitir que el tráfico del namespace salga a internet mediante NAT (Masquerading).
# 1. Crear el entorno aislado
sudo ip netns add hacker_lab
2. Enlace virtual (Host ←> Guest)
sudo ip link add veth_host type veth peer name veth_guest
sudo ip link set veth_guest netns hacker_lab
3. Asignación de direccionamiento (Red interna 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
4. Levantar 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
5. Enrutamiento y NAT
sudo ip netns exec hacker_lab ip route add default via 10.10.10.1
sudo iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
sudo sysctl -w net.ipv4.ip_forward=1</→
0x03 Túnel y Hardening
Ejecución de OpenVPN
La conexión VPN se ejecuta exclusivamente dentro del contexto del namespace. Esto asegura que la tabla de enrutamiento del host permanezca intacta.
sudo ip netns exec hacker_lab openvpn --config vpnbook-fr231-tcp443.ovpn
-
Por defecto, el namespace hereda
/etc/resolv.confdel host. - Esto es un fallo de seguridad grave ya que el ISP podría ver las peticiones DNS aunque el tráfico vaya por VPN.
- He forzado la resolución DNS dentro del namespace utilizando montajes específicos en
/etc/netns/.
# Crear directorio de configuración específica
sudo mkdir -p /etc/netns/hacker_lab
Forzar DNS Cloudflare/Google solo para este entorno
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
0x04 Persistencia y Verificación
Para agilizar el flujo de trabajo, he creado un alias en Zsh que inyecta una configuración de Bash personalizada.
Esto cambia el prompt a ROJO cuando estoy dentro del namespace, sirviendo como advertencia visual de que estoy en modo ofensivo.
# Alias en ~/.zshrc
alias lab='sudo ip netns exec hacker_lab /bin/bash --rcfile ~/.hacker_rc'
Verificación de identidad (Debe retornar IP de VPN)
curl ifconfig.me
> 5.196.64.231
Prueba de conectividad (Scan TCP Bypass)
nmap -Pn -p 80,443 scanme.nmap.org
"Security is not a product, it's a mindset."
[ EOF ]