Sites na mesma sub-rede podem contornar o proxy transparente de um gateway

A navegação na Internet aparece no registo do proxy do gateway. Um site na LAN do escritório não. Antes de alterar o filtro de URL, determine se o pedido da LAN chegou alguma vez ao gateway.

Para um destino IPv4 ligado diretamente, o cliente pode resolver o endereço de camada de ligação do destino e enviar-lhe no segmento local. O gateway predefinido não está automaticamente nesse caminho. Uma regra de interceptação transparente no gateway não pode redirecionar pacotes que o gateway nunca recebe.

Por exemplo, dois anfitriões na mesma sub-rede ligada diretamente podem trocar tráfego através de um comutador enquanto a máquina proxy está ligada a outra porta do comutador. Estar apenas nessa LAN não torna o proxy o ponto de reencaminhamento.

Escolha o caminho pretendido

Uma configuração de proxy explícita pode enviar o pedido da aplicação participante para o proxy mesmo quando o site de destino é local. Verifique também as regras de contorno e as decisões PAC: podem escolher deliberadamente DIRECT para nomes ou endereços privados.

Se a interceptação for necessária, a rede tem de colocar realmente o ponto de interceptação no caminho; num gateway Linux, distinga os caminhos de pacotes locais e reencaminhados. A separação de sub-redes por encaminhamento ou uma ponte deliberadamente em linha podem fazê-lo em conceções adequadas, mas cada uma altera o comportamento de reencaminhamento e de falha. Uma ponte noutro local da LAN não está automaticamente em linha.

Mantenha o requisito do protocolo de aplicação separado. Mesmo depois de o tráfego atravessar o equipamento, o ouvinte tem de suportar o modo de interceptação. Mover os pacotes não é autorização para desencriptar HTTPS nem garantia de que uma porta SOCKS comum os possa aceitar.

Registe o caminho escolhido pelo cliente, o segmento local e o dispositivo de reencaminhamento real. A ausência de registo do proxy pode ser uma descrição correta da topologia e não uma falha de registo.