د Squid SO_ORIGINAL_DST تېروتنې لوستل
مخکې لدې چې په Squid کې د اصلي منزل د لټون ناکامي وڅېړئ، وګورئ چې په څرګنده توګه تنظیم شوي کلاينټ د مداخلې اورېدونکي ته رسېدلی که نه.
NF getsockopt(SO_ORIGINAL_DST) د اصلي منزل لټون ته اشاره کوي. د مداخلې په ترتیباتو کې، Squid باید بیا ومومي چې لېږدول شوې اړیکه په اصل کې چېرته روانه وه.
په څرګنده توګه تنظیم شوی براوزر خپلې غوښتنې په قصد پروکسي ته لېږي. هغه اړیکه یوازې د دې لپاره د NAT مداخلې تاریخ نه ترلاسه کوي چې د Squid اورېدونکي د پورت ترڅنګ intercept لیکل شوی دی.
نو دا ناسم والی کېدای شي مخکې لدې چې د منزل سند اړوند شي، ناکام شي.
له دې پیل وکړئ چې اړیکه څنګه راغله
- که اپلیکیشن پروکسي پته تنظیم کړې وي، هغه عادي مخته لېږدونکی پروکسي اورېدونکی وټاکئ چې باید یې وکاروي.
- که یوه دروازه هغه ترافیک چې بل ډول مستقیم وي بېرته لېږي، وګورئ چې هغه خپلې موخې مداخلې اورېدونکي ته رسېږي او ملاتړ شوی NAT ډیزاین اړین منزل معلومات ساتي.
- که دواړه حالتونه شتون ولري، وګورئ چې ناکام کلاينټ په حقیقت کې کومې پتې او پورت سره اړیکه ټینګه کړې.
د Squid http_port اسناد توپیر روښانه کوي: د حالت بیرغ پرېښودل مخته لېږدونکي پروکسي حالت ټاکي؛ intercept په IP طبقه کې د NAT مداخلې تمه لري.
بیا د لېږد امنیت جلا وګورئ. یو HTTP پروکسي کولای شي HTTPS د CONNECT له لارې ولېږدوي. پروکسي ته TLS اړیکه د سم اورېدونکي او کلاينټ تنظیم غوښتنه کوي. د منزل ترافیک ډیکریپټ کول بیا یو بل اختیاري وړتیا ده.
یو زوړ “HTTPS حل” مه کاپی کوئ چې یوازې د دې لپاره چې د منزل URL په HTTPS پیل کېږي، د سندونو جوړول فعالوي. لومړی د کلاينټ او اورېدونکي ترمنځ همغږي سم کړئ. که له هغې وروسته ریښتینی TLS خطا پاتې شي، هغه به د څېړنې لپاره ګټوره خطا وي.