RRAS DHCP: نشانی تازه یا فقط گزینه‌های پیکربندی؟

خواندن DHCPACK در یک ضبط به‌عنوان مدرکی بر اینکه کارخواه VPN نشانی خود را از DHCP گرفته است اشتباه است. معمولاً فقط ثابت می‌کند که به پیامی از DHCP پاسخ داده شده است. Windows RRAS می‌تواند نشانی‌های نشست را از استخر ایستای خود توزیع کند، در حالی که DHCP همچنان گزینه‌ها را به کارخواه متصل می‌رساند. نوع درخواست می‌گوید کدام‌یک از این دو کار در جریان بوده است.

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

DHCP دو کار جدا انجام می‌دهد و آن دو نوع پیام را سهیم می‌شوند. یکی تخصیص نشانی و اجاره است. دیگری رساندن پیکربندی به میزبانی است که از پیش نشانی دارد، که RFC 2131 آن را DHCPINFORM می‌نامد. پاسخ در حالت دوم گزینه‌ها را دارد و هیچ زمان اجاره‌ای ندارد.

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

RRAS نشانی را از کجا می‌گیرد

RRAS مالک تصمیم نشانی VPN از طریق روش تخصیص IPv4 پیکربندی‌شده است: یا سرور DHCP یا استخر نشانی ایستا. وقتی استخر ایستا باشد، استخر تخصیص‌دهنده است و یک رزرو روی سرور DHCP جداگانه در آن نشست حرفی برای گفتن ندارد. این دو سازوکار می‌توانند در یک شبکه کنار هم بمانند بدون اینکه یکی دیگری را کنترل کند.

Get-Command -Module RemoteAccess *IPAddress*

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

کلاس کاربر چه چیزی را می‌تواند ثابت کند و چه چیزی را نه

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

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

مدرک‌ها را مقایسه کنید، نه ACK را

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

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

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