OpenVPN no es la puerta de enlace predeterminada para todo el tráfico

Estoy tratando de hacer que mi cliente avance todo el tráfico a través de un VPS que ejecuta OpenVPN. Como puede ver, permitirá pings a dominios y direcciones IP sin procesar, pero no permitirá que el tráfico como el hecho a través de curl y traceroute no surja con nada. El tráfico funciona correctamente cuando no está conectado a la VPN.

Toda la información está aquí: http://pastebin.com/Zpvzs7gW

Gracias.

Configuración de trabajo gracias a la solución siguiente:

Servidor:

port <integer> proto udp dev tun ca ca.crt cert vpnserver.crt key vpnserver.key # This file should be kept secret dh dh4096.pem tls-auth ta.key 0 server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "redirect-gateway autolocal" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" keepalive 10 120 cipher AES-256-CBC comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log verb 3 

Cliente:

 client dev tun proto udp remote xxxx <port number> resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert vpnclient.crt key vpnclient.key tls-auth ta.key 1 ns-cert-type server cipher AES-256-CBC comp-lzo verb 3 

Hay dos partes en la solución:

1. Redireccionar todo el tráfico hacia el túnel

La solución más fácil: use la opción --redirect-gateway autolocal OpenVPN --redirect-gateway autolocal (o póngala en el archivo de configuración como redirect-gateway autolocal .

2. Gestionar el tráfico en el servidor OpenVPN

Ahora que el túnel es todo el tráfico entra en el túnel y aparece en el extremo del tun0 interfaz tun0 .

Debe configurar dos cosas para que funcione:

a. Habilitar el reenvío de paquetes

Por defecto en la mayoría de las distribuciones el reenvío de paquetes está deshabilitado, por lo tanto los paquetes de la interfaz del túnel nunca lo hacen a la interfaz pública. Debe habilitar el reenvío con:

 ~ # sysctl net.ipv4.ip_forward=1 net.ipv4.ip_forward = 1 

Una vez probado haga el cambio permanente en /etc/sysctl.conf

También asegúrese de que iptables no están bloqueando el tráfico reenviado:

 ~ # iptables -I FORWARD -j ACCEPT 

Esto es lo suficientemente bueno para las pruebas – en la producción querrá hacer que las reglas del firewall sean un poco más específicas, pero eso está fuera de alcance aquí.

segundo. NAT los paquetes salientes del túnel

Con el reenvío activado, los paquetes se reenvían por defecto con su dirección de origen sin cambios, es decir, en su caso 10.8.0.6 – dichos paquetes se descartan en la pasarela de ISP o incluso si llegan al destino la respuesta nunca encuentra el camino de regreso. Estas direcciones privadas no son enrutables en Internet.

La solución es NAT el tráfico de egreso, es decir, reemplazar la dirección privada 10.8.0.6 con la IP pública del servidor VPN. Eso garantizará que las respuestas lleguen al servidor VPN y allí se reenviarán al túnel.

 ~ # iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE 

3. Pruébelo

Ahora intente el ping 8.8.4.4 desde su cliente VPN. Debería ver una respuesta. Háganos saber si no 🙂