Linux порта може да го извршува прокси процесот и истовремено да насочува сообраќај покрај него. Тоа не е истата патека на пакети.

ВрскаРелевантна локална улога
Клиентот стигнува до проксито на портатаСообраќај адресиран до локалниот домаќин
Клиентот стигнува до друг домаќин преку портатаПренесен сообраќај
Проксито отвора врска со веб-страницаСообраќај создаден од локален процес

Netfilter разликува влезни, преносни и излезни патеки. Правилото што го управува пристапот до сопствениот прокси-слушач на портата не го ограничува автоматски секоја насочена врска низ таа машина.

Определете што треба да се спроведе

Ако клиентите мора да го користат одобреното прокси, политиката треба да ги опфати и нивните алтернативни излезни правци, покрај дозволувањето на предвидениот слушач. Дозволувањето врски до која било оддалечена услуга само затоа што користи познатиот прокси порт не е исто како дозволување само на вашата прокси крајна точка.

Држете го сопствениот натамошен пристап на проксито одделно. За Squid, разликувајте сопственост на локален сокет од идентитетот на LAN корисникот пред да примените излезна дозвола. Одбивањето на сите корисни излезни врски од проксито би ја направило потребната патека недостапна. Управувачкиот сообраќај, разрешувањето имиња и поддржаните не-веб операции, исто така, бараат намерно третирање во политиката за распоредување.

Опсегот на протоколот е важен. TCP правилото само по себе не опишува UDP сообраќај, вклучително QUIC. Пресретнувањето сообраќај е друг дизајн; експлицитно HTTPS прокси може да обезбеди CONNECT без дешифрирање на сесијата на веб-страницата.

Мапирајте ги предвидените врски пред да уредувате сет правила. Поставката на прелистувачот избира патека за клиентите што учествуваат. Мрежното спроведување одлучува кои други патеки можат да успеат. Ниту едно од двете не треба да се заклучи само од успешна најава на проксито.

Поврзани статии