O encaminhamento de porta não funciona para determinado IP da LAN

O encaminhamento de porta não funciona para determinado IP da LAN

Espero que alguém possa lançar alguma luz sobre isso. Meu conhecimento de networking é, na melhor das hipóteses, básico.

Tenho um servidor CentOS em duas redes:

  • NIC1 está em um IP público com gateway configurado no Switch 1. (Internet ADSL)
  • NIC2 está configurado para 10.10.10.2 sem nenhum gateway definido no switch 2. (Internet a cabo)
  • O gateway/roteador do switch 2 é 10.10.10.1. (roteador ASUS)

Dentro da LAN, outros PCs da LAN são capazes de acessar 10.10.10.2 em portas abertas. Quando uma regra de encaminhamento de porta é definida no gateway/roteador 10.10.10.1 --> 10.10.10.2, isso não está funcionando. O encaminhamento de porta no gateway/roteador 10.10.10.1 -> para 10.10.10.3 funciona (máquina Windows com gateway definido para 10.10.10.1).

É possível acessar 10.10.10.2 da Internet pública através do roteador ASUS 10.10.10.1?

Responder1

Roteamento de política IP.

Encontrei dois artigos do mesmo que usei para atualizar meu servidor CentOS para permitir que a segunda NIC recebesse e enviasse pacotes. Também foi bem-sucedido na atualização de outro servidor semelhante com NICs/gateways duplos.

http://jensd.be/468/linux/two-network-cards-rp_filter<- Configurei políticas de IP na seção 'melhor solução' e não alterei o valor de rp_filter. Este artigo também tem bons diagramas.

http://www.microhowto.info/howto/ensure_metric_routing_on_a_server_with_multiple_default_gateways.html <-exemplo adicional do acima que deixou tudo mais claro para mim.

Se você deseja que as alterações sejam permanentes, siga as instruções no primeiro link acima.

Meu exemplo:

  • ip route add 99.88.77.66/24 dev eth0 tabela 1 (exemplo IP público #1)
  • ip route add default via 99.88.77.1 tabela 1 (exemplo de gateway do IP público nº 1)
  • ip route add 10.10.10.0/24 dev eth1 table 2 (segunda NIC em rede diferente)
  • ip route add default via 10.10.10.1 tabela 2 (gateway do roteador ASUS)
  • adição de regra de ip de 99.88.77.66/32 tabela 1 prioridade 100
  • adição de regra ip de 10.10.10.4/32 tabela 2 prioridade 110
  • cache de liberação de rota ip

O /24 para você pode mudar dependendo da máscara de sub-rede dos seus IPs.

Responder2

Primeiro precisamos entender por que sua configuração não funciona. Para fazer isso, precisamos considerar o que acontece.

  • Uma tentativa de conexão vem da conexão "cabo" com a Internet.
  • O roteador NAT modifica o endereço de destino e configura uma entrada na tabela de mapeamento.
  • O pacote chega ao seu servidor e uma resposta é gerada.
  • Seu servidor procura o destino da resposta em sua tabela de roteamento e envia o pacote para o gateway padrão (por exemplo, para a conexão de internet "ADSL").
  • Muito provavelmente o pacote foi descartado por ter um endereço de origem falso. Mesmo que retorne ao cliente, seu endereço de origem não corresponderá ao que o cliente espera, portanto, o cliente o descartará como falso.

Agora que entendemos o que está errado, podemos fazer algo a respeito. Existem algumas opções.

A opção 1 é usar "roteamento de política" no servidor para rotear o tráfego com base no IP de origem. Esta é a melhor opção do servidor que suporta (versões recentes do Linux sim).A resposta de Stileaborda como configurar o roteamento de política em um servidor Linux para rotear com base no endereço de origem.

A opção 2 é apontar o gateway padrão do servidor para uma caixa que possa fazer o roteamento de políticas. Então essa caixa pode rotear o tráfego corretamente dependendo do IP de origem. Esta pode ser uma solução útil se o sistema operacional do servidor não suportar roteamento de políticas.

A opção 3 é fazer a caixa NAT Masqurade para o tráfego que está encaminhando de porta. Eu consideraria esta uma opção de último recurso, pois oculta o endereço de origem real do tráfego.

informação relacionada