Katera pot paketov v Linuxu naj bi uveljavila uporabo proxyja?
Nadzore uveljavljanja omrežnega proxyja postavite na tisto pot paketov, ki naj bi jo upravljali, namesto da filtrirate le povezave do prehoda.
Prehod Linux lahko izvaja proces proxyja in hkrati usmerja promet mimo njega. To ni ista pot paketov.
| Povezava | Ustrezna lokalna vloga |
|---|---|
| Odjemalec doseže proxy na prehodu | Promet, naslovljen na lokalnega gostitelja |
| Odjemalec doseže drugega gostitelja skozi prehod | Posredovani promet |
| Proxy odpre povezavo do spletnega mesta | Promet, ki ga ustvari lokalni proces |
Netfilter razlikuje vhodno, posredovalno in izhodno pot. Pravilo, ki upravlja dostop do lastnega poslušalca proxyja na prehodu, samodejno ne omejuje vsake usmerjene povezave skozi ta stroj.
Določite, kaj je treba uveljaviti
Če morajo odjemalci uporabljati odobreni proxy, mora politika obravnavati tudi njihove nadomestne izhodne poti poleg dovoljenja za predvidenega poslušalca. Dovoljevanje povezav do katere koli oddaljene storitve samo zato, ker uporablja znana vrata proxyja, ni isto kot dovoljevanje le lastne končne točke proxyja.
Lastni nadaljnji dostop proxyja držite ločeno. Pri Squidu ločite lastništvo lokalnega vtičnika od identitete uporabnika LAN pred uporabo izhodnega dovoljenja. Zavrnitev vseh koristnih izhodnih povezav proxyja bi zahtevano pot naredila nedosegljivo. Upravljalni promet, razreševanje imen in podprte ne-spletne operacije prav tako potrebujejo premišljeno obravnavo v politiki uvajanja.
Obseg protokola je pomemben. Pravilo TCP samo po sebi ne opisuje prometa UDP, vključno s QUIC. Prestrezanje prometa je druga zasnova; izrecni proxy HTTPS lahko ponudi CONNECT brez dešifriranja seje spletnega mesta.
Pred urejanjem nabora pravil preslikajte predvidene povezave. Nastavitev brskalnika izbere pot za sodelujoče odjemalce. Omrežno uveljavljanje odloči, katere druge poti lahko uspejo. Nobenega od tega ne bi smeli sklepati le iz delujoče prijave v proxy.