Unha pasarela Linux pode executar o proceso do proxy e tamén encamiñar tráfico por fóra del. Non son a mesma ruta de paquetes.

ConexiónFunción local relevante
O cliente chega ao proxy na pasarelaTráfico dirixido ao host local
O cliente chega a outro host a través da pasarelaTráfico reenviado
O proxy abre unha conexión a un sitio webTráfico xerado por un proceso local

Netfilter distingue as rutas de entrada, reenvío e saída. Unha regra que goberna o acceso ao propio receptor do proxy da pasarela non restrinxe automaticamente cada conexión encamiñada por esa máquina.

Defina que se debe aplicar

Se os clientes deben usar o proxy aprobado, a política debe abordar tamén as súas rutas de saída alternativas, ademais de permitir o receptor previsto. Permitir conexións a calquera servizo remoto só porque usa o porto de proxy habitual non é o mesmo que permitir unicamente o seu punto final de proxy.

Manteña separado o acceso propio do proxy cara ao exterior. En Squid, distinga a propiedade do socket local da identidade do usuario da LAN antes de aplicar un permiso de saída. Denegar todas as conexións de saída útiles do proxy deixaría a ruta necesaria sen servizo. O tráfico de xestión, a resolución de nomes e as operacións non web admitidas tamén precisan un tratamento deliberado na política do despregamento.

O alcance do protocolo importa. Unha regra TCP non describe por si soa o tráfico UDP, incluído QUIC. Interceptar tráfico é outro deseño; un proxy HTTPS explícito pode ofrecer CONNECT sen descifrar a sesión do sitio web.

Trace un mapa das conexións previstas antes de editar un conxunto de regras. Unha preferencia do navegador selecciona unha ruta para os clientes participantes. A aplicación na rede decide que outras rutas poden funcionar. Ningunha das dúas debería inferirse só dun inicio de sesión correcto no proxy.

Artigos relacionados