Websteder på samme subnet kan omgå en gateways transparente proxy
Forklarer hvorfor trafik på samme subnet kan omgå en gateway-regel for aflytning, mens internetanmodninger vises i dens log.
Internetbrowsing vises i gateway-proxyens log. Et websted på kontorets LAN gør ikke. Før du ændrer URL-filteret, skal du fastslå, om LAN-anmodningen overhovedet nåede gatewayen.
For en direkte tilsluttet IPv4-destination kan klienten opløse destinationens linklag-adresse og sende til den på det lokale segment. Dens standardgateway er ikke automatisk på den vej. En transparent aflytningsregel på gatewayen kan ikke omdirigere pakker, som gatewayen aldrig modtager.
For eksempel kan to værter i samme on-link-subnet udveksle trafik gennem en switch, mens proxy-maskinen er tilsluttet en anden switch-port. Blot at være på det LAN gør ikke proxyen til videresendelsespunktet.
Vælg den tilsigtede vej
En eksplicit proxyindstilling kan sende den deltagende applikations anmodning til proxyen, selv når målwebstedet er lokalt. Kontroller også omgåelsesregler og PAC-beslutninger: de kan bevidst vælge DIRECT for private navne eller adresser.
Hvis aflytning er påkrævet, skal netværket faktisk placere aflytningspunktet på vejen; på en Linux-gateway skal du skelne mellem lokale og videresendte pakkeveje. Ruteret subnet-adskillelse eller en bevidst inline-bro kan gøre det i passende design, men hver ændrer videresendelses- og fejladfærd. En bro andre steder på LAN'et er ikke automatisk inline.
Hold kravet til applikationsprotokollen adskilt. Selv efter at trafikken har passeret boksen, skal lytteren understøtte aflytningstilstanden. At flytte pakkerne er ikke tilladelse til at dekryptere HTTPS og heller ikke en garanti for, at en almindelig SOCKS-port kan acceptere dem.
Registrér klientens valgte rute, det lokale segment og den faktiske videresendelsesenhed. En manglende proxy-log kan være en korrekt beskrivelse af topologien snarere end en logningsfejl.