it-swarm-es.com

OpenVPN + iptables / NAT enrutamiento

Estoy tratando de configurar una VPN OpenVPN, que llevará algo (pero no todo) el tráfico de los clientes a Internet a través del servidor OpenVPN.

Mi servidor OpenVPN tiene una IP pública en eth0 y usa tap0 para crear una red local, 192.168.2.x. Tengo un cliente que se conecta desde la IP local 192.168.1.101 y obtiene la IP de VPN 192.168.2.3.

En el servidor, ejecuté:

iptables -A INPUT -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

En el cliente, el valor predeterminado sigue siendo enrutar a través de 192.168.1.1. Para apuntar a 192.168.2.1 para HTTP, ejecuté

ip rule add fwmark 0x50 table 200
ip route add table 200 default via 192.168.2.1
iptables -t mangle -A OUTPUT -j MARK -p tcp --dport 80 --set-mark 80

Ahora, si intento acceder a un sitio web en el cliente (por ejemplo, wget google.com), simplemente se cuelga allí. En el servidor, puedo ver

$ Sudo tcpdump -n -i tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
05:39:07.928358 IP 192.168.1.101.34941 > 74.125.67.100.80: S 4254520618:4254520618(0) win 5840 <mss 1334,sackOK,timestamp 558838 0,nop,wscale 5>
05:39:10.751921 IP 192.168.1.101.34941 > 74.125.67.100.80: S 4254520618:4254520618(0) win 5840 <mss 1334,sackOK,timestamp 559588 0,nop,wscale 5>

Donde 74.125.67.100 es la IP que obtiene para google.com.

¿Por qué no funciona la MASQUERADE? Más precisamente, veo que la fuente aparece como 192.168.1.101, ¿no debería haber algo que indique que proviene de la VPN?

Editar: algunas rutas [del cliente]

$ ip route show table main
192.168.2.0/24 dev tap0  proto kernel  scope link  src 192.168.2.4
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.101  metric 2
169.254.0.0/16 dev wlan0  scope link  metric 1000
default via 192.168.1.1 dev wlan0  proto static

$ ip route show table 200
default via 192.168.2.1 dev tap0
5
Mikeage

Dos cosas estaban mal:

Primero, en el cliente, necesitaba SNAT la fuente para la IP real.

En segundo lugar, el filtro de ruta inversa estaba bloqueando los paquetes de retorno, ya que pensaba que estaban falsificados. echo 0 > /proc/sys/net/ipv4/conf/tun0/rp_filter arregló eso

1
Mikeage

¿Puede publicar la salida de ip route show table main y ip route show table 2? Sospecho que le faltan un par de rutas en su tabla '200'. Su tabla de rutas '200' debería tener prácticamente las mismas rutas que la tabla 'principal', siendo la única diferencia la ruta predeterminada.


Veo que actualizaste y creo que mi sugerencia original era correcta. ¿Observa cómo su tabla principal tiene la ruta de 'enlace de alcance' tanto para su red local como para el enlace vpn? Esas rutas también deben agregarse a la tabla '200'.

Intente ejecutar estos comandos además de los otros comandos que usa.

ip route add 192.168.2.0/24 dev tap0  proto kernel  scope link  src 192.168.2.4 table 200
ip route add 192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.101  metric 2 table 200
ip route flush cache

Si desea crear un script para la creación de estas rutas, puede usar esto. Copiará todas las rutas de 'enlace de alcance' de la tabla de ruta principal a la otra tabla.

#!/bin/bash
IFACE=wlan0
RT=200
/sbin/ip route list scope link table main proto kernel dev ${IFACE} \
| while read ROUTE ; do
    # and add that route to all the tables mentioned in the rrtables option
    # in the interfaces file
    /sbin/ip route add table ${RT} scope link proto kernel dev ${IFACE} ${ROUTE}
done

Otra actualización. Me di cuenta de que me perdí algo bastante obvio antes.

Su declaración MASQ parece estar funcionando en eth0. De las tablas de ruta que publicó, su dispositivo de salida no es eth0. En lugar de esto.

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Probablemente debería usar una declaración como esta.

iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
3
Zoredache

Prueba en el servidor:

echo 1 > /proc/sys/net/ipv4/ip_forward

Eso, creo, lo habilitará temporalmente. Si funciona agregue:

net.ipv4.conf.default.forwarding=1 

a su /etc/sysctl.conf para hacerlo permanente.

0
Neobyte