DNAT прозрачного прокси: почему важен обратный маршрут
Поймите, почему DNAT может доставить запрос отдельному прокси, а ответ обходит шлюз и обрывает соединение.
Перенаправленный SYN может дойти до Squid, пока у клиента всё ещё истекает тайм-аут. В схеме DNAT обратный пакет тоже должен дойти до шлюза, который хранит состояние трансляции.
Рассмотрим эту гипотетическую локальную сеть:
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. Симметричная обратная маршрутизация решает этот механизм тайм-аута, а не всю конфигурацию прозрачного прокси.