NAT64 و DNS64: ربط شبكات IPv6 فقط بـ IPv4

مستقبل IPv6 فقط#

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

يحدث هذا الانتقال بالفعل في الشبكات المحمولة. تُشغل شركات الاتصالات الكبرى مكدسات IPv6 فقط على الهواتف الذكية. أزالت T-Mobile و AT&T و Verizon IPv4 من شبكات LTE/5G منذ سنوات. هاتفك لديه عنوان IPv6. عندما تصل إلى موقع ويب IPv4 فقط، يتعامل NAT64 و DNS64 مع الترجمة بشفافية.

تتبع شبكات المؤسسات نفس المسار. IPv6 فقط يُقلل التعقيد، ويلغي مخاوف استنزاف عنوان IPv4، ويُبسط التوجيه. لكن القضاء الكامل على IPv4 ليس واقعيًا بعد — تبقى العديد من الخدمات IPv4 فقط. يُسد NAT64 و DNS64 هذه الفجوة، مما يسمح لشبكات IPv6 فقط بالوصول إلى إنترنت IPv4.

كيف يعمل NAT64 و DNS64 معًا#

يُجري NAT64 ترجمة البروتوكول في طبقة الشبكة. يُصنع DNS64 عناوين IPv6 تُحفز هذه الترجمة. يعملان كزوج — DNS64 بدون NAT64 عديم الفائدة، و NAT64 بدون DNS64 يتطلب تكوينًا يدويًا.

تدفق الترجمة#

إليك ما يحدث عندما يصل عميل IPv6 فقط إلى خدمة IPv4 فقط:

┌─────────────────────────────────────────────────────────────────┐
│ 1. يستعلم العميل DNS عن www.ipv4only.example.com              │
│    نوع الاستعلام: AAAA (عنوان IPv6)                           │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. خادم DNS64 يستعلم DNS المنبع                                │
│    يتلقى: سجل A → 198.51.100.10 (IPv4 فقط)                    │
│    لا يوجد سجل AAAA                                            │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. DNS64 يُصنع سجل AAAA                                        │
│    يجمع بادئة NAT64 + عنوان IPv4                              │
│    النتيجة: 64:ff9b::198.51.100.10                            │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. يتلقى العميل عنوان IPv6 المُصنع                           │
│    يُرسل حزمًا إلى 64:ff9b::198.51.100.10                     │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. بوابة NAT64 تعترض الحزم                                    │
│    تتعرف على بادئة 64:ff9b::/96                              │
│    تستخرج IPv4 المضمن: 198.51.100.10                         │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. NAT64 تترجم IPv6 → IPv4                                     │
│    تُغير رؤوس الحزم                                           │
│    تُجري NAT ذي الحالة (تتبع الجلسة)                          │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 7. حزمة IPv4 مُرسلة إلى الوجهة                                │
│    المصدر: عنوان IPv4 لبوابة NAT64                            │
│    الوجهة: 198.51.100.10                                       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 8. حركة المرور العائدة مُترجمة مرة أخرى                       │
│    NAT64 تبحث عن الجلسة                                        │
│    تترجم IPv4 → IPv6                                           │
│    تُعيد التوجيه إلى العميل                                   │
└─────────────────────────────────────────────────────────────────┘

يرى العميل IPv6 فقط. تر� خدمة IPv4 فقط IPv4 فقط. يتعامل NAT64 و DNS64 مع الترجمة بشكل غير مرئي.

البادئة المعروفة جيدًا#

البادئة القياسية لـ NAT64 هي 64:ff9b::/96 (RFC 6052). تُخبر هذه البادئة المعروفة جيدًا الجميع «عناوين IPv4 مضمنة هنا».

يعمل تضمين عنوان IPv4 هكذا:

عنوان IPv4:    198.51.100.10
في hex:          C6.33.64.0A
بادئة NAT64:    64:ff9b::
مجتمع:        64:ff9b::c633:640a
موسع:        64:ff9b::198.51.100.10 (تدوين شائع)

آخر 32 بت من عنوان IPv6 تحتوي على عنوان IPv4. لا ترى التطبيقات هذا أبدًا — إنه داخلي بحت للبنية التحتية للترجمة.

