عملاء 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. سجّل النتائج الثلاث في تذكرة التغيير ليبدأ الشخص التالي من الأدلة.