مسیر بازگشت VPN برای میزبان‌های LAN با گزینه 121 در DHCP

کلاینت‌های راه دور VPN وصل می‌شوند، سرور LAN پاسخ می‌دهد، و پاسخ از طریق روتر معمولی اینترنت خارج می‌شود و همان‌جا می‌میرد. یک سرور را می‌توان با یک مسیر ایستا درست کرد، اما یک زیرشبکه کامل از آن‌ها بهتر است همان‌جایی مدیریت شود که از قبل پیکربندی شبکه‌شان را می‌گیرند. گزینه 121 در DHCPv4 دقیقاً همین نوع مسیر مقصد را توزیع می‌کند، و همان بخشی است که مردم معمولاً لحظه‌ای که مسیر پیش‌فرض را فراموش می‌کنند اشتباه انجام می‌دهند. نشانه، ترافیک یک‌طرفه است: درخواست‌ها می‌رسند و پاسخ‌ها ناپدید می‌شوند.

اول سه نشانی را نام ببرید

یک LAN مشخص در نظر بگیرید: 192.168.50.0/24 با روتر پیش‌فرض معمولی روی 192.168.50.1 و یک دروازه VPN جداگانه روی 192.168.50.2. کلاینت‌های راه دور احراز هویت‌شده 10.90.0.0/24 را اشغال می‌کنند.

مسیری که هر میزبان مشارکت‌کننده لازم دارد 10.90.0.0/24 via 192.168.50.2 است. مقصد استخر کلاینت‌هاست، و گام بعدی نشانی LAN دروازه است نه نشانی تونل آن.

آن را به عنوان یک مسیر ایستا بدون کلاس رمزگذاری کنید

گزینه 121 جفت‌های پیشوند و گام بعدی را حمل می‌کند، و RFC 3442 هم رمزگذاری و هم رفتار کلاینتی که از آن پیروی می‌کند را تعریف می‌کند. برای یک نمونه موجود dnsmasq که فقط به این LAN نمونه سرویس می‌دهد، شکل پیکربندی چنین است:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

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

مسیر پیش‌فرض را از دست ندهید

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

پیش‌فرض مورد نظر را در همان فهرست بگنجانید، همان‌طور که قطعه بالا انجام می‌دهد. گزینه معمولی Router را هم سر جایش نگه دارید، برای کلاینت‌هایی که مسیرهای بدون کلاس را پیاده‌سازی نمی‌کنند؛ پردازش گزینه‌ها در خود سرور تعیین می‌کند چه چیزی به چه کسی فرستاده شود.

بررسی کنید کلاینت چه چیزی را می‌پذیرد

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

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

اجاره را بررسی کنید، سپس جست‌وجو را

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

روی یک کلاینت Linux، مسیرهای واقعی را بخوانید و هر دو ورودی را تأیید کنید:

ip -4 route
ip -4 route get 10.90.0.23

جست‌وجوی زمینه‌ای باید مسیر استخر را از 192.168.50.2 و پیش‌فرض را از 192.168.50.1 نشان دهد. اگر پیش‌فرض غایب است، تله بالا را بازتولید کرده‌اید.

سپس تبادل واقعی را آزمایش کنید

توزیع مسیر تمام مسیر نیست. دروازه جداگانه هنوز به ارسال بسته، مالکیت همتایان راه دور و سیاست دسترسی‌ای که سرور را مجاز کند نیاز دارد، و DHCP هیچ‌کس را احراز هویت نمی‌کند.

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