DHCP از طریق VPN: پخش را پل بزنیم یا بازپخش کنیم؟

یک لپ‌تاپ جدید در آن‌سوی تونل نشانی نمی‌گیرد، در حالی که همان لپ‌تاپ در دفتر مرکزی کار می‌کند. اولین گمان معمول این است که تونل DHCP را مسدود می‌کند. بیشتر اوقات بستهٔ پخش هرگز مسیری نداشته است: کلاینت پیکربندی‌نشده به 255.255.255.255 می‌فرستد و یک مسیریاب IP معمولی آن بسته را ارسال نمی‌کند. تونل دقیقاً همان کاری را می‌کند که یک تونل مسیریابی‌شده انجام می‌دهد.

دو طرح می‌توانند این را تغییر دهند و هم‌ارز نیستند. یکی بستهٔ پخش را حمل می‌کند؛ دیگری درخواست را بازپخش می‌کند.

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

کلاینت DHCPv4 بدون نشانی از 0.0.0.0 به نشانی پخش محدود روی پورت‌های UDP 67 و 68 می‌فرستد. آن بسته بنا بر طراحی روی همان پیوند خود می‌ماند. مسیریابی که آن را ارسال می‌کرد، هر بخشی را که به آن خدمت می‌دهد سیل‌آسا می‌کرد.

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

تونل پل‌شده در واقع چه چیزی را گسترش می‌دهد

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

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

این تصمیمی بزرگ‌تر از تأمین یک نشانی است و باید آگاهانه گرفته شود.

در عوض درخواست را بازپخش کنید

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

برای یک دفتر دور به‌عنوان نمونه، بازپخش‌کننده روی LAN دفتر قرار دارد و سرور از طریق VPN سایت در دسترس است. دامنه را برای آن دفتر، هویت بازپخش‌کننده و سرور، و مسیر بازگشت کامل را پیکربندی کنید. اجازهٔ UDP 67 از تونل به سرور نمی‌گوید کدام استخر را استفاده کند.

بازپخش‌کننده‌ای که ارسال می‌کند اما هرگز پاسخی نمی‌گیرد معمولاً مشکل مسیر بازگشت است. پیش از تغییر دامنه، مسیر برگشت به نشانی بازپخش‌کننده را بررسی کنید.

DHCP را از ARP و از نشانی‌دهی تونل جدا کنید

DHCP روی UDP/IP سوار می‌شود. در Ethernet، میزبان ممکن است از ARP هم برای بررسی اینکه نشانی نامزد پیش‌تر در استفاده است بهره ببرد. آن بررسی تعارض یک عملیات محلیِ پیوند و جداگانه است، نه حامل پیام‌های DHCP. گفتن اینکه DHCP در اصل ARP است نادرست است؛ گفتن اینکه این دو هرگز مرتبط نیستند بسیار گسترده است.

کلاینت VPN می‌تواند نشانی تونل خود را از پروتکل VPN یا از استخر خود سرور بگیرد، نه از پخش DHCP. گزینه‌ای که نامش DHCP دارد ممکن است تنظیمات کلاینتِ هل‌داده‌شده را توصیف کند، نه بستهٔ DHCP بازپخش‌شده را. پیش از فرض اینکه DHCP اصلاً دخیل است، استخر سرور را بررسی کنید.

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