Watter Linux-pakketpad moet proxygebruik afdwing?
Plaas netwerkproxy-afdwingbeheer op die pakketpad wat dit moet beheer, in plaas daarvan om slegs verbindings na die poort self te filter.
'n Linux-poort kan die proxyproses laat loop en ook verkeer verby dit routeer. Dit is nie dieselfde pakketpad nie.
| Verbinding | Relevante plaaslike rol |
|---|---|
| Kliënt bereik die proxy op die poort | Verkeer gerig na die plaaslike gasheer |
| Kliënt bereik 'n ander gasheer deur die poort | Geforwarde verkeer |
| Die proxy open 'n webwerfverbinding | Verkeer wat deur 'n plaaslike proses gegenereer word |
Netfilter onderskei inset-, forward- en uitsetpaaie. 'n Reël wat toegang tot die poort se eie proxyluisteraar beheer, beperk nie outomaties elke geroteerde verbinding deur daardie masjien nie.
Bepaal wat afgedwing moet word
As kliënte die goedgekeurde proxy moet gebruik, moet die beleid hul alternatiewe uitgaande roetes aanspreek sowel as die beoogde luisteraar toelaat. Om verbindings na enige afgeleë diens toe te laat bloot omdat dit die bekende proxyport gebruik, is nie dieselfde as om slegs jou proxy-eindpunt toe te laat nie.
Hou die proxy se eie verdere toegang apart. Vir Squid, onderskei plaaslike socket-eienaarskap van LAN-gebruikersidentiteit voordat jy 'n uitgangstoelating toepas. Om alle nuttige uitgaande verbindings van die proxy te weier, sou die vereiste pad onbeskikbaar maak. Bestuursverkeer, naamoplossing en ondersteunde nie-web-bewerkings het ook doelbewuste behandeling in die ontplooiing se beleid nodig.
Protokolomvang maak saak. 'n TCP-reël beskryf nie op sigself UDP-verkeer nie, insluitend QUIC. Om verkeer te onderskep is weer 'n ander ontwerp; 'n eksplisiete HTTPS-proxy kan CONNECT verskaf sonder om die webwerfsessie te dekripteer.
Karteer die beoogde verbindings voordat jy 'n reëlstel wysig. 'n Blaaier-voorkeur kies 'n roete vir deelnemende kliënte. Netwerkafdwinging besluit watter ander roetes kan slaag. Nie een moet bloot uit 'n werkende aanmelding by die proxy afgelei word nie.