مخزن VPN شما همان محدوده DHCP شبکه محلی نیست: چرا می‌شکند

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

دو تخصیص‌دهنده، یک فضای آدرس

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

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

این همان خرابی است که مردم اول با آن روبه‌رو می‌شوند: کلاینتی که با موفقیت وصل می‌شود و بعد به ماشین اشتباه می‌رسد، یا با فاصله به ماشین درست می‌رسد.

چرا روتر آدرس‌های VPN را توزیع نمی‌کند

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

بنابراین سرور VPN خودش آدرس را تعیین می‌کند: یک مخزن در پیکربندی سرور، یک آدرس برای هر همتا در یک راه‌اندازی WireGuard، یا آدرسی که لایه احراز هویت در یک استقرار IKEv2 هل می‌دهد. این سازوکارها از پایگاه داده اجاره شبکه محلی مستقل‌اند، و دقیقاً به همین دلیل به محدوده خودشان نیاز دارند.

همین استدلال توضیح می‌دهد چرا تغییر دامنه DHCP کلاینتی را که هرگز آدرس نمی‌گیرد درست نمی‌کند. کلاینت از سرور شبکه محلی نمی‌پرسد و هیچ مقدار ویرایش دامنه او را به پرسیدن وادار نمی‌کند.

همپوشانی به‌صورت تعارض ظاهر می‌شود، نه شبکه کند

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

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

مسیر بازگشت مشکلی جداست

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

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

این دستورها تصمیم ارسال روی دروازه و ورودی‌های همسایه را نشان می‌دهند که تکرار را آشکار می‌کنند:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

اگر دستور اول با رابط تونل پاسخ دهد، مسیر بازگشت وجود دارد. اگر با رابط شبکه محلی پاسخ دهد، روتر باور دارد کلاینت روی سیم است و تلاش می‌کند برای آن ARP کند.

طراحی‌های پل‌شده وجود دارند، اما باید انتخاب شوند

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

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

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