Webbplatser i samma subnät kan kringgå en gateways transparenta proxy
Förklarar varför trafik i samma subnät kan kringgå en gateways avlyssningsregel medan internetförfrågningar syns i dess logg.
Internetbläddring syns i gateway-proxyns logg. En webbplats på kontorets LAN gör det inte. Innan du ändrar URL-filtret, avgör om LAN-förfrågan överhuvudtaget nådde gatewayen.
För ett direkt anslutet IPv4-mål kan klienten lösa målets länklageradress och skicka till den på det lokala segmentet. Dess standardgateway ligger inte automatiskt på den vägen. En transparent avlyssningsregel på gatewayen kan inte omdirigera paket som gatewayen aldrig tar emot.
Till exempel kan två värdar i samma on-link-subnät utbyta trafik via en switch medan proxymaskinen är ansluten till en annan switchport. Bara att befinna sig på det LAN:et gör inte proxyn till vidarebefordringspunkten.
Välj den avsedda vägen
En explicit proxyinställning kan skicka den deltagande applikationens förfrågan till proxyn även när målwebbplatsen är lokal. Kontrollera även kringgångsregler och PAC-beslut: de kan medvetet välja DIRECT för privata namn eller adresser.
Om avlyssning krävs måste nätverket faktiskt placera avlyssningspunkten på vägen; på en Linux-gateway skiljer du på lokala och vidarebefordrade paketvägar. Rutad subnätsuppdelning eller en medvetet inline-kopplad brygga kan göra det i lämpliga konstruktioner, men var och en ändrar vidarebefordrings- och felbeteende. En brygga någon annanstans på LAN:et är inte automatiskt inline.
Håll kravet på applikationsprotokollet åtskilt. Även efter att trafiken passerat enheten måste lyssnaren stödja avlyssningsläget. Att flytta paketen är inte tillstånd att dekryptera HTTPS och inte heller en garanti för att en vanlig SOCKS-port kan ta emot dem.
Registrera den väg klienten valde, det lokala segmentet och den faktiska vidarebefordringsenheten. En saknad proxylogg kan vara en korrekt beskrivning av topologin och inte ett loggningsfel.