Прозрачен прокси DNAT: защо обратният маршрут е важен
Разберете защо DNAT може да достави заявка до отделен прокси, докато отговорът заобикаля шлюза и прекъсва връзката.
Пренасочен SYN може да пристигне в Squid, докато клиентът все още изчаква. При DNAT настройка обратният пакет също трябва да достигне шлюза, който притежава състоянието на транслацията.
Представете си тази хипотетична LAN:
client 192.168.40.25 → gateway 192.168.40.1
DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directlyКлиентът първоначално се е свързал към адрес на уебсайт. След DNAT проксито вижда източника на клиента и може да използва локалния маршрут на подмрежата, за да отговори директно. Този отговор пропуска обратната транслация на шлюза и може да достигне до клиента от адреса на проксито вместо от очаквания адрес на уебсайта. Шлюзът не може да поправи пакети, които никога не е получил.
| Подход | Последствие |
|---|---|
| Прекарване на отговорите на проксито през транслиращия шлюз | Входящата връзка към проксито може да запази адреса на източника на клиента |
| Прилагане и на подходяща транслация на източника | Проксито отговаря на шлюза като свой партньор, но сега вижда онзи транслиран източник, а не оригиналния клиент |
Не премахвайте SNAT заради по-хубави журнали, без да проверите обратния маршрут. Широкото му прилагане също променя ACL на източника и атрибуцията; приемете този резултат като част от дизайна.
Доверен HTTP хоп може да предаде метаданни за клиента в заглавка за препращане, но NAT не създава тази заглавка и не я превръща в идентичност на TCP партньор. Запазването на източник по връзката към Squid също не го запазва по отделната връзка на Squid към уебсайта.
И накрая, дизайнът на прихващането все още трябва да осигури изискваната от Squid информация за дестинацията. Симетричното обратно маршрутизиране решава този механизъм за изчакване, а не цялата конфигурация на прозрачен прокси.