ترحيل IPv6: المكدس المزدوج، النفق، وNAT64

لماذا الترحيل الآن#

استنفاد عناوين IPv4 حقيقي. استنفدت جميع سجلات الإنترنت الإقليمية مجمعاتها. تدفع المؤسسات أسعاراً متميزة لكتل IPv4 صغيرة بينما تبقى مساحة عناوين IPv6 مجانية. بخلاف العنونة، يزيل IPv6 تعقيد NAT ويبسط التوجيه ويصبح بشكل متزايد متطلباً تنافسياً حيث تعطي المنصات الرئيسية الأولوية لحركة مرور IPv6.

الحالة التجارية واضحة: مستخدموك بالفعل على شبكات IPv6 (شركات الاتصالات المحمولة، مزودي السحابة، مزودي خدمة الإنترنت الحديثين)، لكنك قد لا تكون مستعداً لخدمتهم بكفاءة. تتطلب Apple دعم IPv6 لتطبيقات iOS. تصنف Google المواقع الممكّنة لـ IPv6 أعلى قليلاً. تنمو حركة مرور IPv6 بنسبة 25-30٪ سنوياً.

ثلاث نهج للترحيل#

ترحيل IPv6 ليس مقاساً واحداً يناسب الجميع. لديك ثلاث استراتيجيات أساسية:

تستخدم معظم الشبكات الإنتاجية المكدس المزدوج. يعمل النفق كجسر مؤقت. تتعامل الترجمة مع الحالات الحدية حيث يجب على البروتوكولات التشغيل البيني.

نشر المكدس المزدوج#

المكدس المزدوج يعني أن كل جهاز شبكة يتحدث كلا البروتوكولين. الخادم لديه عنوان IPv4 (192.0.2.10) وعنوان IPv6 (2001:db8::10). تختار التطبيقات البروتوكول الذي تستخدمه بناءً على الوجهة والتفضيل.

┌─────────────────────────────────┐
│      طبقة التطبيق          │
├─────────────────────────────────┤
│  TCP/UDP (لا يعتمد على البروتوكول)    │
├──────────────┬──────────────────┤
│  مكدس IPv4  │   مكدس IPv6     │
│  192.0.2.10  │  2001:db8::10    │
└──────────────┴──────────────────┘
         │              │
    شبكة IPv4   شبكة IPv6

المزايا#

المكدس المزدوج لا يخلق مشاكل توافق. يستمر عملاء IPv4 فقط في العمل بشكل طبيعي. يحصل عملاء IPv6 على اتصال أصلي. تهاجر بوتيرتك الخاصة دون انقطاع الخدمة أو التنسيق مع أطراف خارجية.

تبسيط معمارية الشبكة مع مرور الوقت. مع نمو اعتماد IPv6، يمكنك إهمال خدمات IPv4 تدريجياً. لا يوم علم. لا عطلة نهاية أسبوع للترحيل. فقط تقدم ثابت.

خطوات التنفيذ#

1. التحقق من دعم الأجهزة

تحقق من أن الموجهات والمحولات وجدران الحماية تدعم IPv6. معظم معدات المؤسسات من العقد الأخير تدعمه، لكن تحقق من إصدارات البرامج الثابتة. بعض الأجهزة القديمة تحتاج إلى تحديثات.

2. صمم مخطط العنونة الخاص بك

اطلب بادئة /48 أو أكبر من مزود خدمة الإنترنت الخاص بك (أو RIR للمؤسسات الكبيرة). خطط لهيكل شبكتك الفرعية. على عكس التقسيم الصارم لـ IPv4، استخدم /64 لجميع الشبكات المحلية - حجم الشبكة الفرعية القياسي الذي يمكّن SLAAC.

مثال تخصيص لـ /48:

2001:db8:0100::/48  - مستلم من ISP
2001:db8:0100:0001::/64  - خوادم مركز البيانات
2001:db8:0100:0002::/64  - شبكة المكتب المحلية
2001:db8:0100:0003::/64  - شبكة الضيوف
2001:db8:0100:0010::/64  - DMZ

3. تكوين البنية التحتية للشبكة