يمكنك استخدام بادئات مخصصة بدلاً من البادئة المعروفة جيدًا. الخيارات الشائعة تتضمن بادئات خاصة بالمنظمة مثل 2001:db8:64::/96. هذا يسمح بهندسة حركة المرور (توجيه حركة مرور NAT64 بشكل مختلف) ولكنه يتطلب تغييرات تكوين DNS64.

DNS64 بعمق#

DNS64 هو خادم DNS مع منطق ترجمة خاص. يعترض استعلامات AAAA ويُصنع استجابات عندما توجد سجلات A فقط.

تدفق منطق DNS64#

استعلام AAAA لـ example.com
    ↓
استعلم المنبع عن AAAA
    ↓
سجل AAAA موجود؟ ─ نعم ─→ أرجع سجل AAAA (IPv6 أصلي)
    │
    لا
    ↓
استعلم المنبع عن A
    ↓
سجل A موجود؟ ─ لا ─→ أرجع NXDOMAIN
    │
    نعم
    ↓
اصنع AAAA = بادئة + IPv4
    ↓
أرجع AAAA المُصنع

السلوكيات الرئيسية:

• IPv6 الأصلي مفضل: إذا كان AAAA موجودًا، يُرجعه DNS64 دون تغيير. لا تصنيع. NAT64 غير متورط.
• احتياطي IPv4 فقط: يحدث التصنيع فقط عندما لا يوجد AAAA
• الحفاظ على TTL لذاكرة التخزين المؤقت: تُرث السجلات المُصنعة TTL من سجل A
• تعقيد DNSSEC: يكسر التصنيع التحقق من DNSSEC (المزيد عن هذا لاحقًا)

أمثلة تكوين DNS64#

BIND 9:

options {
    // ... خيارات أخرى ...
    dns64 64:ff9b::/96 {
        clients { any; };
        mapped { !192.168.0.0/16; !10.0.0.0/8; any; };
        exclude { 64:ff9b::/96; ::ffff:0:0/96; };
        suffix ::;
    };
};

المعلمات:

• clients: العملاء الذين يحصلون على DNS64 (عادةً any)
• mapped: عناوين IPv4 التي ستُترجم (استبعد عناوين RFC 1918 الخاصة)
• exclude: نطاقات IPv6 التي لن يتم تصنيعها أبدًا
• suffix: يُخصص مكان تضمين IPv4 في العنوان (متقدم)

Unbound:

server:
    module-config: "dns64 validator iterator"
 
dns64:
    dns64-prefix: 64:ff9b::/96
    dns64-synthall: no

• dns64-synthall: ما إذا كان سيُصنع حتى عندما يوجد AAAA (عادةً لا)

PowerDNS Recursor:

# في recursor.conf
enable-dns64: yes
dns64-prefix: 64:ff9b::/96

اكتشاف DNS64#

يحتاج العملاء إلى معرفة أي خادم DNS يوفر DNS64. عادةً ما يتم تكوينه عبر:

إعلانات الموجه (SLAAC):

# radvd.conf
interface eth0 {
    RDNSS 2001:db8::53 {
        AdvRDNSSLifetime 300;
    };
};

DHCPv6:

option dhcp6.name-servers 2001:db8::53;

تقبل أنظمة التشغيل الحديثة خوادم DNS من كل من RA و DHCPv6.

NAT64 بعمق#

NAT64 هي ترجمة ذات حالة — تحتفظ بحالة الجلسة مثل NAT44 التقليدي. يحصل كل اتصال عميل على ربط في جدول حالة بوابة NAT64.

الترجمة ذات الحالة#

تتبع بوابة NAT64:

• عنوان ومنفذ مصدر IPv6
• عنوان ومنفذ وجهة IPv4
• عنوان ومنفذ مصدر IPv4 المُترجم
• البروتوكول (TCP/UDP/ICMP)
• مؤقتات الجلسة

إدخال جدول الجلسة:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
جانب عميل IPv6          │  جانب خادم IPv4
━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━
2001:db8:100::45:1234     │  203.0.113.5:6789
  (عميل IPv6:منفذ)      │    (NAT IPv4:منفذ)
                          │        ↕
                          │  198.51.100.10:80
                          │  (وجهة IPv4:منفذ)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
