Թափանցիկ պրոքսի 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-ի պահանջած նպատակակետի տեղեկատվությունը։ Համաչափ վերադարձի երթուղավորումը լուծում է այս ժամկետի մեխանիզմը, ոչ թե ամբողջ թափանցիկ պրոքսիի կարգավորումը։