Která paketová cesta v Linuxu má vynucovat používání proxy?
Umístěte ovládací prvky vynucení síťové proxy na paketovou cestu, kterou mají spravovat, místo abyste filtrovali jen spojení k bráně.
Linuxová brána může spouštět proxy proces a zároveň směrovat provoz kolem něj. To není stejná paketová cesta.
| Spojení | Příslušná místní role |
|---|---|
| Klient dosáhne proxy na bráně | Provoz adresovaný místnímu hostiteli |
| Klient dosáhne jiného hostitele přes bránu | Předávaný provoz |
| Proxy otevře spojení na web | Provoz vytvořený místním procesem |
Netfilter rozlišuje cesty vstupu, předávání a výstupu. Pravidlo řídící přístup k vlastnímu naslouchajícímu proxy na bráně automaticky neomezuje každé směrované spojení přes tento stroj.
Určete, co se má vynucovat
Pokud klienti musí používat schválenou proxy, politika musí řešit i jejich alternativní odchozí trasy vedle povolení zamýšleného naslouchajícího soketu. Povolit spojení ke kterékoli vzdálené službě jen proto, že používá známý port proxy, není totéž jako povolit pouze váš koncový bod proxy.
Vlastní další přístup proxy udržujte odděleně. U Squidu rozlišujte vlastnictví místního socketu od identity uživatele LAN před uplatněním povolení odchozího provozu. Odmítnutí všech užitečných odchozích spojení z proxy by potřebnou cestu znepřístupnilo. Řídicí provoz, překlad jmen a podporované newebové operace také vyžadují záměrné ošetření v politice nasazení.
Rozsah protokolu je důležitý. Pravidlo TCP samo o sobě nepopisuje provoz UDP, včetně QUIC. Zachytávání provozu je jiný návrh; explicitní HTTPS proxy může poskytnout CONNECT bez dešifrování relace webu.
Zmapujte zamýšlená spojení před úpravou sady pravidel. Předvolba prohlížeče vybírá trasu pro zúčastněné klienty. Síťové vynucení rozhoduje, které jiné trasy mohou uspět. Ani jedno by se nemělo odvozovat pouze z funkčního přihlášení k proxy.