یک نشانی VPN اضافه کردید و انتظار داشتید درخواست از آن استفاده کند، اما سرور هنوز پیشوند قدیمی را ثبت می‌کرد. هیچ چیز در تونل از کار نیفتاده بود؛ میزبان پیش از آنکه حتی مسیری را که شما به آن نگاه می‌کردید بررسی کند، درباره نشانی مبدأ تصمیم گرفته بود. انتخاب منبع IPv6 یک رقابت مرتب و جداگانه میان نشانی‌های نامزد میزبان است و بلندترین پیشوند منطبق تنها یک قاعده در نزدیکی پایان آن است. برای رسیدن به نتیجه‌ای که می‌خواهید باید بدانید کدام قاعده پیش‌تر برنده شده است. خود قواعد خسته‌کننده و دقیق‌اند و همین دلیل خواندنشان به ترتیب است.

دو جست‌وجو، نه یکی

انتخاب مقصد گام بعدی و رابط خروجی را مشخص می‌کند. سپس انتخاب مبدأ روشن می‌کند کدام یک از نشانی‌های میزبان در سرآیند ظاهر می‌شود، و این دو پرسش با سازوکارهای متفاوت پاسخ داده می‌شوند، هرچند هر دو از پیشوندها استفاده می‌کنند. میزبان دارای یک نشانی فیزیکی، یک نشانی موقت و یک نشانی VPN برای هر مقصدی سه نامزد دارد و مسیر به سوی VPN به‌طور خودکار نامزد سوم را پیشنهاد نمی‌کند.

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

قواعد را رقابتی مرتب بخوانید

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

خوانش عملی این است که نمی‌توانید برنده را تنها از مقصد استنتاج کنید. نامزدها را فهرست کنید، قواعد را به ترتیب بگذرانید و ببینید تصمیم واقعاً کجا گرفته شده است.

توجه کنید که این نیمه مبدأ مسئله است. خلط دو مقایسه پیشوند توضیحاتی می‌سازد که سخت‌گیرانه به گوش می‌رسند و نشانی اشتباه را پیش‌بینی می‌کنند. هر بار که واژه پیشوند را در تیکت به کار می‌برید بگویید کدام مقایسه را منظور دارید.

اتصال برنامه پرسش را تغییر می‌دهد

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

این اتصال به مبدأ را هم ابزار تشخیص و هم راه‌حل موقت می‌کند: نشانی VPN را متصل کنید و ببینید آیا درخواست موفق می‌شود. اگر موفق شود، مسیر درست است و مشکل همان انتخاب بوده است. اگر شکست بخورد، مشکل از همان آغاز مسیر بازگشت یا سیاست طرف دور بوده است.

بررسی کنید که طرف دور آن مبدأ را می‌پذیرد

میزبان هر چه انتخاب کند باید با دامنه محافظت‌شده VPN و مسیر بازگشت و قواعد دسترسی انتهای دور سازگار باشد. مبدأیی بیرون از انتخاب‌کننده‌ها می‌تواند وارد تونل شود و در انتهای دور حذف شود، که مانند یک شکست یک‌سویه دیده می‌شود و گردن مسیریابی می‌افتد. پیش از دست زدن به تنظیمات رمزنگاری، مبدأ داخلی انتخاب‌شده را با دامنه حفاظت مقایسه کنید، زیرا تغییر حالت میان نشانی‌های نامزد یکی را برنمی‌گزیند.

نشانی نقطه پایانی بیرونی را هم در استدلال خود جدا نگه دارید. این نشانی انتقال میان مشارکت‌کنندگان VPN را مشخص می‌کند و مبدأ بسته برنامه در درون نیست.

با چهار مشاهده تصمیم بگیرید

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

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

مقالات مرتبط