¿Puerto adelante al cliente VPN?

21

Me he encontrado con un poco de rompecabezas y no he tenido mucha suerte en encontrar una solución. En este momento estoy (lamentablemente) conectado a la red a través de Verizon 3G. Filtran todo el tráfico entrante, por lo que me es imposible abrir puertos para aceptar conexiones.

Actualmente tengo una máquina virtual Linux en linode.com, y se me ocurrió la idea de instalar pptpde intentar hacer un iptablesreenvío de puertos. He pptpdinstalado y mi máquina doméstica se conecta felizmente. Dicho esto, aquí hay información general:

Servidor (Debian) IP WAN: xxxx en eth0 - pptpd IP: aaa1 en ppp0 - Cliente VPN IP: aaa100

Para verificar que no me estaba volviendo loco, intenté algunas conexiones desde el servidor a los puertos abiertos del cliente, y el cliente acepta las conexiones a través de la VPN IP.

Lo que quiero lograr es esto:

Internet -> WAN IP: Puerto -> Reenviar al cliente VPN IP: Puerto

Entonces, por ejemplo, si tuviera el puerto 6000 abierto en mi cliente, una persona podría hacer telnet en xxxx: 6000, y el servidor lo detectaría y lo reenviaría a 192.168.3.100:6000.

He probado al menos 20 iptablesconfiguraciones diferentes de Google y ninguna ha funcionado todavía. ¿Alguien tiene alguna idea, o tal vez incluso un enfoque totalmente diferente que no conozco? El objetivo aquí es escuchar a través de una conexión horriblemente cortafuegos, preferiblemente tráfico TCP y UDP.

— Brigante vil
fuente

25

Necesita hacer tres cosas en su servidor VPN (el Linode) para que esto funcione:

Debe habilitar el reenvío de IP:
```
sysctl -w net.ipv4.ip_forward=1
```
Configure el destino NAT (DNAT) para reenviar el puerto. Probablemente ya haya descubierto esto porque es un estándar de reenvío de puertos, pero para completar:
```
iptables -t nat -A PREROUTING -d x.x.x.x -p tcp --dport 6000 -j DNAT --to-dest y.y.y.100:6000
```
Configure la fuente NAT (SNAT) para que, desde la perspectiva de su cliente VPN, la conexión provenga del servidor VPN:
```
iptables -t nat -A POSTROUTING -d y.y.y.100 -p tcp --dport 6000 -j SNAT --to-source y.y.y.1
```

La razón por la que necesita el SNAT es porque, de lo contrario, su cliente VPN enviará sus paquetes de devolución directamente al host que inició la conexión (zzzz) a través de su puerta de enlace predeterminada (es decir, Verizon 3G), y no a través de la VPN. Por lo tanto, la dirección IP de origen en los paquetes de devolución será su dirección Verizon 3G, y no xxxx. Esto causa todo tipo de problemas, ya que zzzz realmente inició la conexión a xxxx

En la mayoría de las configuraciones de reenvío de puertos, el SNAT no es necesario porque el host que realiza el reenvío de puertos también es la puerta de enlace predeterminada para el host de destino (por ejemplo, un enrutador doméstico).

También tenga en cuenta que si desea reenviar el puerto 6000 a un puerto diferente (digamos 7000), la regla SNAT debe coincidir con 7000, no 6000.

— AGWA
fuente

Hola AGWA, gracias por la respuesta. Ya tenía ip_forwarding activado, y sus reglas funcionaron perfectamente, aunque inicialmente no. El problema era (en mi nobilidad de iptables) que no me di cuenta de que iptables -F no eliminaba las entradas nat, y iptables -L no las enumeraba. Después de descubrir cómo enumerarlos correctamente, noté varias entradas conflictivas de los intentos anteriores. Después de enjuagar y probar sus reglas, funciona perfectamente. Sin embargo, una pregunta rápida, en sus reglas, especifica tcp. ¿Cambiar esto a "todos" funcionaría tanto para el tráfico TCP / UDP?

— Vile Brigandier

¡De nada! (Por cierto, me gusta usar iptables-savepara mostrar mis reglas de iptables, aunque el resultado no está destinado al consumo humano, todavía es legible y muestra todas sus reglas de iptables). No, desafortunadamente no puede usar "all" allí, porque --dportsolo funciona con protocolos que realmente tienen puertos ("todos" incluirían, por ejemplo, ICMP, que no tiene noción de puertos). Necesitará reglas separadas para TCP y UDP.

— AGWA

Gracias por el consejo de iptables-save. Todo funciona como se espera tanto para TCP como para UDP. Aclamaciones.

— Vile Brigandier

2

Una actualización de esta respuesta es que con iproute2, puede configurar su cliente VPN para que tenga 2 puertas de enlace y enrutar el tráfico DNAT de regreso a través de la VPN. Esto es beneficioso si no desea utilizar SNAT y parece que todo el tráfico proviene del servidor vpn. thomas-krenn.com/en/wiki/Two_Default_Gateways_on_One_System incluye información sobre cómo configurarlo.

— PressingOnAlways

Funciona para mí siempre que ufw esté desactivado, a pesar de que he permitido 8080 en ufw, pero tan pronto como habilite ufw, este reenvío no funciona ... ¿alguna idea?

— Sudhir N

3

También tuve este problema e intenté resolverlo durante horas. Aquí está mi solución:

Tenía más de uno VPNClientcon lo mismo IPAddress. Así que les di a cada uno una estáticaIPAddress

Defina un directorio donde se deben almacenar los scripts del cliente, por ejemplo / etc / openvpn / staticclients y cree el directorio
mkdir /etc/openvpn/staticclients
Agregue este directorio como opción a su archivo de configuración openvpn en el servidor:
client-config-dir /etc/openvpn/staticclients
Para cada cliente, debe crear un archivo. El nombre del archivo debe coincidir con el common nameatributo que se especificó en el certificado del cliente. Este comando obtiene el CN del certificado de la computadora:

Este ejemplo IPAddressempuja el 10.1.134.110/10.1.134.109 al Cliente con el common name TESTCLIENT y también empuja una ruta adicional para la subred 10.1.135.0.
cat /etc/openvpn/staticclients/TESTCLIENT

ifconfig-push 10.1.134.110 10.1.134.109
push "route 10.1.135.0 255.255.255.0 10.1.134.62"

http://www.yougetsignal.com/tools/open-ports/ y http://canyouseeme.org/ no detectaron correctamente los puertos. Además, tuve que iniciar mi aplicación en el cliente, para que los sitios web pudieran ver estos puertos.
No hay necesidad de SNATreglas adicionales . Solo se necesitaban estas reglas:

sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A PREROUTING -p tcp --dport 28006 -j DNAT --to 10.1.134.110

— Dominic Jonas
fuente

2

La mayoría de los servidores tienen el reenvío de IP deshabilitado en la configuración predeterminada. Debe habilitarlo si desea redirigir las conexiones entrantes a través de su VPN.

Prueba esto:

sysctl -w net.ipv4.ip_forward = 1

Me refiero además de la configuración de iptables.

— Andrey Voitenkov
fuente

0

Lo que desea lograr es (probablemente) muy posible con pptpdOpenVPN e iptables, sin embargo, es posible que encuentre un mejor candidato para este caso de uso. Acabo de leer esto, que describe cómo configurar tinc exactamente para este caso de uso. Es una alternativa (potencialmente más simple) a la parte pptdpo OpenVPN. Entonces necesitarías exactamente las mismas reglas para iptables.

— chmac
fuente