Problema realmente extraño de Debian: no puedo conectarme a ningún servicio que se ejecute en Debian desde ninguna IP pública, funciona bien con IP privadas

Problema realmente extraño de Debian: no puedo conectarme a ningún servicio que se ejecute en Debian desde ninguna IP pública, funciona bien con IP privadas

En primer lugar, no se trata de un problema de reenvío de puertos. Al ejecutar tcpdump, puedo ver que las solicitudes llegan al servidor Debian y luego se detienen.

Mi servidor Debian ejecuta Apache y PleX. Si me conecto al servidor Debian usando 192.168.1.210, funciona perfectamente. Puedo ver las páginas web y puedo transmitir desde PleX.

Si salgo de mi red, digamos, voy a la casa de un amigo, tampoco puedo acceder. Usando tcpdump, puedo ver que los paquetes llegan al servidor, pero eso es todo. Lo mismo con canyouseeme.org.

Ihacertenga algunas rutas e iptables implementadas. Utilizo esta máquina para descargar torrents + una VPN, así que uso enrutamiento para que todo siga funcionando. Se supone que el enrutamiento mantiene a PleX alejado de tun0, la interfaz VPN, y se supone que iptables evita que el usuario debian-transmission use cualquier otra cosa que no sea tun0.

 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.172.1.5      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.172.1.1      10.172.1.5      255.255.255.255 UGH   0      0        0 tun0
10.172.1.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
50.18.0.0       192.168.1.1     255.255.0.0     UG    0      0        0 eth0
54.241.0.0      192.168.1.1     255.255.0.0     UG    0      0        0 eth0
128.0.0.0       10.172.1.5      128.0.0.0       UG    0      0        0 tun0
184.72.0.0      192.168.1.1     255.255.192.0   UG    0      0        0 eth0
184.169.128.0   192.168.1.1     255.255.128.0   UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
216.144.236.186 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0

iptables:

target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.1.0/24       owner UID match debian-transmission
REJECT     all  --  anywhere             anywhere             owner UID match debian-transmission reject-with icmp-port-unreachable

Respuesta1

Probablemente sea más fácil describir lo que está sucediendo con un ejemplo.

Digamos que la dirección IP de su enrutador NAT es 1.1.1.1 y la dirección IP de su amigo es 2.2.2.2. Supongamos también, en aras de la simplicidad, que su amigo no está detrás de un enrutador nat (hace que el ejemplo sea un poco más complicado si lo está, pero Esto no cambia fundamentalmente el problema. También asumiré que el reenvío de puerto está reenviando el puerto 80 en su IP externa al puerto 80 en la caja Debian.

La computadora de su amigo envía un paquete de sincronización con una dirección de origen de 2.2.2.2, un puerto de origen elegido al azar (digamos 12345), una dirección de destino de 1.1.1.1 y un puerto de destino de 80.

El paquete llega a su NAT, busca el puerto hacia adelante y cambia la IP de destino a 192.168.1.210. La IP de origen sigue siendo 2.2.2.2, los puertos siguen siendo los mismos. Se crea un mapeo para que se pueda realizar la traducción inversa en los paquetes que regresan, hasta ahora todo bien.

El paquete llega a su servidor. Se entrega a la pila TCP, que crea un paquete de confirmación en respuesta. Como es normal, cuando se responde un paquete, se intercambian el origen y el destino. Entonces el paquete tiene una dirección de origen de 192.168.1.210, una dirección de destino de 2.2.2.2, un puerto de origen de 80 y un puerto de destino de 12345.

La respuesta sale de la pila TCP y llega a iptables. Sus reglas realizan una coincidencia de UID para que la coincidencia del propietario funcione correctamente y el paquete debería pasar allí.

Luego llega a la tabla de enrutamiento. Lo que lo envía por la VPN. Llega a una NAT en la VPN que modifica su fuente de alguna manera, regresa con su amigo y se descarta debido a que tiene la dirección de origen incorrecta.

Posibles soluciones: 1: Agregue la IP de sus amigos a la tabla de enrutamiento, obviamente no se escala muy bien y puede causar fugas de tráfico de torrent. 2: Si su caja nat es un sistema Linux adecuado, debería ser posible configurarlo para cambiar el origen y el destino de las conexiones entrantes. Entonces, su caja de torrent ve la caja NAT como la fuente en lugar de ver el sistema de sus amigos en Internet. 3: utilice las funciones de "enrutamiento avanzado" en Linux para enrutar según el puerto de origen. Desafortunadamente, las funciones avanzadas de enrutamiento son muy poderosas pero también difíciles de entender. Si desea obtener más información sobre cómo seguir esta ruta, consulte el "procedimiento de control de tráfico y enrutamiento avanzado de Linux".

información relacionada