Nettlesing vises i gateway-proxyens logg. Et nettsted på kontorets LAN gjør det ikke. Før du endrer URL-filteret, må du fastslå om LAN-forespørselen i det hele tatt nådde gatewayen.

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

For eksempel kan to verter i samme on-link-subnett utveksle trafikk gjennom en svitsj mens proxy-maskinen er koblet til en annen svitsjport. Bare å være på det LAN-et gjør ikke proxyen til videresendingspunktet.

Velg den tiltenkte veien

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

Hvis avlytting er påkrevd, 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 atskilt. 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 korrekt beskrivelse av topologien snarere enn en loggfeil.

Relaterte artikler