البروتوكول: TCP
الحالة: ESTABLISHED
المهلة: 7440 ثانية

عندما تصل حركة مرور عائدة إلى 203.0.113.5:6789، تبحث NAT64 عن الجلسة وتترجم مرة أخرى إلى 2001:db8:100::45:1234.

ترجمة البروتوكول#

تترجم NAT64 أكثر من العناوين — تُحول بين تنسيقات حزم IPv4 و IPv6:

حزمة IPv6:

[ رأس IPv6 | رأس TCP/UDP/ICMP | الحمولة ]

مُترجمة إلى IPv4:

[ رأس IPv4 | رأس TCP/UDP/ICMP | الحمولة ]

تتضمن الترجمة:

• TTL/Hop Limit: مُنقص ومنسوخ
• التجزئة: تجزئة IPv6 → تجزئة IPv4 (مع اعتبارات MTU)
• ICMP: ICMPv6 → ICMPv4 (تعيين نوع الرسالة)
• Checksums: إعادة حساب لرؤوس البروتوكول الجديدة

مجموعة العناوين#

تحتاج NAT64 إلى عناوين IPv4 للاتصالات الصادرة. تستخدم النشر الصغيرة عنوان IPv4 واحد مع التحميل الزائد للمنفذ (مثل موجهات المنزل). تستخدم النشر الأكبر مجموعات.

# صغيرة: IPv4 واحد
مجموعة NAT64: 203.0.113.5/32
الحد الأقصى للعملاء: ~65,000 جلسة متزامنة
 
# كبيرة: مجموعة IPv4
مجموعة NAT64: 203.0.113.0/24
الحد الأقصى للعملاء: ~16 مليون جلسة متزامنة

تنطبق مخاوف استنزاف العناوين — تواجه NAT64 نفس قيود المنفذ مثل NAT44.

خيارات التنفيذ#

توجد تطبيقات برامج NAT64 متعددة، من خفيفة الوزن إلى درجة الناقل.

TAYGA: مساحة مستخدم خفيفة الوزن#

TAYGA هو daemon NAT64 بسيط في مساحة المستخدم لـ Linux. جيد للنشر الصغيرة والاختبار.

التثبيت:

apt-get install tayga
 
# إنشاء واجهة TUN
ip tuntap add name nat64 mode tun
ip link set nat64 up
ip addr add 192.168.255.1/24 dev nat64
ip addr add 2001:db8:ffff::1/96 dev nat64

التكوين (/etc/tayga.conf):

tun-device nat64
ipv4-addr 192.168.255.1
ipv6-addr 2001:db8:ffff::1
prefix 64:ff9b::/96
dynamic-pool 192.168.255.0/24
data-dir /var/lib/tayga

البدء والتوجيه:

systemctl start tayga
 
# توجيه بادئة NAT64 من خلال TAYGA
ip route add 64:ff9b::/96 dev nat64
ip route add 192.168.255.0/24 dev nat64
 
# تمكين إعادة التوجيه
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1

الإيجابيات: بسيط، خفيف الوزن، سهل الإعداد السلبيات: أداء محدود (مساحة المستخدم)، لا تجميع، ميزات قليلة

Jool: وحدة نواة#

يُطبق Jool NAT64 كوحدة نواة Linux، مما يوفر أداءً أفضل.

التثبيت:

# إضافة المستودع (Debian/Ubuntu)
apt-get install linux-headers-$(uname -r)
apt-get install jool-dkms jool-tools
 
# تحميل الوحدة
modprobe jool

التكوين:

# إنشاء مثيل NAT64
jool instance add "default" --netfilter --pool6 64:ff9b::/96
 
# إضافة مجموعة عناوين IPv4
jool -i "default" pool4 add --tcp 203.0.113.5 1024-65535
jool -i "default" pool4 add --udp 203.0.113.5 1024-65535
jool -i "default" pool4 add --icmp 203.0.113.5 1024-65535
 
# تمكين
jool -i "default" global update enabled true

التوجيه:

ip route add 64:ff9b::/96 via 2001:db8::1

