Vilken Linux-paketväg bör framtvinga proxyanvändning?
Placera tvingande kontroller för nätverksproxyn på den paketväg de ska styra, i stället för att bara filtrera anslutningar till gatewayen.
En Linux-gateway kan köra proxyprocessen och samtidigt routa trafik förbi den. Det är inte samma paketväg.
| Anslutning | Relevant lokal roll |
|---|---|
| Klienten når proxyn på gatewayen | Trafik adresserad till den lokala värden |
| Klienten når en annan värd genom gatewayen | Vidarebefordrad trafik |
| Proxyn öppnar en webbplatsanslutning | Trafik som skapas av en lokal process |
Netfilter skiljer på ingångs-, vidarebefordrings- och utgångsvägar. En regel som styr åtkomsten till gatewayens egen proxlyssnare begränsar inte automatiskt varje routad anslutning genom den maskinen.
Definiera vad som ska framtvingas
Om klienterna måste använda den godkända proxyn måste policyn också hantera deras alternativa utgående rutter utöver att tillåta den avsedda lyssnaren. Att tillåta anslutningar till vilken fjärrtjänst som helst bara för att den använder den välbekanta proxyporten är inte samma sak som att bara tillåta din egen proxyändpunkt.
Håll proxyns egen vidare åtkomst åtskild. För Squid, skilj lokal socket-ägarskap från LAN-användaridentitet innan du tillämpar ett utgående tillstånd. Att neka alla nyttiga utgående anslutningar från proxyn skulle göra den nödvändiga vägen otillgänglig. Administrativ trafik, namnhämtning och stödda icke-webboperationer behöver också medveten behandling i distributionens policy.
Protokollomfånget spelar roll. En TCP-regel beskriver inte i sig UDP-trafik, inklusive QUIC. Att fånga trafik är en annan design; en explicit HTTPS-proxy kan tillhandahålla CONNECT utan att dekryptera webbplatssessionen.
Kartlägg de avsedda anslutningarna innan du redigerar en regeluppsättning. En webbläsarinställning väljer en rutt för deltagande klienter. Nätverkstvång avgör vilka andra rutter som kan lyckas. Ingen av dem bör slutas enbart av en fungerande inloggning till proxyn.