مكّن توجيه IPv6 على موجهات الحدود. كوّن إعلانات الموجه (SLAAC) أو DHCPv6 لتعيين العناوين. حدّث قواعد جدار الحماية - هذا حرج وغالباً ما يُنسى.

4. النشر على الخوادم

ابدأ بالخدمات منخفضة المخاطر. أضف سجلات DNS من نوع AAAA. اختبر بدقة قبل الانتقال إلى خدمات الإنتاج. راقب أنماط حركة مرور IPv4 وIPv6.

5. تمكين اتصال العميل

تتعامل أنظمة التشغيل الحديثة مع المكدس المزدوج تلقائياً. يكوّن SLAAC العناوين بدون DHCP. يتلقى العملاء عناوين IPv4 (عبر DHCP) وIPv6 (عبر SLAAC) ويختارون بشكل مناسب.

Happy Eyeballs: اختيار البروتوكول#

يحدد RFC 8305 "Happy Eyeballs"، الخوارزمية التي تستخدمها الأنظمة الحديثة للاختيار بين IPv4 وIPv6. فهم هذا يساعد في تصحيح مشاكل الاتصال.

العملية:

1. يعيد بحث DNS كلاً من سجلات A (IPv4) وAAAA (IPv6)
2. يحاول النظام اتصال IPv6 أولاً
3. بعد 50-250 مللي ثانية (خاص بالتنفيذ)، يبدأ محاولة IPv4 بالتوازي
4. أول اتصال ناجح يفوز
5. النتيجة مخزنة للاتصالات اللاحقة بنفس المضيف

هذا يضمن حصول المستخدمين على أفضل اتصال متاح دون تأخير ملحوظ. يحصل IPv6 على الأفضلية، لكن IPv4 يبقى احتياطياً.

يمكنك اختبار هذا السلوك مع أداة ping IPv6. قارن أوقات الاستجابة للوجهات ذات المكدس المزدوج.

آليات النفق#

يلف النفق حزم IPv6 داخل IPv4، مما يسمح باتصال IPv6 عبر البنية التحتية IPv4 فقط. فكر فيه كحل مؤقت، وليس حلاً دائماً.

الأصلي: [رأس IPv6 | البيانات]
منفق: [رأس IPv4 | رأس IPv6 | البيانات]

6in4: أنفاق يدوية#

أبسط طريقة للنفق. كوّن نقطتي نهاية يدوياً، وتتدفق حزم IPv6 عبر شبكات IPv4 كبروتوكول 41 (ليس UDP أو TCP - بروتوكول IP الخام 41).

مثال تكوين Linux:

# إنشاء واجهة النفق
ip tunnel add he-ipv6 mode sit remote 209.51.161.14 local 203.0.113.50 ttl 255
 
# تعيين عنوان IPv6 (من وسيط النفق)
ip addr add 2001:470:1f0a:1ab::2/64 dev he-ipv6
 
# تعيين الوصلة لأعلى
ip link set he-ipv6 up
 
# إضافة مسار IPv6 افتراضي
ip route add ::/0 dev he-ipv6
 
# التحقق
ping6 google.com

نقاط رئيسية:

• يجب أن يمر البروتوكول 41 عبر جدران الحماية/NAT (غالباً محظور)
• نقاط نهاية النفق تحتاج عناوين IPv4 ثابتة
• Hurricane Electric ووسطاء أنفاق آخرون يوفرون نقاط نهاية مجانية
• يضيف ~10-30 مللي ثانية زمن انتقال حسب موقع وسيط النفق

6rd: النشر السريع لـ ISP#

يسمح 6rd لمزودي خدمة الإنترنت بتوفير IPv6 للعملاء عبر البنية التحتية الحالية لـ IPv4. يشغل مزود الخدمة خوادم ترحيل، وموجهات العملاء تنفق حركة مرور IPv6 تلقائياً.

على عكس 6to4، يستخدم 6rd بوادئ خاصة بمزود الخدمة وترحيلات مسيطر عليها من مزود الخدمة، مما يجعله أكثر موثوقية وأماناً. لن تكوّن هذا يدوياً - إنه مزوَّد تلقائياً إذا كان مزود خدمة الإنترنت الخاص بك يدعمه.

