کلاینت‌های IPv4 در Squid و مقصدهای IPv6: سیاست‌های جداگانه

می‌توان کلاینتی را از طریق IPv4 پذیرفت و به وب‌سایت درخواستی او از طریق IPv6 رسید. این‌ها اتصال‌های جداگانه‌اند. سیاست مربوط به سمت وب‌سایت نباید به‌طور خودکار کلاینت‌های IPv4 را رد کند.

این همان تله در مثال‌هایی است که ممنوعیت خانواده مقصد را با src ipv4 ترکیب می‌کنند: ACL مبدأ تغییر می‌دهد چه کسی می‌تواند متصل شود، نه فقط اینکه کدام اتصال‌های وب‌سایت مجازند.

محدودیت مورد نظر را تعریف کنید

برای نسخه‌های Squid که ACLهای IP مربوط را پشتیبانی می‌کنند، یک قاعده خانواده مقصد می‌تواند از dst ipv4 برای شناسایی مقصدهای IPv4 استفاده کند. چنین قواعدی را با احراز هویت و مجوزهای مقصد موجود یکپارچه کنید؛ مجوز گسترده IPv6 که آن‌ها را دور بزند اضافه نکنید.

مرجع ACL بین انواع مبدأ و مقصد تمایز می‌گذارد. این یک محدودیت است، نه سرویس ترجمه خودکار. یک وب‌سایت فقط IPv4 ممکن است غیرقابل دسترس شود، هرچند دستگاه در غیر این صورت می‌توانست از طریق IPv4 به آن برسد.

اتصال یک نشانی IPv6 خروجی نیز کل سیاست اجرا نیست. انتخاب مبدأ، خانواده‌های مقصد مجاز، پاسخ‌های DNS و دسترس‌پذیری واقعی شبکه همگی سهیم‌اند. صریحاً تصمیم بگیرید که آیا بازگشت به IPv4 قابل قبول است.

تغییر forwarded_for این مشکل را حل نمی‌کند. این بر سرآیند HTTP اثر می‌گذارد، نه بر خانواده نشانی اتصال TCP پروکسی. به همین ترتیب، یک resolver DNS IPv6 تضمین نمی‌کند که هر نامی که پاسخ می‌دهد مقصد IPv6 داشته باشد.

پیش از پذیرش یک پیکربندی قدیمی بزرگ، رفتار مخصوص نسخه را بررسی کنید. به‌ویژه: dns_v4_first در Squid 5 تا 7 یک کلید پشتیبانی‌شده برای ترجیح خانواده نیست. سیاستی که می‌توانید آن را دقیق توصیف کنید، اعتبارسنجی‌اش آسان‌تر از مجموعه‌ای از تنظیمات نامرتبط IPv6 است.