PAT não pode acessar o site, mas o NAT pode

Question

Minha pergunta original estava aqui: Os usuários do PAT não podem acessar o site, mas os usuários do NAT podem?

Eu tenho um IP estático agora e apenas assumi que funcionou porque não recebi nenhuma resposta depois que ele foi ativado, mas então me disseram ontem que o cliente ainda não está acessando o site. O cliente não pode alterar suas configurações de rede devido à política corporativa, então estou pensando se há algo que eu possa fazer do meu lado.

Agora usando NAT, tudo se conecta bem. Foi-me dito por seu cara de TI que ele se conecta ao nosso endereço IP estático duas vezes e, em seguida, nosso site tenta se conectar de volta em uma porta aleatória. Em seguida, ele se conecta a dois outros endereços IP pertencentes ao Google (para classificação na Web) e, em seguida, o site carrega.

Ao usar o PAT, eles se conectam ao nosso endereço IP estático duas vezes, mas nada acontece. Quando o nosso site se conecta de volta, o firewall o interrompe.

Não tenho ideia se o site tentando se conectar é normal ou não. Na verdade, nem sei o que está acontecendo. Eu não sou um cara de rede. Eu estou apenas no comando do site.

    

Answer 1

Na sua posição, depois de esclarecer a ideia com ambas as partes, eu faria uma teleconferência envolvendo você, o cara de TI do cliente e a equipe de suporte técnico do seu provedor de hospedagem. Gostaria de encorajar os outros dois a discutir os detalhes e esperar que eles cheguem a uma solução em conjunto ou identifiquem passos concretos para identificar a causa.

OK, se você não conseguir que o cliente fale com o serviço de hospedagem, você terá que entender claramente os detalhes técnicos do problema.

NAT é Network Address Translation, é uma forma muito comum de lidar com a falta de endereços IPV4. Antes do NAT, todos os computadores de todas as organizações conectadas à Internet precisavam ter um endereço IP globalmente exclusivo. O NAT é executado em um roteador para ocultar seus endereços internos por trás de endereços públicos diferentes. Dessa forma, uma empresa com 10.000 computadores pode precisar apenas de um endereço IP público em vez de 10.000. Normalmente, atualmente, endereços internos são escolhidos de um grupo de endereços IPV4 reservados para uso privado.

Assim, meu PC pode ter um endereço interno de 192.168.1.1 e seu servidor da web também pode ter um endereço interno de 192.168.1.1. O NAT possibilita que esses computadores conversem entre si. Seu DNS público para www.example.com não fornece seu endereço interno 192.168.1.1, ele fornece o endereço IP público de seu roteador, digamos 1.2.3.4.

Então, quando eu digito link em um navegador da web, ele envia um pacote TCP parecido com esse

From=192.168.1.1:5432 To=1.2.3.4:80 Payload="GET / HTTP/1.0"

Onde 5432 é uma porta que meu PC escolheu aleatoriamente. Meu roteador muda isso para

From=99.88.77.66:6789 To=1.2.3.4:80 Payload="GET / HTTP/1.0"

Onde 99.88.77.66 é o endereço IPV4 público do meu roteador. Isso é Network Address Translation (NAT). 6789 é um número de porta que ele aloca (pode já estar usando 5432 para a conexão de algum outro cara), isto é a Port Address Translation (PAT). O roteador registra essa tradução na memória para recuperação posterior.

Seu roteador de serviço de hospedagem em 1.2.3.4 recebe o pacote e analisa o número da porta 80 para decidir em qual computador interno deve passar o pacote. Este é o encaminhamento de porta. Então, na LAN do serviço de hospedagem, o pacote é alterado para

From=99.88.77.66:6789 To=192.168.1.1:80 Payload="GET / HTTP/1.0"

O servidor web recebe isso. Ele responde a 99.88.77.66:6789. Quando essa resposta chega ao meu roteador, ele usa o número da porta no endereço de destino 99.88.77.66:6789 para procurar a fonte da conexão original - minha 192.168.1.1:5432. Meu roteador altera o endereço de destino de acordo e encaminha o pacote para minha LAN.

Não consigo ver como isso pode estar dando errado. Mas você pode ver que os números das portas são vitais para que tudo funcione.