چرا پاسخ‌های DNS64 پس از اتصال VPN تغییر می‌کنند؟

پاسخ‌های DNS64 یک ترتیب شبکه‌ای را توصیف می‌کنند، نه خصلتی از سرور. حل‌کننده یک نشانی IPv6 را از نشانی IPv4 می‌سازد و نتیجه تنها جایی کار می‌کند که مترجمی در انتهای آن پیشوند بنشیند. یک VPN را به مسیر بیاورید و آن ترتیب می‌تواند بسته به سه شرط بماند، تغییر کند یا دیگر درست نباشد.

این شرط‌ها همان حل‌کننده‌ای است که پاسخ داده، مسیری که دستگاه شما به پیشوند ساخته‌شده دارد و این که چیزی روی آن مسیر ترجمه را انجام می‌دهد یا نه. هر یک قابل مشاهده است و همین است که خرابی را قابل عیب‌یابی می‌کند.

یک رکورد AAAA ساخته‌شده واقعاً به چه چیزی اشاره می‌کند

حل‌کننده DNS64 به پرسش AAAA برای نامی که فقط IPv4 دارد پاسخ می‌دهد با جای دادن نشانی IPv4 درون پیشوندی که برای استفاده از آن پیکربندی شده است، و پیشوند شناخته‌شده برای این کار 64:ff9b::/96 است که در RFC 6147 توصیف شده است. رکورد برای برنامه مانند هر رکورد AAAA دیگری به نظر می‌رسد و نکته همین است: کارخواهی که فقط IPv6 دارد می‌تواند اتصال را بیازماید بی‌آنکه بداند مقصد هرگز IPv6 نداشته است. سپس آن اتصال به کارکرد NAT64 وابسته است که جایی روی مسیر میان دو خانواده ترجمه می‌کند. بدون آن مترجم، نشانی ساخته‌شده مقصدی باورپذیر است که به هیچ‌جا نمی‌رسد.

پس رکورد دو چیز را هم‌زمان رمزگذاری می‌کند: نشانی اصلی IPv4 و این فرض که مترجمی در دسترس است. تنها اولی در خود پاسخ دیده می‌شود.

سه شرط تعیین می‌کنند که آیا هنوز کار می‌کند

شرط اول این است که کدام حل‌کننده رکورد را ساخته، چون حل‌کننده‌ای بدون DNS64 پیکربندی‌شده برای آن نام چیزی برنمی‌گرداند و برنامه به شکل دیگری شکست می‌خورد. دومی این است که آیا دستگاه شما مسیری به پیشوند ساخته‌شده دارد، چون پاسخ می‌تواند معتبر باشد در حالی که راه رسیدن به آن نیست. سومی این است که آیا مترجم مالک آن پیشوند روی مسیری است که استفاده می‌کردید، چون تونلی که 64:ff9b::/96 را جای دیگری می‌برد به کارکردی دیگر یا به هیچ چیز می‌رسد. هر سه می‌توانند پیش از تونل برقرار باشند و پس از آن شکست بخورند و همین است که نشانه شبیه یک پسرفت ناگهانی به نظر می‌رسد.

آن‌ها را به همین ترتیب بررسی کنید. پاسخی که نیست و مسیری که نیست در مرورگر یکسان و در گزارش حل‌کننده کاملاً متفاوت دیده می‌شوند.

وقتی حل‌کننده عوض می‌شود، پاسخ هم عوض می‌شود

کارخواه VPN غالباً حل‌کننده خودش را تحمیل می‌کند یا کل مسیر پرسش را در دست می‌گیرد و آن حل‌کننده ممکن است چیزی نسازد. آنگاه پرسش‌های نام‌های فقط IPv4 هیچ رکورد AAAA برنمی‌گردانند و کارخواهی که فقط IPv6 دارد این را همچون نامی می‌بیند که به آن نمی‌رسد. عکس آن هم رخ می‌دهد: حل‌کننده‌ای که واقعاً می‌سازد می‌تواند پیشوندی به شما بدهد که مسیر تونلی شما آن را حمل نمی‌کند.

حافظه نهان دیدن این را سخت‌تر می‌کند. رکورد ساخته‌شده‌ای که در شبکه دفتر به دست آمده می‌تواند از بافتی که آن را ساخته بیشتر بماند، بنابراین کارخواه همچنان به نشانی‌ای متصل می‌شود که مترجمش دیگر در دسترس نیست. به حل‌کننده‌ای که اکنون پاسخ می‌دهد نگاه کنید، نه به آن که هنگام ذخیره مدخل پاسخ داد. پاک‌کردن حافظه نهان بدون ثبت پاسخ قدیم و جدید شواهدی را که نیاز دارید نابود می‌کند.

جستجو و مسیر را جداگانه بیازمایید

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

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

نتایج را مانند یک زنجیره بخوانید. نبودن رکورد AAAA یعنی حل‌کننده پیش روی شما نمی‌سازد، پس مسیری که فقط IPv6 دارد برای آن نام کار نخواهد کرد، هر کاری که کارخواه بکند. بودن رکورد بدون مسیر یعنی پیشوند را مسیر کنونی حمل نمی‌کند و این یک تصمیم مسیریابی است نه خطای حل‌کننده. بودن مسیر در حالی که درخواست هنوز شکست می‌خورد به خود مترجم اشاره دارد و آن به مالک دیگری تعلق دارد.

حل‌کننده، بافت شبکه و خانواده نشانی را کنار هر نتیجه ثبت کنید. همین یادداشت است که به مقایسه بعدی اجازه می‌دهد تغییر حل‌کننده را از تغییر مسیریابی جدا کند.