Які шлях пакетаў Linux павінен забяспечваць выкарыстанне проксі?
Размяшчайце сродкі кантролю проксі на тым шляху пакетаў, якім яны павінны кіраваць, а не фільтруйце толькі злучэнні да шлюза.
Шлюз Linux можа запускаць працэс проксі і адначасова маршрутызаваць трафік паўз яго. Гэта не адзін і той жа шлях пакетаў.
| Злучэнне | Адпаведная лакальная роля |
|---|---|
| Кліент дасягае проксі на шлюзе | Трафік, адрасаваны лакальнаму хосту |
| Кліент дасягае іншага хоста праз шлюз | Перанакіраваны трафік |
| Проксі адкрывае злучэнне з сайтам | Трафік, створаны лакальным працэсам |
Netfilter адрознівае шляхі ўваходу, перанакіравання і выхаду. Правіла, якое кіруе доступам да ўласнага слухача проксі на шлюзе, не абмяжоўвае аўтаматычна кожнае маршрутызаванае злучэнне праз гэтую машыну.
Вызначце, што трэба забяспечыць
Калі кліенты абавязаны выкарыстоўваць зацверджаны проксі, палітыка павінна ўлічваць іх альтэрнатыўныя знешнія маршруты, а не толькі дазваляць патрэбны слухач. Дазваляць злучэнні да любой аддаленай службы толькі таму, што яна выкарыстоўвае знаёмы порт проксі, не тое самае, што дазваляць толькі вашу канчатковую кропку проксі.
Трымайце ўласны далейшы доступ проксі асобна. Для Squid адрознівайце ўласніцтва лакальнага сокета ад ідэнтычнасці карыстальніка LAN перад прымяненнем дазволу на выхад. Забарона ўсіх карысных знешніх злучэнняў проксі зрабіла б патрэбны шлях недаступным. Кіраванне, развязанне імёнаў і падтрыманыя невяб-аперацыі таксама патрабуюць наўмыснага ўліку ў палітыцы разгортвання.
Ахоп пратаколаў важны. Правіла TCP само па сабе не апісвае трафік UDP, уключаючы QUIC. Перахоп трафіку — іншы дызайн; явны проксі HTTPS можа даць CONNECT без расшыфроўкі сеансу сайта.
Складзіце карту патрэбных злучэнняў перад рэдагаваннем набору правілаў. Перавага браўзера выбірае маршрут для кліентаў-удзельнікаў. Сеткавае прымушэнне вырашае, якія іншыя маршруты могуць працаваць. Ні тое, ні другое не варта выводзіць толькі з працоўнага ўваходу ў проксі.