لب عملی: پیکربندی DNS64 در کنار NAT64

هدف لب

پیکربندی DNS64 روی یک روتر برای رهگیری پرس‌وجوهای DNS از کلاینت‌های فقط-IPv6، سنتز خودکار یک رکورد AAAA که آدرس یک مقصد فقط-IPv4 را با استفاده از پیشوند NAT64 در بر می‌گیرد، و تأیید اینکه یک کلاینت می‌تواند به آن مقصد فقط با نام‌میزبان بدون ساختن دستی هیچ آدرس ترکیبی برسد.

هدف لب (چرا مهم است)

لب NAT64 قبلی نیازمند ساختن دستی آدرس IPv6 ترکیبی با دست بود — غیرعملی برای اپلیکیشن‌های واقعی که نام‌میزبان را حل می‌کنند به‌جای تایپ‌کردن آدرس‌های تحت‌اللفظی. DNS64 این را کاملاً خودکار می‌کند: وقتی یک کلاینت فقط-IPv6 یک نام‌میزبان که فقط یک رکورد IPv4 (A) دارد را پرس‌وجو می‌کند، DNS64 یک رکورد AAAA با استفاده از پیشوند NAT64 سنتز می‌کند، و کل فرآیند را برای اپلیکیشن شفاف می‌کند.

توپولوژی لب

همان توپولوژی لب NAT64 قبلی، با DNS64 اضافه‌شده
روی R1

IPv4Server فقط یک رکورد A دارد:
  ipv4server.lab -> 203.0.113.50
  (هیچ رکورد AAAA‌ای برای این نام وجود ندارد)

وظیفه ۱: تأیید عدم‌داشتن رکورد AAAA توسط سرور

تأیید کن یک پرس‌وجوی مستقیم AAAA برای ipv4server.lab هیچ‌چیزی بازنمی‌گرداند، چون فقط یک رکورد A وجود دارد.

وظیفه ۲: پیکربندی DNS64 روی R1

R1 را طوری پیکربندی کن که رکوردهای AAAA را با استفاده از همان پیشوند NAT64 پیکربندی‌شده در لب قبلی سنتز کند.

وظیفه ۳: اشاره‌دادن کلاینت فقط-IPv6 به R1 برای DNS

IPv6Client را طوری پیکربندی کن که از R1 به‌عنوان resolver قادر-به-DNS64‌اش استفاده کند.

وظیفه ۴: تأیید دریافت یک رکورد AAAA سنتزشده توسط کلاینت

نام‌میزبان را از کلاینت پرس‌وجو کن و تأیید کن یک رکورد AAAA با استفاده از پیشوند NAT64 و شامل آدرس IPv4 واقعی سرور بازگردانده می‌شود.

وظیفه ۵: تأیید اتصال کلاینت با استفاده از فقط نام‌میزبان

تأیید کن کلاینت با موفقیت به سرور با استفاده از اتصال معمولی مبتنی‌بر-نام‌میزبان می‌رسد، بدون نیاز به هیچ ساخت دستی آدرس.

راه‌حل و تأیید

DNSServer> dig AAAA ipv4server.lab

;; ANSWER SECTION:
(خالی -- هیچ رکورد AAAA‌ای وجود ندارد)
-- تأیید‌شده: این نام واقعاً فقط یک رکورد A
-- IPv4 دارد، هیچ رکورد IPv6 بومی‌ای ندارد

R1(config)# dns64 server

R1(config)# dns64 prefix 64:ff9b::/96

-- استفاده از همان پیشوند پیکربندی‌شده برای
-- NAT64 در لب قبلی ضروری است -- DNS64
-- آدرس‌هایی را سنتز می‌کند که NAT64 سپس باید
-- واقعاً ترجمه کند، پس یک عدم‌تطابق اینجا
-- آدرس‌های سنتزشده‌ای تولید می‌کرد که NAT64
-- تشخیص نمی‌دهد

IPv6Client(config)# [سرور DNS تنظیم‌شده به
                     آدرس IPv6 R1، 2001:DB8:K:1::1]

IPv6Client> dig AAAA ipv4server.lab

;; ANSWER SECTION:
ipv4server.lab.  300  IN  AAAA  64:ff9b::cb00:7132
-- R1 این رکورد AAAA را در لحظه سنتز کرد --
-- هیچ رکورد AAAA‌ای روی سرور معتبر وجود ندارد،
-- این رکورد فقط چون DNS64 آن را هنگام متوجه‌شدن
-- اینکه پرس‌وجو از یک مسیر resolver قادر-به-
-- IPv6 آمده و فقط یک رکورد A پیدا شد ساخت وجود دارد

IPv6Client> curl http://ipv4server.lab

-- با موفقیت متصل می‌شود، کاملاً با نام‌میزبان
-- -- هیچ ساخت دستی آدرس، هیچ IP تحت‌اللفظی‌ای
-- در هیچ‌جا توسط کاربر تایپ نشده

R1# show nat64 translations

Proto  IPv6 Source          IPv6 Destination        IPv4 Source    IPv4 Destination
tcp    2001:DB8:K:1::10     64:ff9b::cb00:7132       203.0.113.1    203.0.113.50
-- تأیید می‌کند اتصال واقعاً از میان ترجمه
-- NAT64 جریان می‌یابد، دقیقاً مانند لب قبلی،
-- اما این‌بار رسیده از طریق حل معمولی
-- نام‌میزبان به‌جای یک آدرس سنتزشده دستی-تایپ‌شده

نکته کلیدی

DNS64 و NAT64 به‌عنوان یک جفت منطبق طراحی شده‌اند که همان پیشوند را به اشتراک می‌گذارند — DNS64 آدرس را سنتز می‌کند، و NAT64 ترجمه واقعی را برای ترافیک فرستاده‌شده به آن آدرس سنتزشده انجام می‌دهد، با پیشوند مشترک که نقطه هماهنگی متصل‌کننده این دو است — استقرار فقط NAT64، مانند لب قبلی، هر اپلیکیشن را مجبور می‌کند به‌نحوی از‌قبل آدرس سنتزشده درست را بداند، در حالی که افزودن DNS64 کل مکانیزم را برای اپلیکیشن‌های معمولی که نام‌میزبان‌ها را همان‌طور که معمولاً انجام می‌دادند حل می‌کنند شفاف می‌کند.