بیا لېږل شوی 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 ورته اړتیا لري برابروي. متقارنه بېرته راستنېدونکې لارښوونه دا د وخت د پای مېکانېزم حل کوي، نه ټول شفاف-پروکسي ترتیبات.

اړوندې مقالې