Nettsurfing vises i loggen til gateway-proxyen. Et nettsted på kontor-LAN-et gjør det ikke. Før du endrer URL-filteret, må du finne ut om LAN-forespørselen i det hele tatt nådde gatewayen.

For en direkte tilkoblet IPv4-destinasjon kan klienten slå opp destinasjonens koblingslagsadresse og sende til den på det lokale segmentet. Standardgatewayen ligger ikke automatisk på den veien. En transparent avlyttingsregel på gatewayen kan ikke omdirigere pakker som gatewayen aldri mottar.

To verter i samme on-link-subnett kan for eksempel utveksle trafikk via en svitsj mens proxymaskinen er koblet til en annen svitsjport. Bare det å være på det LAN-et gjør ikke proxyen til videresendingspunktet.

Velg den tiltenkte veien

En eksplisitt proxyinnstilling kan sende forespørselen fra den deltakende applikasjonen til proxyen selv når mål-nettstedet er lokalt. Sjekk også omgåelsesregler og PAC-avgjørelser: de kan bevisst velge DIRECT for private navn eller adresser.

Hvis avlytting er nødvendig, må nettverket faktisk plassere avlyttingspunktet i veien; på en Linux-gateway skiller du mellom lokale og videresendte pakkeveier. Rutet subnettdeling eller en bevisst inline-bro kan gjøre det i egnede design, men hver endrer videresendings- og feilatferd. En bro andre steder på LAN-et er ikke automatisk inline.

Hold kravet til applikasjonsprotokollen adskilt. Selv etter at trafikken har passert boksen, må lytteren støtte avlyttingsmodusen. Å flytte pakkene er ikke tillatelse til å dekryptere HTTPS og heller ikke en garanti for at en vanlig SOCKS-port kan ta imot dem.

Registrer ruten klienten valgte, det lokale segmentet og den faktiske videresendingsenheten. En manglende proxy-logg kan være en riktig beskrivelse av topologien og ikke en loggfeil.

Relaterte artikler