چرا رزرو DHCP یک IP ثابت برای سرور VPN شما نیست

یک جعبهٔ VPN خانگی را از Wi-Fi به Ethernet بردم و نشانی «دائمی» آن همان شب تغییر کرد. هیچ چیز روی روتر خراب نبود. رزرو با آداپتور بی‌سیم تطبیق یافته بود و آن آداپتور دیگر در مسیر نبود.

این برداشت نادرست نیمهٔ دومی هم دارد. درست‌کردن نشانی LAN هیچ کاری برای نشانی‌ای که دوستانتان به آن وصل می‌شوند نمی‌کند و هیچ ارتباطی با استخر خصوصی‌ای که VPN به کلاینت‌ها می‌دهد ندارد. سه نشانی، سه حالت خرابی جداگانه، و تنها یکی از آن‌ها کار یک رزرو است.

رزرو با کلاینت تطبیق می‌یابد، نه با دستگاه

در DHCPv4 رزرو بر نشانی سخت‌افزاری کلاینت استوار است؛ در DHCPv6 بر DUID که انتظار می‌رود کلاینت آن را نگه دارد. فیلد hostname برچسبی برای انسان‌هاست. آنچه روتر واقعاً مقایسه می‌کند شناسه‌ای است که در درخواست می‌رسد.

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

OpenWrt شکل را روشن نشان می‌دهد. یک بلوک config host در /etc/config/dhcp یک نام، یک MAC و یک نشانی را به هم می‌بندد، و مستندات اجاره‌های ثابت توضیح می‌دهد که این ورودی چگونه با استخر تعامل دارد. روترهای دیگر همان سه فیلد را پشت برچسب‌های متفاوت پنهان می‌کنند.

جایی که تطبیق بی‌صدا از کار می‌افتد

تعویض سخت‌افزار حالت رایج است. کارت شبکه را عوض کنید، یا ماشین را بین Ethernet و Wi-Fi جابه‌جا کنید، و نشانی‌ای که روتر می‌بیند با آن تغییر می‌کند. رزرو قدیمی در فهرست می‌ماند و همچنان درست به نظر می‌رسد.

نصب دوباره حالت دوم است و در IPv6 سخت‌تر گاز می‌گیرد. نصب تازه می‌تواند DUID جدیدی بسازد در حالی که اجارهٔ قدیمی IPv4 هنوز معتبر است، پس نشانی v4 مدتی زنده می‌ماند و ورودی v6 بدون هیچ ویرایش دیدنی از کار می‌افتد.

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

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

پیکربندی سمت میزبان و هزینه‌اش

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

هزینه مالکیت است. حالا پیشوند، دروازه و حل‌کننده‌ها را خودتان تأمین می‌کنید و باید نشانی را خودتان بیرون از استخر پویا نگه دارید. در Ubuntu با netplan، /etc/netplan/01-vpn.yaml آن را حمل می‌کند:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

کاربران NetworkManager با nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1 و سپس nmcli con up "Wired connection 1" به همان وضعیت می‌رسند. netplan را در نخستین تلاش با netplan try اعمال کنید نه با netplan apply؛ دروازه‌ای که اشتباه تایپ شده جعبه را از شبکه بیرون می‌برد و شما را به دنبال کنسول می‌فرستد.

با این حال یک رزرو منطبق نگه دارید. زیادی نیست. ورودی نشانی را در سمت روتر ثبت می‌کند و مانع می‌شود سرور DHCP آن نشانی را به دستگاه مهمان بدهد اگر کسی بعداً استخر را گسترده کند.

یک نشانی LAN پایدار نقطهٔ پایانی عمومی نیست

انتقال پورت را به 192.168.50.10 نشانه بگیرید و قاعده از هر تغییر سمت LAN جان سالم به در می‌برد. نشانی اینترنت پایداری به شما نمی‌دهد. IP عمومی شما متعلق به ISP است و می‌تواند با اتصال دوباره یا تعویض مودم جابه‌جا شود، که DNS پویا برای همین است.

پشت NAT سطح اپراتور اصلاً IPv4 عمومی‌ای برای انتقال وجود ندارد و هیچ رزروی یکی نمی‌سازد. پیش از هر چیز صفحهٔ WAN روتر را بررسی کنید: اگر نشانی در محدودهٔ مشترک باشد، انتقال ورودی هرگز کار نمی‌کند، هر قدر هم رزرو پاکیزه باشد.

نشانی سوم استخر تونل است، اغلب چیزی مثل 10.8.0.0/24. این نشانی‌ها فقط داخل تونل وجود دارند و هرگز در LAN ظاهر نمی‌شوند. اشتباه گرفتن آن‌ها با نشانی LAN سرور همان راهی است که یک پورت در نهایت به کلاینتی منتقل می‌شود که فقط تا وقتی متصل است آنلاین است.

مسیر را به همان ترتیبی که می‌شکند بررسی کنید

از روتر شروع کنید. ورودی جدول اجاره را با هدف رزرو مقایسه کنید؛ اگر سرور نشانی استخر را گرفته، شناسه اشتباه است و ip link show روی میزبان مقدار لازم برای مقایسه را می‌دهد.

سپس میزبان. ip -4 addr show eth0 باید نشانی و پیشوند مورد انتظار را گزارش کند. وجود نشانی دوم روی همان رابط معمولاً یعنی DHCP هنوز در کنار پیکربندی ثابت شما اجرا می‌شود.

سپس انتقال. تأیید کنید که مقصد هنوز همان نشانی‌ای است که همین حالا بررسی کردید و چیزی با ss -lntp گوش می‌دهد. انتقالی که به پورت بسته اشاره کند از بیرون دقیقاً مثل انتقال شکسته به نظر می‌رسد.

از بیرون تمام کنید، روی تلفنی با Wi-Fi خاموش. همان یک آزمون «نشانی محلی اشتباه است» را از «دسترسی عمومی شکسته است» جدا می‌کند، همان دو مشکلی که این چیدمان مدام با هم قاطی می‌کند.

سه نشانی را بنویسید، LAN، عمومی و استخر تونل، و یادداشت کنید هر کدام متعلق به کدام سامانه است. وقتی ماه آینده یک اتصال شکست خورد می‌دانید کدام را بررسی کنید، به‌جای اینکه هر سه را همزمان عوض کنید.