Прыватны прамы проксі не павінен фізічна стаяць паміж ноўтбукам і маршрутызатарам. Ён можа быць іншай машынай у той жа LAN з адным сеткавым інтэрфейсам.

Ноўтбук падключаецца да адраса проксі і порта праслухоўвання. Працэс проксі адкрывае асобнае злучэнне да сайта або яго бацькі. Адзін і той жа інтэрфейс можа несці абедзве размовы, а табліца маршрутызацыі хоста выбірае наступны крок.

client → proxy listener
proxy → existing router → destination

Гэтага дастаткова для праграмы, якая відавочна выбрала проксі. У Linux такая звычайная схема не патрабуе ўключэння перасылкі IP толькі для перадачы запытаў праграмы.

Шлюз па змаўчанні адказвае на іншае пытанне

Шлюз кліента па змаўчанні апрацоўвае пакеты, якія кліент адпраўляе ў іншыя сеткі. Змена гэтай налады не прымушае браўзер выдаваць запыты HTTP-проксі або весці перамовы SOCKS. Гэтак жа ўвод проксі ў браўзеры не накіроўвае кожную іншую праграму праз гэтую машыну.

Хост можа выконваць абедзве задачы, але тады ў яго дзве канфігурацыі: служба проксі і функцыя маршрутызацыі або міжсеткавага экрана. Больш інтэрфейсаў могуць палегчыць падзел сетак. Гэта выбар тапалогіі, а не перадумова, накладзеная відавочным HTTP-проксі.

Гэтае адрозненне таксама тлумачыць часты няўдалы эксперымент: праўка правілаў перасылкі сервера-проксі не ўплывае на прамое злучэнне кліента, якое ідзе праз іншы маршрутызатар. Пакеты ніколі не перасякалі гэты сервер.

Калі патрабаванне — абавязковае выкарыстанне, вызначце, дзе можна кантраляваць альтэрнатыўны зыходны трафік. Проксі з адным інтэрфейсам можа быць слушнай службай, пакуль асобны шлюз забяспечвае сеткавую палітыку. Размясціце прымус там, дзе пакеты сапраўды праходзяць.

Падобныя артыкулы