الإيجابيات: أداء عالٍ (مساحة النواة)، تطوير نشط، وثائق جيدة السلبيات: تعقيد وحدة النواة، مشاكل توافق عرضية مع تحديثات النواة

NAT64 مزود السحابة#

توفر منصات السحابة الرئيسية NAT64 مُدار:

AWS (NAT64 عبر Egress-Only Internet Gateway):

لا توفر AWS NAT64 أصلي، ولكن يمكنك نشر Jool أو TAYGA على حالات EC2. توجد بعض AMIs من طرف ثالث.

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

Google Cloud Platform:

توفر GCP Cloud NAT مع دعم NAT64 (بيتا):

# إنشاء شبكة فرعية NAT64
gcloud compute networks subnets create nat64-subnet \
  --network=my-network \
  --region=us-central1 \
  --range=10.0.0.0/24 \
  --enable-nat64
 
# تكوين Cloud NAT
gcloud compute routers nats create my-nat64 \
  --router=my-router \
  --region=us-central1 \
  --enable-nat64 \
  --nat64-prefix=64:ff9b::/96

Azure:

يدعم Azure IPv6 ولكنه لا يوفر NAT64 مُدار. نشر خاصتك باستخدام Linux VMs مع Jool أو TAYGA.

الإيجابيات (الخدمات المُدارة): لا صيانة، قابلة للتطوير، مراقبة متكاملة السلبيات: خاص بالسحابة، مرونة تكوين أقل، تكلفة محتملة

NAT64 درجة الناقل#

تستخدم نشر الاتصالات و ISP الكبيرة حلولاً تجارية:

• Cisco ASR مع CGv6
• Juniper MX Series مع خدمة NAT64
• A10 Thunder CGN
• F5 BIG-IP مع وحدة CGNAT

تتعامل هذه مع ملايين الجلسات المتزامنة مع توافر عالٍ، وتسجيل للامتثال القانوني، وسياسات حركة مرور متطورة.

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

يعمل NAT64/DNS64 بشفافية للتطبيقات مضاعفة المكدس. لكن بعض التطبيقات تُشفر عناوين IPv4 بشكل ثابت أو تستخدم بروتوكولات لا يمكن لـ DNS64 اعتراضها. يحل 464XLAT هذا.

كيف يعمل 464XLAT#

يضيف 464XLAT ترجمة جانب العميل (CLAT) قبل NAT64 (PLAT):

┌─────────────┐      ┌──────────────┐      ┌──────────────┐
│  تطبيق IPv4 │      │              │      │              │
│             │      │ شبكة IPv6    │      │ خادم IPv4    │
│ 192.0.0.10  │      │ فقط          │      │198.51.100.10 │
└──────┬──────┘      └──────────────┘      └──────────────┘
       │                                            │
   CLAT (محلي)                                PLAT (ISP)
   NAT46: IPv4→IPv6                           NAT64: IPv6→IPv4
       │                                            │
       └──────────── شبكة IPv6 ─────────────────┘

الخطوات:

1. يُرسل التطبيق حزمة IPv4 إلى 192.0.0.10 (واجهة افتراضية CLAT)
2. CLAT تترجم IPv4 → IPv6 باستخدام بادئة محلية (مثل، 64:ff9b::c000:0a)
3. حزمة IPv6 تعبر الشبكة إلى PLAT (بوابة NAT64)
4. PLAT تترجم IPv6 → IPv4
5. حزمة IPv4 تصل إلى الوجهة

يرى التطبيق اتصال IPv4 محلي. الشبكة IPv6 فقط. تحدث الترجمة في كلا الطرفين.

464XLAT على المحمول#

تُطبق Android و iOS CLAT تلقائيًا عند الاتصال بشبكات IPv6 فقط مع NAT64:

Android CLAT:

• يكتشف NAT64 بالاستعلام عن ipv4only.arpa (يُرجع AAAA المُصنع إذا كان NAT64 موجودًا)
• ينشئ واجهة clat4 مع عناوين 192.0.0.0/29
• يُوجه حركة مرور تطبيق IPv4 من خلال CLAT
• يترجم إلى IPv6 باستخدام بادئة NAT64 المكتشفة

