Problema realmente estranho no debian: Não é possível conectar-se a nenhum serviço em execução no Debian a partir de um IP público, funciona bem com IPs privados

Primeiro de tudo, não é um problema de encaminhamento de porta. Ao executar o tcpdump, posso ver os pedidos chegando ao servidor debian, e então eles param.

Meu servidor debian está executando o apache e também o PleX. Se eu conectar ao servidor Debian usando 192.168.1.210, ele funcionará perfeitamente. Consigo ver as páginas da Web e transmitir a partir do PleX.

Se eu sair da minha rede, digamos, eu vou para uma casa de amigos, também não consigo acessar. Usando o tcpdump, posso ver os pacotes chegarem ao servidor, mas é isso. Mesmo com canyouseeme.org.

I fazer ter algum encaminhamento & iptables no lugar. Eu uso esta máquina para torrenting + uma VPN, então eu uso roteamento para manter tudo funcionando. O roteamento deve manter o PleX longe do tun0, a interface da VPN e o iptables deve impedir o usuário da transmissão debian de usar algo diferente de 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

É provavelmente mais fácil descrever o que está acontecendo por um exemplo.

Vamos dizer que o endereço IP dos roteadores NAT é 1.1.1.1 e o endereço IP dos seus amigos é 2.2.2.2 Suponhamos, por uma questão de simplicidade, que seu amigo não esteja atrás de um roteador nat (isso torna o exemplo um pouco mais complicado se eles estiverem Não mudamos fundamentalmente o problema.Eu também assumirei que o encaminhamento de porta está encaminhando a porta 80 no seu IP externo para a porta 80 na caixa Debian.

O computador do seu amigo envia um pacote syn com um endereço de origem 2.2.2.2, uma porta de origem escolhida aleatoriamente (digamos 12345), um endereço de destino 1.1.1.1 e uma porta de destino 80

O pacote alcança o seu NAT, procura a porta para frente e altera o IP de destino para 192.168.1.210. O IP de origem permanece como 2.2.2.2, as portas permanecem as mesmas. Um mapeamento é criado para que a conversão reversa possa ser executada nos pacotes retornados até o momento.

O pacote chega ao seu servidor. Ele é entregue na pilha TCP, que cria um pacote de confirmação em resposta. Normalmente, quando um pacote é respondido à origem e ao destino, são trocados. Portanto, o pacote tem um endereço de origem 192.168.1.210, um endereço de destino 2.2.2.2, uma porta de origem 80 e uma porta de destino 12345.

A resposta sai da pilha TCP e atinge iptables. Suas regras estão executando uma correspondência de UID para que a correspondência do proprietário funcione corretamente, o pacote deve passar por lá.

Em seguida, ele atinge a tabela de roteamento. O que o envia pela VPN. Ele atinge um NAT na VPN, que modifica sua origem de alguma forma, volta ao seu amigo e cai devido a um endereço de origem errado.

Possíveis correções: 1: Adicione o IP de seus amigos à tabela de roteamento, obviamente não dimensiona muito bem e pode causar vazamento de tráfego torrent. 2: Se sua caixa nat for um sistema linux adequado, deve ser possível configurá-lo para alterar a fonte e o destino das conexões de entrada. Portanto, sua caixa de torrents vê a caixa NAT como a fonte, em vez de ver o sistema de seus amigos na internet. 3: use os recursos de "roteamento avançado" no linux para rotear com base na porta de origem. Infelizmente, os recursos avançados de roteamento são muito poderosos, mas também difíceis de entender. Se você quiser obter mais informações sobre como percorrer esta rota, consulte o "howto avançado sobre roteamento e controle de tráfego do linux"