DNAT de proxy transparente: por que a rota de retorno importa
Entenda por que o DNAT pode entregar um pedido a um proxy separado enquanto a resposta contorna a gateway e quebra a ligação.
Um SYN redirecionado pode chegar ao Squid enquanto o cliente ainda expira. Numa configuração DNAT, o pacote de retorno também tem de chegar à gateway que detém o estado de tradução.
Considere esta LAN hipotética:
client 192.168.40.25 → gateway 192.168.40.1
DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directlyO cliente ligou-se originalmente a um endereço de site. Após DNAT, o proxy vê a origem do cliente e pode usar a rota da sub-rede local para responder diretamente. Essa resposta falha a tradução inversa da gateway e pode chegar ao cliente a partir do endereço do proxy em vez do endereço de site esperado. A gateway não pode reparar pacotes que nunca recebe.
| Abordagem | Consequência |
|---|---|
| Encaminhar as respostas do proxy pela gateway que traduz | A ligação de entrada para o proxy pode conservar o endereço de origem do cliente |
| Aplicar também a tradução de origem adequada | O proxy responde à gateway como seu par, mas agora vê essa origem traduzida em vez do cliente original |
Não remova SNAT para obter registos mais bonitos sem verificar a rota de retorno. Aplicá-lo amplamente também altera as ACL de origem e a atribuição; aceite essa consequência como parte do projeto.
Um salto HTTP de confiança pode transportar metadados do cliente num cabeçalho de encaminhamento, mas o NAT não cria esse cabeçalho nem o transforma em identidade de par TCP. Preservar uma origem na ligação ao Squid também não a preserva na ligação separada do Squid ao site.
Por fim, o desenho de interceção ainda tem de fornecer as informações de destino exigidas pelo Squid. O encaminhamento simétrico de retorno resolve este mecanismo de expiração, não toda a configuração de proxy transparente.