کلاینتهای VPN در RRAS به استخر IPv4 اختصاصی و مسیر بازگشت نیاز دارند

کلاینت VPN متصل میشود و نشانی میگیرد، اما میزبان LAN که به آن نیاز دارد هنوز نمیتواند پاسخش را بدهد. در Windows Routing and Remote Access، نشانی داخلی کلاینتهای VPN از استخری میآید که جدا از آداپتور LAN سرور پیکربندی میشود، و سمت LAN به مسیری بازگشتی به آن استخر نیاز دارد. دو تغییر، نه یکی، و هر یک به شکلی متفاوت شکست میخورند. آنها را به ترتیب انجام دهید تا پیش از بازنشسته کردن محدودههای قدیمی، طرح نشانیها و مسیر بازگشت اثبات شود.

محدوده را پیش از باز کردن کنسول رزرو کنید

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

طرح نشانیهایی که فقط در یک کنسول زندگی میکند، یک بازسازی از برخورد فاصله دارد. همچنین گرایش به رشد دارد: کسی بعداً محدوده دومی اضافه میکند و هیچکس اولی را بررسی نمیکند. طرح را کنار مستندات سرور نگه دارید، نه در رشته چت.

آداپتور LAN سرور این استخر را تعریف نمیکند. تغییر شنونده عمومی یا افزودن آداپتور به LAN کار کاملاً دیگری میکند. به همین دلیل کلاینتها میتوانند متصل شوند و با این حال نشانی را از جای اشتباه بگیرند. استخر در ویژگیهای IPv4 سرور زندگی میکند، نه در فهرست آداپتورها.

تغییر روش، افزودن محدوده نیست

RRAS یک روش تخصیص و مجموعهای از محدودهها دارد. گذر از DHCP به استخر استاتیک تغییر روش است. افزودن بلوک دیگر در حالی که استخر استاتیک از قبل فعال است، تغییر محدوده است.

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

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

دستور دوم شکست میخورد یا استخری غیرقابل استفاده میسازد اگر سرور هنوز روی تخصیص DHCP باشد. اولی روش را جایگزین میکند نه اینکه استخر موجود را گسترش دهد. هیچکدام از پیشنمایشها چیزی اعمال نمیکند، پس آن را که مطابقت دارد اجرا کنید و سپس استخر حاصل را در کنسول تأیید کنید. اگر مطمئن نیستید سرور در چه وضعیتی است، روش تخصیص را در صفحه ویژگیهای IPv4 بخوانید و محدودههای پیکربندیشده را فهرست کنید:

Get-VpnIPAddressRange

روش DHCP با فهرست محدوده خالی یعنی پیشنمایش اول اعمال میشود. استخر نشانی استاتیک با محدوده موجود یعنی دومی اعمال میشود.

راهاندازی مجدد سرویس را که تنظیم ممکن است نیاز داشته باشد در نظر بگیرید و فرض نکنید کلاینتهای متصل فوراً شمارهگذاری مجدد میشوند. کلاینتی که تا اتصال مجدد نشانی قدیمیاش را نگه میدارد، طبیعی رفتار میکند. تغییر را برای پنجرهای برنامهریزی کنید که اتصال مجدد در آن قابل قبول است.

LAN به مسیر بازگشت نیاز دارد

فرض کنید LAN برابر 10.60.0.0/24 است و سرور RRAS در آن 10.60.0.10 است. میزبانی در آن LAN که به کلاینتی در 10.250.50.0/24 پاسخ میدهد، به مسیری به استخر از طریق سرور RRAS نیاز دارد. بدون آن مسیر، درخواست میرسد و پاسخ میمیرد.

اگر دروازه پیشفرض میزبان روتر دیگری باشد، آن روتر به مسیر بازگشت برای پیشوند VPN نیاز دارد. مسیر استاتیک روی سرور RRAS اینجا کمکی نمیکند؛ مسیر بازگشت باید روی دستگاهی وجود داشته باشد که دروازه LAN را دارد، پس آن را به جدول مسیریابی یا به فرایند مسیریابی پویا اضافه کنید، بسته به اینکه سایت از کدام استفاده میکند.

فایروال میزبان و هر قاعده دسترسی شبکه را نیز در برابر محدوده مبدأ جدید بررسی کنید. قواعدی که برای محدوده قدیمی کلاینت نوشته شدهاند، محدوده جدید را رد میکنند حتی اگر تخصیص موفق شده باشد. مسیرهای کلاینت به سمت LAN و تفکیک DNS نیازهای جداگانهای هستند و هر دو میتوانند شکست بخورند در حالی که تونل سالم به نظر میرسد. هر یک را جداگانه آزمایش کنید.

استخر جدید را روی یک دستگاه اثبات کنید پیش از بازنشسته کردن استخر قدیمی

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

تفکیک نام شایسته آزمایش خودش است: دسترسی با IP میتواند کار کند در حالی که DNS کلاینت هنوز به ریزولوری اشاره میکند که به آن نمیرسد. سرور DNS در LAN تنها در دسترس است اگر کلاینت مسیری به آن داشته باشد و سرور پرسوجوهای محدوده جدید را بپذیرد. هر دو از اشتباهات رایج هنگام جابهجایی استخر هستند.

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

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

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

از سمت کلاینت، نشانی و مسیر به یک میزبان LAN را تأیید کنید:

ipconfig | findstr /i "IPv4"
route print -4

از سمت میزبان LAN، مسیر پاسخ و سیاست را در یک گذر تأیید کنید. اگر ping شکست بخورد اما برنامه کار کند، قطعه گمشده احتمالاً قاعده ICMP است نه مسیر. اگر هر دو شکست بخورند، پیش از ویرایش VPN مسیر را روی میزبان بخوانید. سه نتیجه را در تیکت تغییر ثبت کنید تا نفر بعدی از شواهد شروع کند.