iOS CLAT:

• آلية كشف مماثلة
• شفاف للتطبيقات والمستخدمين

هذا هو السبب في أن تطبيقات IPv4 فقط تعمل على T-Mobile و AT&T وشبكات محمولة IPv6 فقط أخرى.

Linux 464XLAT مع Clatd#

لأنظمة Linux على شبكات IPv6 فقط:

# تثبيت
apt-get install clatd
 
# تكوين /etc/clatd.conf
clat-v4-addr=192.0.0.1
clat-v6-addr=2001:db8:1234:5678::1
plat-prefix=64:ff9b::/96
 
# بدء
systemctl enable --now clatd
 
# تحقق
ip addr show clat
ping -4 8.8.8.8  # يجب أن يعمل حتى على شبكة IPv6 فقط

استخدم 464XLAT عندما:

• لديك تطبيقات IPv4 فقط لا يمكن تحديثها
• تتجاوز التطبيقات DNS (IPs مُشفرة ثابتًا)
• تحتاج إلى دعم IPv4 شفاف على بنية تحتية IPv6 فقط

سيناريوهات النشر#

يناسب NAT64/DNS64 حالات استخدام محددة. فهم متى تنشره يتجنب الأخطاء المعمارية.

السيناريو 1: الشبكات المحمولة#

الوضع: ناقل 5G/LTE بملايين المشتركين، عناوين IPv4 محدودة

الحل: شبكة IPv6 فقط مع NAT64/DNS64 + 464XLAT

الفوائد:

• يُلغي IPv4 من شبكة الراديو والنواة
• توجيه مُبسط (بروتوكول واحد)
• يتطور دون قيود عنوان IPv4
• يدعم التطبيقات القديمة عبر 464XLAT

التنفيذ:

• PLAT (NAT64) في نواة الناقل
• DNS64 على خوادم DNS للناقل
• CLAT على الأجهزة المحمولة (تلقائي)

هذه هي البنية المحمولة المهيمنة عالميًا.

السيناريو 2: شبكات المؤسسات IPv6 فقط#

الوضع: مركز بيانات جديد، تريد IPv6 فقط لتجنب تعقيد مضاعف المكدس

الحل: شبكة داخلية IPv6 فقط، NAT64 للوصول إلى خدمات IPv4 الخارجية

الفوائد:

• عناوين مُبسطة (لا DHCP IPv4، NAT، إلخ)
• بنية حديثة
• يُجبر التطبيقات على دعم IPv6

التحديات:

• بعض تطبيقات المؤسسات تبقى IPv4 فقط
• واجهات الإدارة غالبًا IPv4 فقط
• توافق الأجهزة القديمة

التوصية: مضاعف المكدس عادةً أسهل للمؤسسة. IPv6 فقط منطقي للبيئات الجديدة والأصلية السحابية.

السيناريو 3: الخدمات الصغيرة الأصلية السحابية#

الوضع: عنقود Kubernetes، الخدمات تتواصل داخليًا عبر IPv6

الحل: عنقود IPv6 فقط مع NAT64 لتبعيات API IPv4 الخارجية

الفوائد:

• شبكة خدمة مُبسطة
• لا استنزاف عنوان IPv4 في العناقيد الكبيرة
• IPv6 أصلي لشبكات الحاويات

التنفيذ:

• وضع Kubernetes IPv6 فقط
• بوابة NAT64 للخروج
• DNS64 عبر DNS العنقود (CoreDNS يدعمه)

# CoreDNS ConfigMap مع DNS64
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        dns64 64:ff9b::/96
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

حالة استخدام متزايدة مع أصبح IPv6 قياسيًا في تنسيق الحاويات.

القيود والمشاكل#

NAT64/DNS64 ليس مثاليًا. فهم القيود يمنع فشل النشر.

1. يكسر DNSSEC#

يُصنع DNS64 سجلات AAAA غير موجودة في المنطقة الموثوقة. توقيعات DNSSEC لا تغطي هذه السجلات الاصطناعية، لذا يفشل التحقق.

الحلول:

