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

1

Em primeiro lugar, não é um problema de encaminhamento de porta. Ao rodar o tcpdump, consigo ver os pedidos chegando ao servidor do Debian e eles param.

Meu servidor Debian está executando o Apache, assim como o PleX. Se eu me conectar ao servidor Debian usando 192.168.1.210, ele funciona perfeitamente. Eu posso ver as páginas da web e posso transmitir a partir do PleX.

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

Eu faço tenho algumas rotas & iptables no lugar. Eu uso esta máquina para torrent + VPN, então eu uso roteamento para manter tudo funcionando. O roteamento deve manter o PleX longe do tun0, a interface VPN, e o iptables deve manter o usuário debian-transmitindo de 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
    
por Stephen 16.10.2015 / 02:29

1 resposta

0

Provavelmente é mais fácil descrever o que está acontecendo com um exemplo.

Digamos que o endereço IP dos seus roteadores NAT seja 1.1.1.1 e o endereço IP de seus amigos seja 2.2.2.2 Vamos supor que o seu amigo não esteja atrás de um roteador nat (torna o exemplo um pouco mais complicado se eles são, mas não muda fundamentalmente o problema.Eu também supor que a porta para a frente está aportando a porta 80 em 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 de 1.1.1.1 uma porta de destino de 80

O pacote chega ao seu NAT, ele 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 tradução reversa possa ser executada nos pacotes de retorno tão bem.

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

A resposta deixa a pilha TCP e atinge o 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. Que envia para baixo a VPN. Ele atinge um NAT na VPN que modifica sua origem de alguma forma, retorna para seu amigo e é descartado devido ao endereço de origem errado.

Correções possíveis: 1: Adicione o IP de seus amigos à tabela de roteamento, obviamente, não dimensiona muito bem e pode causar vazamento no tráfego de torrent. 2: Se o seu nat box é um sistema linux adequado, deve ser possível configurá-lo para alterar a fonte, assim como o destino das conexões de entrada. Então, a sua caixa de torrent, em seguida, vê a caixa NAT como a fonte, em vez de ver o seu sistema de 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 essa rota, confira o "guia avançado de roteamento e controle de tráfego do linux"

    
por 19.10.2015 / 01:59