Kuris Linux paketų kelias turėtų priversti naudoti proxy?
Įdėkite tinklo proxy priverstinės kontrolės priemones į tą paketų kelią, kurį jos turi valdyti, o ne filtruokite tik jungtis į tinklų sietuvą.
Linux tinklų sietuvas gali vykdyti proxy procesą ir tuo pačiu maršrutizuoti srautą aplink jį. Tai ne tas pats paketų kelias.
| Jungtis | Atitinkamas vietinis vaidmuo |
|---|---|
| Klientas pasiekia proxy sietuve | Srautas, adresuotas vietiniam mazgui |
| Klientas pasiekia kitą mazgą per sietuvą | Persiųstas srautas |
| Proxy atidaro svetainės jungtį | Vietinio proceso generuojamas srautas |
Netfilter skiria įvesties, persiuntimo ir išvesties kelius. Taisyklė, valdanti prieigą prie paties sietuvo proxy klausytojo, automatiškai neapriboja kiekvienos maršrutizuotos jungties per tą mašiną.
Apibrėžkite, ką reikia priversti
Jei klientai privalo naudoti patvirtintą proxy, politika turi apimti ir jų alternatyvius išeinančius maršrutus, be numatyto klausytojo leidimo. Leisti jungtis į bet kurią nuotolinę paslaugą vien todėl, kad ji naudoja įprastą proxy prievadą, nėra tas pats, kas leisti tik savo proxy galinį tašką.
Laikykite paties proxy tolesnę prieigą atskirai. Su Squid atskirkite vietinio lizdo nuosavybę nuo LAN vartotojo tapatybės prieš taikydami išėjimo leidimą. Visų naudingų išeinančių jungčių iš proxy atmetimas padarytų reikiamą kelią neprieinamą. Valdymo srautas, vardų sprendimas ir palaikomos ne žiniatinklio operacijos taip pat reikalauja sąmoningo apdorojimo diegimo politikoje.
Protokolo apimtis svarbi. TCP taisyklė pati savaime neaprašo UDP srauto, įskaitant QUIC. Srauto perėmimas yra kita konstrukcija; aiškus HTTPS proxy gali suteikti CONNECT neiššifravus svetainės sesijos.
Sudarykite numatomų jungčių žemėlapį prieš redaguodami taisyklių rinkinį. Naršyklės nuostata parenka maršrutą dalyvaujantiems klientams. Tinklo priverstinė kontrolė nusprendžia, kurie kiti maršrutai gali pavykti. Nė vieno iš jų nereikėtų spręsti vien iš sėkmingo prisijungimo prie proxy.