Encaminhamento de porta de roteador duplo

0

Eu tenho roteadores adicionais atrás do Modem / Roteador fornecido pelo meu provedor. Essa configuração foi criada para lidar com vários problemas, como o encaminhamento de portas de conexões que entram na Internet e precisam ser direcionadas para um Windows Server conectado ao segundo roteador.

O layout é assim:

  • Modem / roteador ISP 192.168.100.1 - recebe tráfego de entrada da Internet (DHCP ativado), incluindo TV por demanda, passando-o para um decodificador de TV e para o segundo roteador.
  • 2º Roteador 192.168.90.1 - recebe tráfego da Internet do Modem / Roteador ISP, configurado com 192.168.100.1 como Gateway Padrão e (DHCP habilitado) atendendo a todo o tráfego LAN WiFi e Ethernet, incluindo o Windows Server configurado como 192.168.90.10. / li>

Eu uso um aplicativo baseado em MS-SQL, executado neste servidor e em um PC de mesa complementar (192.168.90.11), para habilitar a sincronização de banco de dados a partir da LAN e da Internet. O LAN PC Sync com o servidor funciona bem, o Sync externo (internet) não pode se conectar ao servidor. Mas o PC externo pode fazer ping no servidor que tem um domínio DDNS instalado e funcionando.

Eu tentei configurar portas abertas no firewall do servidor, sem sorte. Desativado o Firewall, sem sorte.

Entre os dois roteadores, configurei o encaminhamento de porta da seguinte forma:

  • Roteador 1 (192.168.100.1) - portas de encaminhamento 80, 65100, 1433, 1434 etc para
  • Roteador 2 (192.168.90.1) - encaminhar as portas 80, 65100, 1433, 1434 etc para o servidor (192.168.90.10)

Meu objetivo principal ao separar as duas LANs é manter a TV na Internet e o hardware associado separados dos dispositivos Windows e Android que vêm e vão.

Há algo que estou perdendo ou há uma maneira melhor de abordar isso?

    
por Geoff Whiteley 11.07.2018 / 05:33

1 resposta

0

Em geral, isso deve funcionar. Existem duas situações:

  1. O roteador 1 não tem uma rota para a segunda sub-rede (192.168.90.0/24, suponho).

    Nesse caso, todos os redirecionamentos de porta no roteador 1 devem usar o endereço IP externo (WAN) do roteador 2, ou seja, 192.168.100.x , porque ele não sabe como acessar o interno. / p>

  2. O roteador 1 tem uma rota estática em direção à segunda sub-rede.

    Nesse caso, os encaminhamentos de porta no Roteador 1 podem apontar diretamente para o endereço IP do seu servidor, e o Roteador 2 não precisa de nenhum encaminhamento de porta. (No entanto, o roteador 2 faz precisa de regras de firewall que permitam conexões de entrada.)

(Eu diria 2º é uma abordagem mais direta.)

Você não mencionou nada sobre o teste dos componentes individuais. As conexões levam alguns saltos, então não é um black & branco "funciona / não funciona".

  1. As conexões da Internet para a porta TCP 80 chegam ao seu roteador externo?

    Isso pode ser difícil ou impossível de testar se for um modem / roteador combo bloqueado. (Se tiver sorte, terá acesso ao telnet e tcpdump instalado.)

    Mas observe que alguns ISPs bloqueiam as conexões de entrada em certas portas, seja porque são arriscadas (o MS-SQL em particular tinha worms graves em algum momento) ou porque o ISP quer mais vendas para seu plano de negócios (bloqueando, assim, o site de hospedagem nos planos do consumidor).

  2. O roteador externo os encaminha corretamente para o que for especificado nas regras de encaminhamento de porta? Em outras palavras, o roteador 2 recebe os pacotes?

    Se o roteador 2 não tiver nenhum método para testar isso (sem telnet / tcpdump), altere as regras de encaminhamento para apontar para um computador na rede 192.168.100.xe execute o Wireshark nesse computador para confirmar que está recebendo os pacotes. (Então mude as regras de volta.)

  3. O roteador interno encaminha corretamente os pacotes para o servidor?

    Desta vez, o servidor pode ter o Wireshark ou o tcpdump instalados facilmente, então você só precisa iniciar uma captura e observar os pacotes.

    A captura não é afetada pelo próprio firewall do servidor, portanto, ele mostrará os pacotes mesmo que o SO não reaja a eles. (Se isso acontecer, você pode assumir que o firewall do servidor é o problema.)

  4. O servidor responde?

  5. As respostas percorrem todo o caminho de volta?

por 11.07.2018 / 07:38