خواندن خطای SO_ORIGINAL_DST در Squid

NF getsockopt(SO_ORIGINAL_DST) به جست‌وجوی مقصد اصلی اشاره دارد. در چیدمان رهگیری، Squid باید بازیابی کند که اتصال تغییرمسیرداده‌شده در ابتدا به کجا می‌رفت.

مرورگری که صریحاً پیکربندی شده باشد درخواست‌هایش را عمداً به پروکسی می‌فرستد. آن اتصال تنها به این دلیل که intercept کنار درگاه شنوندهٔ Squid نوشته شده است، تاریخچهٔ رهگیری NAT پیدا نمی‌کند.

بنابراین این ناسازگاری می‌تواند پیش از آنکه گواهی مقصد اهمیت پیدا کند شکست بخورد.

با این شروع کنید که اتصال چگونه رسید

• اگر برنامه نشانی پروکسی پیکربندی‌شده دارد، شنوندهٔ معمول پروکسی پیش‌رو را که باید استفاده کند مشخص کنید.
• اگر دروازه‌ای ترافیکی را که در غیر این صورت مستقیم است تغییرمسیر می‌دهد، بررسی کنید که به شنوندهٔ رهگیری موردنظر برسد و طرح NAT پشتیبانی‌شده اطلاعات مقصد لازم را حفظ کند.
• اگر هر دو حالت وجود دارد، بررسی کنید کارخواهِ ناکام در واقع به کدام نشانی و درگاه متصل شده است.

مستندات http_port در Squid تفاوت را روشن می‌کند: حذف پرچم حالت، حالت پروکسی پیش‌رو را انتخاب می‌کند؛ intercept رهگیری NAT در لایهٔ IP را انتظار دارد.

سپس امنیت انتقال را جداگانه بررسی کنید. یک پروکسی HTTP می‌تواند HTTPS را با CONNECT حمل کند. اتصال TLS به پروکسی به شنونده و پیکربندی کارخواه سازگار نیاز دارد. رمزگشایی ترافیک مقصد هم قابلیت اختیاری دیگری است.

“راه‌حل HTTPS” قدیمی‌ای را که فقط به این دلیل که نشانی مقصد با HTTPS شروع می‌شود تولید گواهی را روشن می‌کند کپی نکنید. نخست هماهنگی میان کارخواه و شنونده را درست کنید. اگر پس از آن خطای واقعی TLS باقی ماند، خطای مفیدتری برای بررسی خواهد بود.