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. Симетрична зворотна маршрутизація вирішує цей механізм тайм-ауту, а не всю конфігурацію прозорого проксі.