Desconectado tráfego IP com um servidor multihomed

Question

(Antes de entrar em detalhes, estou apresentando este problema com Apache e SSH como exemplo, mas isso não é específico para o tráfego TCP, é o mesmo problema com protocolos baseados em TCP e UDP.)

Eu tenho um servidor multilinked multihomed com Ubuntu 9.04, com eth0 conectado a uma rede outside e eth1 conectado a uma rede inside . A rede externa é apresentada ao "resto do mundo" e a rede interna contém todas as estações de trabalho e servidores de trabalho. Há um firewall bloqueando o tráfego do "resto do mundo" para a rede interna, mas não bloqueando solicitações de saída.

$ /sbin/ifconfig
eth0  Link encap:Ethernet  HWaddr 00:30:18:a5:62:63  
      inet addr:xxx.yyy.159.36  Bcast:xxx.yyy.159.47  Mask:255.255.255.240
      [snip]

eth1  Link encap:Ethernet  HWaddr 00:02:b3:bd:03:29  
      inet addr:xxx.zzz.109.65  Bcast:xxx.zzz.109.255  Mask:255.255.255.0
      [snip]

$ route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xxx.yyy.159.32  0.0.0.0         255.255.255.240 U     0      0        0 eth0
xxx.zzz.109.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         xxx.yyy.159.33  0.0.0.0         UG    100    0        0 eth0

Apache está escutando na porta 80, sshd ouvindo 22:

$ netstat --tcp -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 *:www                   *:*                     LISTEN     
tcp        0      0 *:ssh                   *:*                     LISTEN     
[snip]

Da minha máquina de desenvolvimento no interior, xxx.zzz.109.40, eu posso conectar ao endereço interno e tudo está bem. Do lado de fora, posso me conectar ao endereço externo e tudo funciona como deveria.

Mas, para alguns tipos de teste, gostaria de me conectar ao endereço externo da minha máquina de desenvolvimento, mas o servidor está recusando a solicitação de conexão. Eu estou supondo que ele está procurando em suas tabelas de roteamento e desde que os dados de entrada são provenientes de um endereço que deveria estar na eth1, mas está chegando na eth0 que está descartando, provavelmente como uma precaução de segurança.

Existe alguma maneira de eu relaxar essa restrição?

O curioso é que isso costumava funcionar em 8.04, mas não funciona em 8.10 ou 9.04, então em algum momento durante o último ano o kernel está fazendo alguma verificação extra. Para que a conexão funcione, o caminho de retorno precisa ser o mesmo que o caminho de origem, então isso significa que as mensagens da minha máquina de desenvolvimento que chegam na eth0 teriam que voltar na eth0 para serem roteadas de volta para minha máquina.

Aqui está um diagrama, não há nenhum NAT em lugar algum.

Diagrama http://i25.tinypic.com/ff37yx.png

    

Answer 1

Supondo que você não tenha regras de iptables que possam impedir isso, é necessário desativar a filtragem do caminho de retorno. Você pode fazer isso usando:

# echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

Você também pode usar um nome de interface específico em vez de todos e também há um padrão, o que afetaria interfaces recém-criadas.

De:

reverse path filter; it is a check to see if, for a packet arriving on an interface, a packet sent to the original packet's source address would be sent out on that interface; if not, the arriving packet is dropped. it can be considered an attempt at detecting packets with spoofed source addresses.

    

Answer 2

Você não mostrou sua configuração de firewall, mas aposto que há uma regra que está fazendo algo desfavorável com conexões de filtragem para o endereço IP externo de dentro. Uma configuração NAT gravemente defeituosa também poderia estar em falta, mas estou tendo problemas para visualizar algo tão patológico resultante de uma tentativa comum de configuração.

Só para esclarecer um ponto também: só porque um pacote vem de uma interface endereçada ao endereço IP de uma interface diferente, o não fará com que o kernel rejeite esse pacote. O que quer que esteja acontecendo, não é culpa do kernel.

Além disso, um tcpdump de tráfego (tanto nas interfaces internas quanto externas do servidor e no cliente) seria útil para diagnósticos.

    

Answer 3

O que é gateway padrão para sua máquina de desenvolvimento? O gateway padrão assumindo o Switch / Router da Camada 3 deve saber como alcançar a outra interface do servidor.

Você deve ter algo como

ip route xxx.yyy.159.36 netmask 255.255.255.240 gw xxx.zzz.109.65

Isso deve fazer as coisas funcionarem. Mas, caso isso não seja suficiente, habilite o encaminhamento de IP na máquina xxx.zzz.109.65 usando

sysctl net.ipv4.ip_forward = 1

Edite também o /etc/sysctl.conf e habilite o encaminhamento de ip para lá também.

Verifique se a cadeia FORWARD do iptables da tabela de filtros em xxx.zzz.109.65 permite o encaminhamento de pacotes para sua máquina de desenvolvimento.

    

Answer 4

Eu estou supondo que você está usando essa caixa como seu roteador nat nativo usando o iptables NAT - obviamente, se esse não for o caso, isso não ajudará, caso contrário você provavelmente precisará de algo como:

iptables -t nat -I POSTROUTING -s xxx.zzz.109.0/24 -d xxx.yyy.159.36 -j ACCEPT

Isso irá pular a fonte que você está fazendo para os pacotes que viajam de dentro para fora para qualquer coisa destinada ao IP externo desse servidor.

    

Answer 5

Apenas para ser anal, eu não chamaria a configuração de rede multihomed acima. É apenas o encaminhamento entre duas redes dentro do mesmo AS. Multihomed nos dias de hoje realmente significa conectado a dois ou mais vizinhos (AS), ou pelo menos várias rotas para o mesmo vizinho upstream (AS), no caso de uma rede de folhas com um único provedor de conectividade upstream.

    

Answer 6

Muitas ideias úteis já fornecidas. Eu gostaria a) Verifique novamente que não é o firewall / NAT. Adicione uma regra -j LOG antes de suas regras REJECT e DROP e veja se algo suspeito é detectado. b) Execute o tcpdump em ambas as interfaces (-i any) e procure por seus pacotes.

BTW, o que exatamente você quer dizer com "o servidor está recusando a solicitação de conexão"? Você vê alguma mensagem de recusa (imediata) ou a conexão acabou?

    

Answer 7

Isso tem que ser um problema com suas regras de firewall. O mais provável é que o IP externo da caixa seja englobado com "todo o tráfego externo" e, portanto, não seja permitido o acesso ao cliente interno. Tente colocar uma exceção nas regras de firewall para esse endereço IP; isto é, permite explicitamente que o endereço IP externo do servidor envie tráfego para as redes internas.

Mais depuração exigirá que você publique suas regras de firewall.