Primeiro de tudo, não é um problema de encaminhamento de porta. Ao executar o tcpdump, posso ver as solicitações chegando ao servidor Debian e então param.
Meu servidor Debian está executando o Apache e também o PleX. Se eu me conectar ao servidor Debian usando 192.168.1.210, ele funcionará perfeitamente. Posso ver as páginas da web e transmitir do PleX.
Se eu sair da minha rede, digamos, vou na casa de um amigo, também não consigo acessar. Usando o tcpdump, posso ver os pacotes chegando ao servidor, mas é isso. O mesmo acontece com canyouseeme.org.
EUfazertenha algum roteamento e iptables em vigor. Eu uso esta máquina para torrent + VPN, então uso roteamento para manter tudo funcionando. O roteamento deve manter o PleX longe do tun0, a interface VPN, e o iptables deve evitar que o usuário debian-transmission use qualquer coisa 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
tabelas de ip:
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
Responder1
Provavelmente é mais fácil descrever o que está acontecendo com um exemplo.
Digamos que o endereço IP do seu roteador NAT seja 1.1.1.1 e o endereço IP do seu amigo seja 2.2.2.2. Vamos supor também, para simplificar, que seu amigo não esteja atrás de um roteador nat (isso torna o exemplo um pouco mais complicado se estiver, mas é isso não muda fundamentalmente o problema. Também assumirei que o encaminhamento de porta está encaminhando a porta 80 em seu IP externo para a porta 80 na caixa Debian.
O computador do seu amigo envia um pacote syn com 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 chega ao seu NAT, procura a porta 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 tradução reversa possa ser realizada no retorno de pacotes até agora tudo bem.
O pacote chega ao seu servidor. Ele é entregue à pilha TCP, que cria um pacote de confirmação em resposta. Normalmente, quando um pacote é respondido, a origem e o 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 chega ao iptables. Suas regras estão realizando uma correspondência de UID para que a correspondência do proprietário funcione corretamente e 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 fonte de alguma forma, volta para seu amigo e é descartado por ter o endereço de origem errado.
Possíveis soluções: 1: Adicione o IP de seus amigos à tabela de roteamento, obviamente não escala muito bem e pode causar vazamento de tráfego de torrent. 2: Se a sua caixa nat for um sistema Linux adequado, deverá ser possível configurá-la para alterar a origem e também o destino das conexões de entrada. Assim, sua caixa de torrent 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 mais informações sobre como seguir esse caminho, verifique o "como fazer roteamento avançado e controle de tráfego do Linux"