VPN دوپشته: خانواده نشانی را کلاینت انتخاب می‌کند، نه شما
یک نام، دو خانواده، دو مسیر متفاوت. تونل می‌تواند سالم باشد و درخواست باز هم شکست بخورد، چون کلاینت نامزدی را برگزیده که هرگز آن را مسیریابی نکرده‌اید.
تونل برپاست، سایت‌های IPv4 بار می‌شوند و یک نام میزبان به پایان مهلت می‌رسد. نتیجه‌گیری فوری این است که VPN خراب است یا اعتبارنامه‌ها اشتباه‌اند، و معمولاً هیچ‌کدام درست نیست. نام هم نشانی IPv4 و هم IPv6 برگرداند، برنامه یکی را انتخاب کرد و تنها یکی از این نامزدها مسیر کاری داشت. کلاینت تصمیم انتخاب را گرفت؛ تونل به‌سادگی آنچه را انتخاب شده بود پوشش نمی‌داد.
انتخاب، وعده پوشش نیست
انتخاب نشانی پیش‌فرض که در RFC 6724 توصیف شده، تعیین می‌کند که میزبان وقتی چند گزینه موجود است کدام جفت مبدأ و مقصد را ترجیح می‌دهد. Happy Eyeballs یک راهبرد اتصال روی آن می‌افزاید: تلاش‌ها را در هر دو خانواده آغاز می‌کند و هر کدام اول پاسخ دهد نگه می‌دارد، تا کاربر منتظر پایان مهلت یک خانواده خراب نماند.
هیچ‌یک از این دو سازوکار مسیر ایجاد نمی‌کند. اگر تونل شما فقط IPv4 را حمل کند، نامزد AAAA هنوز مقصدی مشروع است که کلاینت می‌تواند امتحان کند، و شکست به‌صورت بارگذاری کند و نه خطا ظاهر می‌شود، چون مرورگر عقب‌نشینی کرده است. کاربر از سایتی کند شکایت می‌کند نه خراب، و تیکت پشتیبانی همان ابهام را به ارث می‌برد. آن را با خانواده‌ای ثابت بازتولید کنید و گزارش مشخص می‌شود.
همین عقب‌نشینی دلیل ناسازگاری نشانه میان برنامه‌هاست. مرورگر تأخیر را پنهان می‌کند؛ کلاینت خط فرمان با خانواده ثابت شکست واقعی را بی‌درنگ نشان می‌دهد.
خانواده‌ای را که درخواست واقعاً استفاده کرده بیابید
از نام شروع کنید، نه از تونل. هر دو نوع رکورد را بپرسید و بنویسید چه برگشت:
dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.comاگر درخواست v4 موفق شود و درخواست v6 شکست بخورد، مشکل را در قالبی بازتولید کرده‌اید که می‌توانید اشکال‌زدایی کنید. اگر هر دو از پوسته موفق شوند و مرورگر باز هم شکست بخورد، پیش از دست زدن به تونل به حل‌کننده خود برنامه یا پاسخ کش‌شده نگاه کنید.
خانواده و مقصد را در یادداشت‌هایتان نگه دارید. تیکتی که می‌گوید سایت از طریق VPN بار نمی‌شود را هیچ‌کس نمی‌تواند بررسی کند، در حالی که تیکتی که می‌گوید AAAA شکست می‌خورد و A کار می‌کند به مسیری مشخص اشاره دارد.
مسیر آن خانواده را بررسی کنید
برای خانواده‌ای که شکست می‌خورد، از هسته بپرسید کدام مسیر را به کار می‌برد و آن را با نشانی‌های پیکربندی‌شده تونل مقایسه کنید. در Linux، ip -6 route get برای مقصد رابط و مبدأیی را که انتخاب می‌شود نشان می‌دهد.
سپس خود تونل را بررسی کنید. همتایان WireGuard فهرست IPهای مجاز را حمل می‌کنند و یک ورودی برای 0.0.0.0/0 هیچ چیزی درباره IPv6 نمی‌گوید. اگر فهرست همتا هیچ پیشوند IPv6 نداشته باشد، کلاینت دلیلی برای فرستادن ترافیک AAAA به تونل ندارد و بسته از همان راهی بیرون می‌رود که میزبان در غیر این صورت می‌رفت.
قواعد فایروال و سیاست NAT همان بررسی را برای هر خانواده می‌طلبند. قاعده‌ای که برای IPv4 نوشته شده در هیچ سکویی IPv6 را پوشش نمی‌دهد، و این رایج‌ترین دلیل کار کردن یک خانواده و کار نکردن دیگری است.
برای ساده کردن تصویر صفحه، IPv6 را غیرفعال نکنید
خاموش کردن IPv6 در کل سامانه نشانه را از میان می‌برد و شما را بی‌تشخیص می‌گذارد. همچنین هر مقصدی را که فقط IPv6 است می‌شکند و همان باگ را برای برنامه بعدی پنهان می‌کند. اگر ماشینی واقعاً نباید از IPv6 استفاده کند، این سیاستی آگاهانه با مالک و آزمون است. خاموش کردن آن هنگام یک رخداد هیچ‌یک از این دو نیست.
تصمیم بگیرید کلاینت با خانواده چه کند و آن را صریح پیکربندی کنید: آن را از تونل عبور دهید، یا به روشی پشتیبانی‌شده مسدودش کنید تا انتخاب هرگز نامزد دسترس‌ناپذیری پیشنهاد نکند. هر دو طرح مشروعی هستند. غیرفعال‌سازی سراسری هیچ‌یک نیست، چون اصلاً طرح نیست.
چه چیزی در تیکت بنویسیم
چهار چیز را ثبت کنید: نام میزبان، خانواده‌ای که شکست خورد، مسیری که هسته برگزید و نتیجه درخواستی مخصوص آن خانواده. همین مجموعه برای بازتولید شکست توسط شخصی دیگر کافی است، بی‌آنکه حدس بزند کدام یک از دو مسیر را منظور داشته‌اید.
قواعد انتخاب نشانی RFC 6724 توضیح می‌دهند چرا کلاینت نامزدی را ترجیح داد که ترجیح داد، و RFC 8305 رفتار مسابقه‌ای را توضیح می‌دهد که تأخیر را پنهان کرد. هیچ‌یک از آن‌ها بسته‌ای را برای شما مسیریابی نمی‌کند، و همین بخشی است که تونل باید انجام دهد.