• تعطيل التحقق من DNSSEC على محلل DNS64 (غير مثالي)
• استخدم DNS64 يدعم معالجة DNSSEC لـ RFC 6147 (تطبيق محدود)
• اقبل أن مجالات IPv4 فقط الموقعة بـ DNSSEC لن تتحقق

هذا هو أكبر تحدٍ تشغيلي مع DNS64.

2. عناوين IPv4 مُشفرة ثابتًا#

التطبيقات بـ IPs مُشفرة ثابتًا تتجاوز DNS، لذا لا يرى DNS64 الاستعلام أبدًا. لا يمكن لـ NAT64 المساعدة لأنها تتعرف فقط على بادئة NAT64.

الحلول:

• نشر 464XLAT (يتعامل مع جميع حركة مرور IPv4)
• تحديث التطبيقات لاستخدام أسماء DNS
• استخدام بوابات طبقة التطبيق (نادر، معقد)

3. IPv4 الحرفية في URLs#

تطبيقات الويب تمرر http://192.0.2.1/api في URLs أو التكوين. لا تُجري المتصفحات عمليات بحث DNS لـ IP الحرفية، لذا لا يُصنع DNS64.

الحلول:

• استخدام أسماء المضيفين بدلاً من IP الحرفية
• وكلاء طبقة التطبيق التي تُعيد كتابة الحرفية
• 464XLAT

4. FTP و ALGs الأخرى#

البروتوكولات التي تُضمن عناوين IP في بيانات التطبيق (وضع FTP النشط، SIP، إلخ) غالبًا ما تفشل من خلال NAT64. العنوان في الحمولة لا يطابق رأس الحزمة.

الحل:

• استخدام وضع FTP السلبي (لا عناوين مُضمنة)
• نشر NAT64 واعية بالبروتوكول مع دعم ALG (معقدة)
• الانتقال إلى بروتوكولات حديثة لا تُضمن IPs

5. مشاكل التجزئة#

يمكن أن تسبب اختلافات MTU للمسار بين IPv4 و IPv6 مشاكل تجزئة. IPv6 لديه MTU أدنى 1280 بايت؛ يسمح IPv4 بـ 576 بايت.

الحل:

• تأكد من أن MTU متسق عبر البنية التحتية
• مكّن اكتشاف MTU للمسار (PMTUD)
• راقب وأرسل تنبيهات على رسائل ICMP Packet Too Big

6. DNS العكسي#

سجلات PTR لعناوين مُترجمة NAT64 لن توجد. قد تفشل التطبيقات التي تتطلب DNS عكسي (بعض خوادم البريد، ضوابط الوصول).

الحل:

• إنشاء سجلات PTR لمجموعة NAT64
• تكوين الخدمات لعدم طلب DNS العكسي
• استخدام IPv6 أصليًا حيث يهم DNS العكسي

المراقبة واستكشاف الأخطاء وإصلاحها#

يضيف NAT64/DNS64 طبقات ترجمة يمكن أن تُخفي المشاكل. المراقبة المناسبة ضرورية.

التحقق من DNS64#

اختبار ما إذا كان DNS64 يعمل:

# استعلام لمجال IPv4 فقط معروف
dig AAAA ipv4.google.com @2001:db8::53
 
# يجب أن يُرجع AAAA المُصنع مع بادئة NAT64
# مثال: 64:ff9b::8.8.8.8

إذا لم تحصل على سجل AAAA، فـ DNS64 لا يعمل.

اختبار اتصال NAT64#

استخدم المجال الاختباري الخاص ipv4only.arpa:

# من عميل IPv6 فقط
ping6 ipv4only.arpa
 
# يجب أن تتلقى رد عبر NAT64
# المجال يحل إلى 192.0.0.170، مُصنع إلى 64:ff9b::192.0.0.170

إذا فشل ping، فبوابة NAT64 غير قابلة للوصول أو لا تترجم.

فحص جدول الجلسة#

تحقق من حالة جلسة NAT64:

Jool:

jool -i "default" session display
 
# يُظهر الجلسات النشطة
# ابحث عن: عميل IPv6، IPv4 المُترجم، الوجهة

TAYGA:

cat /var/lib/tayga/dynamic.map
 
