Websites im selben Subnetz können den transparenten Proxy eines Gateways umgehen

Internetsurfen erscheint im Protokoll des Gateway-Proxys. Eine Website im Büro-LAN nicht. Bevor Sie den URL-Filter ändern, klären Sie, ob die LAN-Anfrage das Gateway überhaupt erreicht hat.

Bei einem direkt verbundenen IPv4-Ziel kann der Client die Link-Layer-Adresse des Ziels auflösen und im lokalen Segment dorthin senden. Sein Standard-Gateway liegt nicht automatisch auf diesem Pfad. Eine transparente Abfangregel am Gateway kann Pakete nicht umleiten, die das Gateway nie empfängt.

Zwei Hosts im selben On-Link-Subnetz können beispielsweise Datenverkehr über einen Switch austauschen, während der Proxy-Rechner an einem anderen Switch-Port hängt. Allein im selben LAN zu sein macht den Proxy nicht zum Weiterleitungspunkt.

Den beabsichtigten Pfad wählen

Eine explizite Proxy-Einstellung kann die Anfrage der beteiligten Anwendung zum Proxy senden, auch wenn die Zielwebsite lokal ist. Prüfen Sie auch Umgehungsregeln und PAC-Entscheidungen: Sie können für private Namen oder Adressen bewusst DIRECT wählen.

Wenn Abfangen erforderlich ist, muss das Netzwerk den Abfangpunkt tatsächlich in den Pfad legen; auf einem Linux-Gateway sind lokale und weitergeleitete Paketpfade zu unterscheiden. Geroutete Subnetztrennung oder eine bewusst inline geschaltete Bridge können das in geeigneten Designs leisten, ändern aber jeweils Weiterleitungs- und Fehlerverhalten. Eine Bridge anderswo im LAN ist nicht automatisch inline.

Halten Sie die Anforderung an das Anwendungsprotokoll getrennt. Auch nachdem der Verkehr die Box passiert hat, muss der Listener den Abfangmodus unterstützen. Pakete zu verschieben ist keine Erlaubnis, HTTPS zu entschlüsseln, und keine Garantie, dass ein gewöhnlicher SOCKS-Port sie annimmt.

Halten Sie die vom Client gewählte Route, das lokale Segment und das tatsächliche Weiterleitungsgerät fest. Ein fehlendes Proxy-Protokoll kann eine korrekte Beschreibung der Topologie sein und kein Protokollierungsfehler.