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

Առնչվող հոդվածներ