# يُظهر تعيينات العناوين

عدد الجلسات العالي يشير إلى استخدام كثيف أو مشاكل محتملة (تسريبات الاتصال).

تحليل حركة المرور#

التقاط حركة المرور قبل وبعد الترجمة:

# التقاط حركة مرور IPv6 إلى بادئة NAT64
tcpdump -i eth0 -n 'ip6 and dst net 64:ff9b::/96'
 
# التقاط حركة مرور IPv4 المُترجمة
tcpdump -i eth1 -n 'ip and src 203.0.113.5'
 
# قارن للتحقق من الترجمة

ابحث عن:

• حزم تصل إلى NAT64 ولكن لا تُترجم
• تحدث الترجمة ولكن الحزم لا تُعيد التوجيه
• توجيه غير متماثل (حركة مرور العودة لا تصل إلى NAT64)

المشاكل الشائعة#

الأعراض: DNS64 يُرجع AAAA المُصنع، ولكن الاتصال يفشل

الأسباب:

• بوابة NAT64 غير قابلة للوصول
• جدار حماية يحظر بادئة NAT64
• مشكلة توجيه (حزم إلى بادئة NAT64 تذهب في الاتجاه الخاطئ)

التصحيح:

traceroute6 64:ff9b::198.51.100.1
# يجب أن توجه إلى بوابة NAT64

الأعراض: بعض المواقع تعمل، والبعض الآخر لا

الأسباب:

• المواقع بـ IPv6 الأصلي تعمل (لا NAT64 متورط)
• مواقع IPv4 فقط بمتطلبات خاصة تفشل
• مشاكل تجزئة أو MTU

التصحيح:

# اختبار مع MTUs مختلفة
ping6 -M do -s 1400 64:ff9b::198.51.100.1

الأعراض: اتصالات بطيئة أو انتهاء المهلة

الأسباب:

• بوابة NAT64 مُحملة زائدة
• جدول الجلسة ممتلئ
• توجيه غير متماثل

التصحيح:

# تحقق من CPU وعدد الجلسات لـ NAT64
# راقب وقت إنشاء الاتصال
time curl -6 http://ipv4-only-site.example.com

اعتبارات الأمان#

تُدخل NAT64 آثارًا أمنية تتجاوز NAT النموذجي.

مسح مساحة العنوان#

تجعل بادئة NAT64 عناوين IPv4 قابلة للتنبؤ في IPv6. يمكن للمهاجمين مسح 64:ff9b::/96 لاكتشاف خدمات IPv4 التي تصل إليها.

التخفيف: استخدم بادئات NAT64 خاصة بالشبكة بدلاً من البادئة المعروفة جيدًا، مما يحد من التعرض.

تجاوز ضوابط الوصول#

قد لا تأخذ ضوابط وصول IPv4 (قواعد جدار حماية، ACLs) في الاعتبار حركة مرور NAT64 المُترجمة القادمة من مصادر IPv6 غير متوقعة.

التخفيف: طبّق سياسات الأمان على بوابة NAT64، وليس فقط نقاط النهاية.

NAT64 كمُضخم للهجوم#

يمكن للمهاجمين على شبكات IPv6 فقط استخدام NAT64 لإطلاق هجمات ضد أهداف IPv4، مما قد يتجاوز تحديد معدل IPv4 أو القوائم السوداء.

التخفيف:

• حدد معدل جلسات NAT64 لكل مصدر
• سجّل جميع ترجمات NAT64 للتحقيق في الإساءة
• طبّق نفس سياسات الأمان مثل NAT IPv4

تسميم ذاكرة DNS64 المؤقتة#

إذا تم اختراق خادم DNS64، يمكن للمهاجمين تصنيع سجلات AAAA ضارة تُشير إلى عناوين IPv4 يتحكم فيها المهاجم عبر NAT64.

التخفيف:

• تأمين خوادم DNS64 (نفس أي بنية تحتية DNS)
• استخدم DNSSEC حيث يكون ممكنًا (على الرغم من مشاكل التوافق)
• راقب DNS64 لأنماط تصنيع غير عادية

متى تستخدم NAT64/DNS64 مقابل مضاعف المكدس#

إطار القرار:

