Tenho quase certeza de que essa é uma questão de NAT ou de roteamento, mas é uma que continuamente me deixa perplexa.
O hardware é um firewall do Checkpoint Safe @ Office. O modo padrão de operação é que os clientes com fio estão em uma rede 192.168.10.xe os clientes wifi estão em um 192.168.252.xe estão protegidos por firewalls uns dos outros.
Um computador no lado com fio está agindo como um servidor web; servindo o subdomínio 'dev' do meu site de negócios. É acessível de dentro para fora e tudo funciona bem.
No entanto, eu preciso que as redes com fio e Wi-Fi sejam capazes de falar umas com as outras por outros motivos. Para fazer isso; você pode configurar o dispositivo no 'modo de ponte', pelo qual tanto os clientes com fio quanto os Wi-Fi acabam com um endereço IP 192.168.10.xe podem se comunicar livremente.
Infelizmente, alguma coisa sobre como fazer uma ponte nesse sentido prejudica seriamente o desempenho do servidor da Web ao ponto em que ele é inutilizável de dentro da rede - ainda é bom externamente.
Se eu pingar dev.mydomain.com de dentro da rede, ele será resolvido para meu IP público - e todas as minhas tentativas anteriores (e googling) para obter essa configuração funcionando sugerem que, como a solicitação é de saída, voltando para o rede, é "double natting" ou algo similar, fazendo com que o roteador não tenha certeza do que fazer com ele.
Existe uma maneira de resolver isso? Eu encontrei outras pessoas com os mesmos problemas (em dispositivos diferentes também), mas não vi uma solução que funcionasse.
Atualizado em 31/03/2013:
Estou bastante convencido de que o primeiro respondente está no caminho certo ao redirecionar o tráfego usando regras NAT.
Primeiro, achei que o hardware não estava funcionando - mas consegui confirmá-lo redirecionando com êxito todo o tráfego da Web de saída de um dispositivo para o nada, pois funcionou conforme o esperado.
Então, agora a questão é: quais regras NAT precisam entrar em ação para garantir que o tráfego seja uma propriedade roteada para a rede interna?
Eu tentei o que parecia mais óbvio:
QUANDO: A origem é Redes internas , O destino é Meu IP público e o serviço é Servidor da Web
ENTÃO: Não altere a fonte, altere o destino para Meu IP do servidor interno e não altere o serviço.
Isso não funciona, mas eu sinto que deveria.
Atualização nº 2
Estou usando o Microsoft Network Monitor para experimentar e assistir aos pacotes de dados para ver se isso oferece algum insight.
Primeiramente, isso levanta uma questão sobre como a tradução do NAT funciona - porque mesmo com as regras em vigor, vejo a solicitação saindo para dev.mydomain.com e dentro do pacote, o destino ainda é lido como meu IP público . A tradução deve realmente mudar o destino, ou é apenas isso que deve silenciosamente redirecioná-lo?
Em segundo lugar, isso também confirma o problema. Se eu olhar para um site real durante a captura de pacotes, o padrão será bem parecido com o esperado - em primeiro lugar, uma pesquisa de DNS sai e volta, seguida por várias solicitações (presumivelmente relacionadas a todos os arquivos padrão, JS, CSS etc, bem como o próprio HTML), cada um dos quais são respondidos quase imediatamente com pacotes de dados.
Se eu olhar para o meu dev. subdomínio; é muito unilateral. Com ou sem regras de NAT, o que estou vendo é que a solicitação é encerrada e as respostas iniciais voltam, então a solicitação HTTP GET sai e é retornada (e na verdade contém o HTML para a página) - mas nada mais. Um monte de pedidos sai para (eu presumo) os includes, e eles não são respondidos. Eventualmente, eles saem novamente, mas ainda assim nada volta.
Podemos estar vendo um problema do Apache em vez de um problema no roteador?
Atualização nº 3
Então eu criei uma página HTML básica com apenas uma linha de texto e nenhum arquivo incluído e funciona com ou sem regras de NAT, às vezes instantaneamente, às vezes leva alguns segundos - mas sempre funciona. Então, incluí uma imagem da mesma forma que elas são incluídas nas páginas reais, e ela é carregada - mas sempre demorei algumas dezenas de segundos para fazer isso. Dado que uma página real terá um número de pedidos de imagem, bem como outros arquivos, não parece surpreendente que, se eles são tão lentos, isso explica por que a página expira. Eu não estou mais perto de descobrir o porquê.