DS-Lite: IPv4 عبر IPv6#

يعكس DS-Lite السيناريو النموذجي: يوفر اتصال IPv4 عبر شبكة IPv6 فقط. يستخدمه مزودو خدمة الإنترنت الذين ينتقلون إلى البنية التحتية IPv6 فقط مع الحفاظ على خدمة IPv4.

العميل ----[IPv4-في-IPv6]----> AFTR لمزود الخدمة ----[IPv4]----> الإنترنت

معدات العميل (عنصر B4) تنفق IPv4 داخل IPv6 إلى AFTR (موجه انتقال عائلة العناوين) لمزود الخدمة، الذي يؤدي NAT44 قبل إعادة التوجيه إلى إنترنت IPv4.

عادةً لا يكوّن المستخدمون النهائيون DS-Lite - إنه مُدار من قبل مزود الخدمة.

تقنيات الترجمة#

تحوّل الترجمة الحزم بين IPv6 وIPv4 في طبقة الشبكة. يمكّن هذا من الاتصال عندما يكون أحد الجانبين IPv6 فقط والآخر IPv4 فقط.

NAT64 مع DNS64#

يترجم NAT64 حزم IPv6 إلى IPv4 والعكس. مجتمعاً مع DNS64، يوفر وصولاً شفافاً لخدمات IPv4 فقط من شبكات IPv6 فقط.

كيف يعمل:

1. عميل IPv6 فقط يستعلم DNS عن ipv4only.example.com
2. خادم DNS64 يرى فقط سجل A (IPv4)، لا سجل AAAA (IPv6)
3. يصنع DNS64 سجل AAAA باستخدام بادئة NAT64: 64:ff9b::198.51.100.5
4. يرسل العميل حزمة إلى عنوان IPv6 المصنع
5. بوابة NAT64 تترجم إلى IPv4 وتعيد التوجيه
6. حركة المرور العائدة مترجمة إلى IPv6

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│ عميل IPv6 │         │   NAT64     │         │ خادم IPv4 │
│             │─────────│   بوابة   │─────────│             │
│2001:db8::1  │  IPv6   │  + DNS64    │  IPv4   │198.51.100.5 │
└─────────────┘         └─────────────┘         └─────────────┘

بادئة NAT64 المعروفة: 64:ff9b::/96 (RFC 6052)

يتطلب NAT64 ترجمة ذات حالة - تحتفظ البوابة بحالة الجلسة مثل NAT44 التقليدي. يقدم هذا نفس مخاوف التوسع مثل NAT في IPv4.

464XLAT: تمكين تطبيقات IPv4#

يمدد 464XLAT NAT64 بإضافة ترجمة جانب العميل (CLAT)، مما يسمح لتطبيقات IPv4 فقط بالعمل على شبكات IPv6 فقط.

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ تطبيق IPv4     │      │              │      │ خادم IPv4  │
│              │      │ شبكة IPv6    │      │              │
│ 192.0.0.1    │      │ فقط      │      │ 198.51.100.5 │
└──────┬───────┘      └──────────────┘      └──────────────┘
       │                                             │
    CLAT (جهاز)                              PLAT (مزود الخدمة)
    NAT46                                       NAT64

الشبكات المحمولة تستخدم 464XLAT بشكل مكثف. يشغل هاتفك مكدس IPv6 فقط، لكن تطبيقات IPv4 فقط القديمة لا تزال تعمل بشفافية. كل من Android وiOS يدعمان CLAT أصلياً.

اختيار استراتيجيتك#

إطار القرار بناءً على خصائص الشبكة:

هل لديك IPv6 أصلي من مزود الخدمة؟
   │
   ├─ نعم ──> انشر المكدس المزدوج (موصى به)
   │          1. مكّن IPv6 على موجه الحدود
   │          2. كوّن SLAAC/DHCPv6
   │          3. حدّث قواعد جدار الحماية
   │          4. أضف سجلات AAAA إلى DNS
   │
   └─ لا ──> تحتاج IPv6 فوراً؟
              │
              ├─ نعم ──> استخدم وسيط النفق
              │          (Hurricane Electric، إلخ)
              │
              └─ لا ──> اطلب IPv6 من مزود الخدمة
                        أو خطط لجدول زمني للترحيل

