====== VPN no puede acceder a la LAN (srv05 como gateway Zerotier) ======
=== Contexto ===
El servidor `srv05` actúa como puente entre la red LAN local `192.168.88.0/24` y la red VPN de Zerotier `10.241.0.0/16`, usando la interfaz `ztkse3ixxp`.
El objetivo era permitir que nodos de la VPN accedan a dispositivos dentro de la LAN hogareña, como por ejemplo un Raspberry Pi.
----
=== Verificaciones básicas ===
* ✅ `srv05` tiene IP `192.168.88.33` asignada a `lxcbr0`
* ✅ `ztkse3ixxp` está **UP** y tiene una IP válida `10.241.x.x`
* ✅ El Mikrotik tiene una ruta estática:
10.241.0.0/16 via 192.168.88.33
* ✅ El Mikrotik permite **forwarding** en ambos sentidos:
10.241.0.0/16 <--> 192.168.88.0/24
* ✅ Desde una máquina en la LAN se puede pingear a hosts de la VPN
* ✅ El `iptables` de `srv05` tiene reglas de FORWARD adecuadas:
sudo iptables -L FORWARD -n -v --line-numbers
-A FORWARD -s 10.241.0.0/16 -d 192.168.88.0/24 -i ztkse3ixxp -o lxcbr0 -j ACCEPT
-A FORWARD -s 192.168.88.0/24 -d 10.241.0.0/16 -i lxcbr0 -o ztkse3ixxp -m state --state RELATED,ESTABLISHED -j ACCEPT
----
=== Problema detectado ===
Desde la VPN no se podía acceder a la LAN (el tráfico era dropeado en `srv05`).
Se verificó el tráfico con:
sudo iptables -I FORWARD 1 -j LOG --log-prefix "FORWARD TRACE: " --log-level 4
tail -f /var/log/syslog | grep "FORWARD DROP:"
Se encontró que el paquete llegaba por `ztkse3ixxp` y salía por `lxcbr0`, pero era dropeado.
----
=== Causa raíz ===
Existía una regla obsoleta en `iptables -t nat`:
-A POSTROUTING -s 10.241.0.0/16 -o lxcbr0 -j SNAT --to-source 192.168.88.84
Esa IP ya no estaba asignada a ninguna interfaz, lo que provocaba un SNAT inválido y rompía el tráfico.
----
=== Solución aplicada ===
- Se eliminó la regla inválida:
sudo iptables -t nat -L POSTROUTING -n --line-numbers
sudo iptables -t nat -D POSTROUTING
- Verificación posterior:
sudo iptables -t nat -S
- Se comprobó que el tráfico funciona **incluso sin SNAT**, dado que:
* El Mikrotik enruta correctamente.
* No se necesita ocultar el origen.
* Es mejor para trazabilidad (los logs muestran la IP real del origen).
----
=== Comandos útiles para este troubleshooting ===
ip a # Ver interfaces y direcciones
ip r # Ver rutas
ip route get # Ruta efectiva hacia un destino
sudo iptables -L FORWARD -v -n --line-numbers
sudo iptables -t nat -L POSTROUTING -n --line-numbers
sudo iptables -t nat -S
sudo iptables -S
----
=== Notas finales ===
Para mantener la configuración:
sudo apt install iptables-persistent
sudo iptables-save | sudo tee /etc/iptables/rules.v4 > /dev/null
Evitar tener múltiples reglas `SNAT` que afecten la misma subred y salida.
Documentar cambios en el Mikrotik (rutas, firewall) para trazabilidad.
----
===== Anexo: Configuración y Diagnóstico IPTables para Gateway Zerotier ↔ LXC =====
=== Resumen ===
El host `srv05` actúa como gateway entre la red VPN de Zerotier (`10.241.0.0/16`) y la red LAN del homelab (`192.168.88.0/24`). Para habilitar esta conectividad, se configuraron reglas de IPTables tanto en la tabla `filter` como en `nat`, y se verificó el ruteo en el router Mikrotik.
=== Reglas Básicas IPTables ===
# Tabla filter
-A FORWARD -s 10.241.0.0/16 -d 192.168.88.0/24 -j ACCEPT
-A FORWARD -s 192.168.88.0/24 -d 10.241.0.0/16 -j ACCEPT
# Tabla nat
-A POSTROUTING -s 10.241.0.0/16 -o lxcbr0 -j SNAT --to-source 192.168.88.33
=== Consideraciones ===
* **Sin necesidad de SNAT si el Mikrotik tiene ruta estática**: Si el router Mikrotik sabe que puede alcanzar `10.241.0.0/16` vía `192.168.88.33`, no hace falta la regla SNAT. Sin embargo, puede ser útil para debugging o si el router impone restricciones por subred.
* **Reglas basadas en subredes en lugar de interfaces**: Esto hace más robusta la configuración frente a cambios de nombres de interfaces.
* **La dirección `192.168.88.84` usada en versiones anteriores fue deprecada**. Revisar la tabla NAT con `iptables -t nat -S` y eliminar reglas obsoletas.
* **`ip a` y `ip r`** son comandos útiles para verificar interfaces y rutas actuales.
=== Troubleshooting: Diagnóstico Paso a Paso ===
==== 1. Habilitar Log de Reglas FORWARD ====
Agregar una regla temporal al inicio de la cadena FORWARD para ver todo el tráfico que pasa (no solo el dropeado):
sudo iptables -I FORWARD 1 -j LOG --log-prefix "FORWARD TRACE: " --log-level 4
Esto logueará *todo* el tráfico que pase por FORWARD, no solo lo que se dropea. Ideal para observar si el tráfico llega pero no coincide con alguna regla `ACCEPT`.
Ver los logs:
tail -f /var/log/syslog | grep "FORWARD TRACE:"
Once you've found the issue, remember to remove the logging rule to avoid excessive log entries:
sudo iptables -D FORWARD -j LOG --log-prefix "FORWARD TRACE: " --log-level 4
==== 2. Confirmar IP Forwarding ====
sysctl net.ipv4.ip_forward
sudo sysctl -w net.ipv4.ip_forward=1
Para hacerlo persistente:
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
==== 3. Verificar Reglas NAT ====
sudo iptables -t nat -S
Eliminar entradas incorrectas:
sudo iptables -t nat -D POSTROUTING -s 10.241.0.0/16 -o lxcbr0 -j SNAT --to-source 192.168.88.84
==== 4. Verificar Rutas en srv05 ====
ip route
Debe haber rutas activas hacia ambas redes (`10.241.0.0/16` y `192.168.88.0/24`), y las interfaces deben estar UP (`ip a`).
==== 5. Confirmar Configuración del Mikrotik ====
* Debe existir una ruta estática:
`10.241.0.0/16 → vía 192.168.88.33`
* Forwarding habilitado entre LAN y VPN.
* NAT deshabilitado o con reglas explícitas de aceptación.
----
Este anexo forma una guía de referencia rápida para resolver problemas de enrutamiento y NAT entre una red VPN virtualizada y un entorno de red de contenedores.