قواعد VPN در روتر: مبدأ و مقصد را تطبیق دهید

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

نام ویژگی دو سر را پنهان می‌کند

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

نیاز را پیش از مقایسهٔ محصولات به‌صورت جفت بنویسید. همان جفت چیزی است که بعداً می‌آزمایید.

محصولی که فهرست دستگاه یا فهرست مقصد جهانی ارائه می‌دهد، شاید نتواند «فقط این دستگاه، فقط این مقصدها» را بیان کند. این شکاف ظاهری نیست: قاعدهٔ مقصد جهانی ترافیک همهٔ دستگاه‌ها به آن سایت را از تونل می‌فرستد و قاعدهٔ دستگاه تمام ترافیک آن دستگاه را می‌فرستد. هیچ‌کدام نیاز نیست. پیش از اعتماد به صفحه، آن حالت را با دو دستگاه بیازمایید.

قاعده را به‌صورت اشتراک بسازید

جدول طرح را صادق نگه می‌دارد. سناریو را در سمت چپ بگذارید، سپس تطبیق فرستنده و تطبیق هدف را جداگانه نام‌گذاری کنید:

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

هویت مبدأ را پایدار نگه دارید. رزرو DHCP، بخش اختصاصی یا سازوکار هویت دستگاه همه کار می‌کنند، اما نشانی‌ای که پس از پایان اجاره تغییر می‌کند کار نمی‌کند. IPv6 را بگنجانید، چون یک نشانی IPv4 تمام ترافیک یک دستگاه را شناسایی نمی‌کند.

اولویت همپوشانی را تعیین می‌کند

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

دستور کار را برای ترتیب و برای حالت بدون تطبیق بخوانید، سپس هر دو را با ترافیکی که می‌توانید ببینید بیازمایید:

ip rule show
ip route get 203.0.113.10

اگر مستندات ترتیب را ذکر نمی‌کند، فرض کنید قاعدهٔ باریک‌تر ممکن است پیروز نشود و بر همان اساس طراحی کنید. دو قاعده‌ای که نمی‌توانند تعارض داشته باشند پشتیبانی‌شان آسان‌تر از یک قاعدهٔ هوشمند با اولویت مستندنشده است.

نام‌ها به سیاست تازه‌سازی نیاز دارند

مقصدی که به‌صورت دامنه نوشته می‌شود یک مشکل نگهداری اضافه می‌کند. روتر باید آن را حل کند، نگاشت را تازه کند، چند نشانی و زیردامنه را مدیریت کند و با DNS برنامه‌هایی که حل‌کنندهٔ مورد انتظار را دور می‌زنند کنار بیاید.

کپی کردن یک نتیجهٔ جست‌وجو در قاعدهٔ IP یک عکس لحظه‌ای است، نه سیاست دامنه.

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

حالت در دسترس نبودن را تعریف کنید

ترجیح مسیر ترافیک فقط-VPN را الزام نمی‌کند. وقتی تونل قطع است، روتر می‌تواند جریان را مسدود کند، مستقیم بفرستد یا از تونل دیگری استفاده کند، و هر انتخاب امضای شکست متفاوتی دارد.

تعیین کنید نیاز کدام را می‌خواهد، سپس با متوقف کردن تونل و مشاهدهٔ جریان آن را بررسی کنید:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

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