مصفوفة اختيار الاستراتيجية#

المخاطر الشائعة#

1. تكوين جدار الحماية غير المكتمل#

غالباً ما تتجاوز حركة مرور IPv6 قواعد جدار حماية IPv4. تكوّن فرق الأمان سياسات IPv4 واسعة النطاق لكن تنسى IPv6 تماماً. النتيجة: اتصال IPv6 غير مصفى.

الحل: طبّق سياسات أمان مكافئة لكلا البروتوكولين. إذا كنت تحظر المنفذ 23 (telnet) على IPv4، احظره على IPv6. استخدم الفحص ذو الحالة لكليهما.

2. تكوينات DNS خاطئة#

نشر سجلات AAAA بدون اتصال IPv6 عامل يكسر الوصول لعملاء IPv6 الممكّنين. يساعد Happy Eyeballs، لكنه يسبب تأخيرات والتراجع إلى IPv4.

الحل: انشر فقط سجلات AAAA بعد التحقق من أن اتصال IPv6 يعمل. راقب أنماط استعلام A وAAAA. كوّن DNS العكسي (سجلات PTR) لعناوين IPv6.

3. مشاكل توافق التطبيق#

التطبيقات التي تشفر افتراضات IPv4 تفشل مع IPv6:

• تخزين عناوين IP في أعداد صحيحة 32 بت
• أنماط regex تطابق تنسيق IPv4 فقط
• عدم وضع عناوين IPv6 بين أقواس في URLs: http://[2001:db8::1]:8080/
• الربط بـ 0.0.0.0 بدلاً من :: (حرف بدل IPv6)

الحل: اختبر التطبيقات بدقة مع اتصال IPv6 فقط. استخدم بيئات اختبار مكدس مزدوج. راجع الكود لافتراضات IPv4.

4. نقاط عمياء في المراقبة#

غالباً ما تتتبع مراقبة الشبكة مقاييس IPv4 لكن تتجاهل IPv6. لن تلاحظ إذا تدهور اتصال IPv6 أو فشل تماماً.

الحل:

• راقب حركة مرور IPv6 وIPv4 بشكل منفصل
• أنشئ فحوصات صحة خاصة بـ IPv6
• تتبع توزيع تفضيل البروتوكول (ما نسبة حركة المرور تستخدم IPv6)
• أنذر على مشاكل توفر IPv6

استخدم حاسبة شبكة IPv6 الفرعية لتخطيط العنونة وأداة ping للتحقق من الاتصال.

ابدأ بسيط#

ابدأ بالمكدس المزدوج على أنظمة غير حرجة. خادم اختبار، بيئة تطوير، أو أداة داخلية. تحقق من عمل اتصال IPv6. أضف سجلات AAAA. راقب حركة المرور.

بمجرد الراحة، توسع لخدمات الإنتاج. معظم البنية التحتية الحديثة تدعم IPv6 مع تكوين ضئيل. الترحيل التقني مباشر - التغيير التنظيمي والاختبار الشامل يأخذان وقتاً أطول.

يعمل النفق كجسر مؤقت إذا لم تتمكن من الحصول على IPv6 أصلي فوراً. لكن اضغط على مزود خدمة الإنترنت الخاص بك للدعم الأصلي. تتعامل الترجمة مع الحالات الحدية لكن لا ينبغي أن تكون استراتيجيتك الأساسية.

يستمر اعتماد IPv6 في التسارع. البدء الآن، حتى بشكل تدريجي، يضع شبكتك للمستقبل بينما يتدافع منافسوك للحاق لاحقاً.

مقالات ذات صلة#

• تمكين IPv6 - دليل عملي لتمكين IPv6 على أجهزتك وموجهاتك
• IPv6 في السحابة - تعلم كيفية نشر IPv6 على AWS وAzure وGoogle Cloud