Tengo lo que es esencialmente un problema de enrutamiento y no estoy lo suficientemente familiarizado con el enrutamiento y con iptables para solucionar problemas y configurar mis necesidades de red de manera efectiva.
¿Qué está funcionando?
Tengo una red openVPN configurada y funcionando; Los clientes pueden conectarse a una LAN a través de Internet.
Lo que me gustaría que pasara
...cuando un cliente se conecta a la VPN en una subred determinada.
- El cliente debe ser accesible desde la red VPN.
Puntos de bonificación si las reglas pueden hacer uno o más de lo siguiente:
- el cliente no debería poder iniciar conexiones a la VPN
- el cliente debería aparecer en nuestro DNS
Topología
Nuestra topología de red se parece a esto:
______ ____________________
/ \ / \
| internet |---| client (10.8.8.0/24) |
\________/ \____________________/
|
______
/ \
| gateway |
\________/
|
-----LAN------ (10.10.10.0/24)
| | | |
L_____VPN Server `VPN1` 10.10.10.2 (fictional name/subnet)
configuraciones actuales
Nuestra pasarela tiene definida la siguiente ruta:
10.8.8.0 255.255.255.0 10.10.10.2 LAN & WLAN
En VPN1, iptables tiene las siguientes reglas
# Flush the filter and nat tables
iptables -t filter -F
iptables -t nat -F
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE
¿Qué está pasando actualmente?
La ejecución del comando mtr 10.8.8.1(la IP del cliente conectado en la VPN) muestra que la ruta actual oscila entre VPN1 y la puerta de enlace.
Respuesta1
Después de otra agotadora ronda de locura por el aprendizaje en línea de iptables, descubrí la solución.
En primer lugar, sin embargo, existe una suposición inválida con respecto a iptables. Mi enfoque inicial de las reglas fue que cuando se recibiera un paquete, pasaría por las cadenas de ENTRADA y SALIDA. No tan; en el momento en que una regla coincide con un paquete, sale de la mesa. Dado que se asume la tabla de filtros a menos que se especifique (por ejemplo, "-t nat"), la mayoría de las reglas enumeradas se ejecutan en la tabla de filtros.
Respecto a las cadenas
- APORTE: se ejecuta en paquetes destinados al servidor
- PRODUCCIÓN: se ejecuta en paquetes que se originan en el servidor
- ADELANTE: todo lo demás - si una regla coincide aquí, y el "salto" (me gusta pensar si-jcomo "trabajo";) es ACEPTAR, el paquete se enrutará adecuadamente
Un desglose de las reglas
Esta es una descripción de las reglas bajoconfiguraciones actualesarriba
iptables -t filter -F
iptables -t nat -F
Estas reglas simplemente limpian elfiltrarynatmesas. Tenga en cuenta que hay más tablas y una forma más completa de borrar las reglas de iptables.
iptables -A INPUT -i tun+ -j ACCEPT
Esta regla no hace nada porque:
- se ejecuta en tráfico destinado a VPN1, no a otra red
- No hay ninguna política establecida para el tráfico entrante, por lo que está permitido de forma predeterminada.
hacia adelante...
iptables -A FORWARD -i tun+ -j ACCEPT
Esta regla permite enrutar el tráfico procedente de 10.8.8.0/24. reglas en elnatLa tabla se ejecuta en paquetes que coinciden con esta regla.
iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24
Esta regla tampoco tiene ningún efecto sobre el enrutamiento deseado, ya que el tráfico 10.8.8.0/24 no está destinado al servidor VPN1.
iptables -A FORWARD -i eth0 -j ACCEPT
Esta regla permite enrutar el tráfico desde 10.10.10.0/16.
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE
Esta regla hace que el tráfico destinado a la VPN desde 10.10.10.0/16 parezca que proviene de VPN1, lo que efectivamente hace que VPN1 parezca una puerta de enlace.
¿Qué ocurre?
Las reglas deberían ser "OK" para llevar el tráfico de una red a la siguiente. No existe ninguna protección real, por ejemplo, una política "DROP" predeterminada, etc., pero ese no es el punto de la pregunta.
Si iptables está configurado para que pueda enrutar el tráfico a través de la VPN, ¿qué causaría que se envíe de regreso?eth0a la puerta de entrada? Si VPN1 no conocía 10.8.8.0/24. Si el servidor VPN no conocía esa red, sería tratado como tráfico de Internet y enviado de regreso a la puerta de enlace.
La solución
La solución fue informarle al servidor VPN sobre la red (este es un servidor openvpn). Hay dos maneras de hacer esto; Si el servidor solo presta servicio a una red, es una configuración simple:
server 10.8.8.0 255.255.255.0
En mi caso, tenía configurada la ruta del servidor y la necesitaba para conocer una red adicional. La configuración se parecía más a esto:
server 10.5.5.0 255.255.255.0
route 10.8.8.0 255.255.255.0
¡Eso es todo! Una vez que VPN1 tuvo una ruta a la red, la cadena FORWARD puede enrutar el tráfico.
Una mejor configuración de iptables
Después de vaciar iptables, una mejor configuración se vería así:
# Forward established traffic so that (in the above case) VPN1 doesn't
# drop responses from the client, A.K.A. "the magic"
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -s 10.10.10.0/16 -d 10.8.8.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -j MASQUERADE
# Drop everything else that wants to be forwarded
iptables -P FORWARD DROP
Tenga en cuenta que no existen reglas explícitas para el tráfico procedente de 10.8.8.0/24, lo que significa que, de forma predeterminada, el tráfico no llegará a la red 10.10.10.0/16, excepto el tráfico en respuesta al tráfico enviado desde 10.10.10.0/16. . Ahora que iptables está configurado, a los clientes se les puede asignar una IP en la configuración de VPN y agregarla a DNS para obtener una solución completa.