┌─────────────────────────────────────────────────┐
│ هل يمكنك تشغيل مضاعف المكدس؟                   │
└─────────────────────┬───────────────────────────┘
                      │
          ┌───────────┴──────────┐
          │                      │
         نعم                    لا
          │                      │
          ▼                      ▼
   ┌─────────────┐     ┌─────────────────────┐
   │ استخدم      │     │ لماذا لا؟           │
   │ مضاعف      │     │                     │
   │ المكدس     │     │ • استنزاف IPv4      │
   │             │     │ • تبسيط معماري      │
   │ (أبسط،     │     │ • شبكة محمولة       │
   │  مشاكل     │     │ • أصلي سحابي        │
   │  أقل)      │     │                     │
   └─────────────┘     └──────────┬──────────┘
                                  │
                                  ▼
                         ┌────────────────────┐
                         │ استخدم NAT64/DNS64 │
                         │                    │
                         │ أضف 464XLAT إذا:   │
                         │ • تطبيقات IPv4 فقط│
                         │ • IPs مُشفرة ثابتًا│
                         └────────────────────┘

يكون NAT64/DNS64 منطقيًا عندما:

• استنزاف عنوان IPv4 قيد حقيقي
• تبني بنية تحتية جديدة (جديدة)
• شبكة محمولة أو بنية أصلية سحابية
• الفوائد التشغيلية لمكدس واحد تفوق تعقيد الترجمة

يكون مضاعف المكدس منطقيًا عندما:

• عناوين IPv4 متاحة
• بنية تحتية قديمة وحديثة مختلطة
• التوافق هو الأولوية العليا
• دراية الفريق بمضاعف المكدس

مستقبل NAT64#

ينمو اعتماد NAT64 مع أصبحت شبكات IPv6 فقط أكثر شيوعًا:

الاتجاهات:

• شركات الاتصالات المحمولة نُشرت بشكل شبه عالمي
• مزودو السحابة يضيفون خيارات NAT64 مُدارة
• IoT والحوسبة الحافة تستخدم IPv6 فقط + NAT64
• مراكز البيانات تجرب IPv6 فقط للتكلفة/البساطة

التحديات المتبقية:

• توافق DNSSEC لا يزال غير محلول بأناقة
• تستمر مشاكل بروتوكول طبقة التطبيق
• الخبرة التشغيلية لا تزال تتطور

على المدى الطويل: مع انكماش إنترنت IPv4 وأصبح IPv6 منتشرًا في كل مكان، قد ينخفض استخدام NAT64 — ستكون لمعظم الوجهات IPv6 أصلي، ولا تتطلب ترجمة. لكن ذلك على بُعد سنوات. الآن، NAT64/DNS64 هي التقنية الرئيسية لتمكين شبكات IPv6 فقط.

ابدأ صغيرًا واختبر#

لا تنشر NAT64/DNS64 في الإنتاج دون اختبار شامل:

1. بيئة مختبرية: إعداد TAYGA أو Jool على شبكة اختبارية
2. تكوين DNS64: استخدم BIND أو Unbound
3. اختبار التطبيقات: تحقق من أن تطبيقاتك المحددة تعمل من خلال الترجمة
4. راقب الأداء: قس زمن الاستجابة وحمل الإنتاجية
5. وثق المشاكل: لاحظ التطبيقات أو الخدمات التي لديها مشاكل
6. خطط للتحايل: مضاعف المكدس للخدمات الإشكالية، 464XLAT للآخرين

فقط بعد الاختبار الناجح يجب أن تفكر في نشر الإنتاج، وحتى ذلك الحين، ابدأ بشبكات أو قطاعات مستخدمين غير حرجة.

NAT64/DNS64 قوي ولكنه يضيف تعقيدًا. استخدمه حيث يحل مشاكل حقيقية، وليس لأنه تقنية جديدة.

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

• استراتيجيات ترحيل IPv6 — اختيار نهج الترحيل الصحيح
• نشر IPv6 مضاعف المكدس — تشغيل IPv4 و IPv6 معًا
• تكوين DNS لـ IPv6 — إعداد DNS لـ IPv6

الأسئلة المتكررة#