عملاء Squid على IPv4 ووجهات IPv6: سياسات منفصلة

من الممكن قبول عميل عبر IPv4 والوصول إلى موقعه المطلوب عبر IPv6. هذان اتصالان منفصلان. وينبغي ألا ترفض سياسة تخص جانب الموقع عملاء IPv4 تلقائيًا.

هذا هو المأزق في الأمثلة التي تجمع بين منع عائلة الوجهة وsrc ipv4: فقائمة ACL للمصدر تغيّر من يُسمح له بالاتصال، لا مجرد اتصالات المواقع المسموح بها.

حدّد القيد المقصود

بالنسبة لإصدارات Squid التي تدعم قوائم IP ACL ذات الصلة، يمكن لقاعدة عائلة الوجهة استخدام dst ipv4 لتحديد وجهات IPv4. ادمج هذه القواعد مع المصادقة وأذونات الوجهة القائمة؛ ولا تضف سماحًا واسعًا بـ IPv6 يتجاوزها.

يميّز مرجع ACL بين أنواع المصدر والوجهة. هذا تقييد وليس خدمة ترجمة تلقائية. فقد يصبح موقع IPv4 فقط غير متاح رغم أن الجهاز يستطيع الوصول إليه عبر IPv4.

كما أن ربط عنوان IPv6 صادر ليس سياسة الإنفاذ كاملة. فاختيار المصدر وعائلات الوجهة المسموح بها وإجابات DNS وإمكانية الوصول الفعلية للشبكة كلها تساهم. قرّر صراحةً ما إذا كان الرجوع إلى IPv4 مقبولًا.

تغيير forwarded_for لا يحل هذه المشكلة. فهو يؤثر في ترويسة HTTP، لا في عائلة عنوان اتصال TCP الخاص بالوكيل. وبالمثل، لا يضمن محلل DNS لنظام IPv6 أن كل اسم يجيب عنه له وجهة IPv6.

تحقق من السلوك الخاص بكل إصدار قبل اعتماد إعداد قديم كبير. على وجه الخصوص: dns_v4_first ليس مفتاح تفضيل عائلة مدعومًا في Squid 5 حتى 7. والسياسة التي يمكنك وصفها بدقة أسهل في التحقق من مجموعة إعدادات IPv6 غير مترابطة.