Estou hospedando alguns sites/serviços como o Jenkins em um servidor que tenho em casa. Gostaria que eles fossem acessíveis pela Internet e também pela intranet por meio de um nome de domínio público. Para isso registrei um nome de domínio noip apontando para meu ipv4 público (dinâmico). O roteador tem encaminhamentos de porta configurados para NAT em uma porta no meu servidor.
Tudo isso estava funcionando bem, até que mudei de provedor de rede e, portanto, de roteador no fim de semana passado.
Agora não consigo me conectar aos meus sites pela intranet usando o nome de domínio público que está sendo resolvido para meu IP público.
O que eu testei:
- Fazer ping no nome de domínio público da intranet resolve o ip público correto -> sem problema de DNS
- Os sites são acessíveis pela Internet ao usar o nome de domínio público (ou IP) e a porta correta
- Os sites NÃO são acessíveis pela intranet ao usar o nome de domínio público (ou IP) e a porta correta. Neste caso o navegador mostra um erro de tempo limite de conexão de rede (ERR_CONNECTION_TIMED_OUT)
- Os sites são acessíveis pela intranet ao usar o IP interno e a porta correta (conforme especificado na regra de encaminhamento de porta para destino)
Qual configuração de rede no roteador deve ser alterada para que ele roteie corretamente a partir da intranet?
Manual do roteador:https://www.sunrise.ch/content/dam/sunrise/residential/hilfe/internet/Sunrise_Home_User_Manual_Sunrise_Internet_Box_new_firmware_e.pdf
Configuração do roteador:
O Firewall está atualmente desativado para garantir que não esteja causando problemas:
Esta é uma duplicação do meu post aqui:https://networkengineering.stackexchange.com/posts/59290
Responder1
Esta é principalmente uma resposta baseada em suposições com base no problema mais comum desse tipo. Para ter certeza absoluta, entretanto, você precisa realmente investigar o que o servidor vê (Wireshark/tcpdump são boas ferramentas).
DNAT (encaminhamento de porta) dentro da mesma sub-rede é muito problemático, pois o caminho de retorno do servidor para o cliente geralmente ignora o roteador e não há chance de cancelar o NAT desse tráfego de retorno.
Para contornar isso, alguns (mas não todos) roteadores têm uma opção "NAT loopback" ou "NAT hairpin". Pelo que entendi, esta opção executa adicionalmente o SNAT para todas as conexões, reescrevendo oclienteEndereço IP e fazer o servidor pensar que todas as conexões vêm do próprio roteador.
Sem loopback/hairpin, seus clientes podem acessar o servidor, mas não reconhecem as respostas que chegaram do servidor (pois o endereço IP não corresponde mais), portanto, uma conexão nunca poderá ser estabelecida.
Se o seu roteador não tiver essa opção, mas tiver configuração NAT avançada manual, você mesmo poderá criar uma regra NAT semelhante – diga ao roteador para 'mascarar' todas as conexões provenientes da LAN e voltando para a mesma LAN.
(É claro que isso ainda tem a mesma desvantagem de ocultar os endereços IP dos clientes do servidor.)
No entanto, IMHO, a melhor opção (não testada pessoalmente, mas não tenho motivos para acreditar que não deva funcionar) é colocar o servidor em umsub-rede diferentedo resto dos seus dispositivos. Desde que o tráfego de retorno do servidor aos clientes passe pelo gateway, o problema deve ser evitado – mesmo que não haja separação de VLAN e que ambas as sub-redes vivam na mesma Ethernet.
O acima também poderia ser implementado alterando a máscara de sub-rede ou adicionando rotas personalizadas ao servidor.