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