عنوان IP ثابت في Azure P2S VPN: لماذا يتغيّر عنوان العميل
يمنح Azure point-to-site العنوان الحر التالي من التجمع عند كل اتصال، لذا لا يوجد عنوان IP ثابت للعميل. اربط الوصول بالنطاقات أو بالهوية بدلًا من ذلك.
يتلقّى كل عميل في Azure point-to-site عنوانًا من التجمع عند المصادقة، ولا يحتفظ به إلا طوال عمر ذلك الاتصال. لا يوجد جدول حجز، ولا تعيين لكل مستخدم، ولا إعداد في البوابة يعني «امنح هذا الشخص دائمًا 172.16.0.10». هذه الآلية الواحدة تفسّر الأعراض التي يصادفها الناس لاحقًا: قاعدة NSG تتوقف عن مطابقة مستخدم كانت تطابقه، وقائمة سماح تقبل بهدوء جهازًا لم يُضِفه أحد عن قصد. واستبدال القاعدة بقاعدة IP أذكى لا يصلح أيًا منهما، لأن الشيء الذي تسمّيه القاعدة يُعاد إسناده وفق جدول لا تتحكم فيه.
التجمع سعة، لا هوية. إنه موجود كي تحصل الأنفاق المتزامنة على عناوين فريدة، وهو يعيد تدويرها في اللحظة التي ينتهي فيها الإيجار. متى اتضح ذلك، يتوقف السؤال المفيد عن كونه «كيف أثبّت هذا العميل» ويصبح «ما الذي يمكنني كتابة قاعدة تجاهه لن تعيد البوابة تدويره».
ما تفعله البوابة فعليًا عند اتصال العميل
تحتفظ البوابة بتجمّع عناوين العملاء المُهيّأ وتتعامل معه كجدول إيجارات. عند الاتصال تأخذ العنوان الحر التالي، وعمليًا أدنى عنوان متاح، وتُسنِده إلى محوّل النفق حتى يقطع العميل الاتصال أو ينتهي الإيجار. الترتيب هو الحاكم، لا الهوية: فمن يعيد الاتصال أولًا بعد فترة هدوء يأخذ أدنى عنوان يكون حرًا في تلك اللحظة.
حجم التجمع يخفي السلوك. تجمع مخبري أكبر بعنوان أو عنوانين من عدد المختبرين يبدو حتميًا، لأن الحاسوب نفسه يميل إلى إعادة الاتصال بالترتيب نفسه كل صباح. أضف جهازًا ثالثًا، أو غيّر حجم التجمع، أو اترك جلسة متصلة خلال الغداء، فينكسر النمط. لم يكن العنوان مستقرًا قط؛ الطابور هو الذي كان مستقرًا.
أي تغيير في إعداد point-to-site يعيد أيضًا ضبط فضاء الإيجارات. نوع مصادقة مختلف، أو تجمع بحجم مختلف، أو نطاق تجمع جديد، أو بوابة تُهدم وتُعاد بناؤها، كلها تعيد العملاء إلى تجمع لم يعد يربطهم بعناوينهم القديمة. ولا شيء في ذلك التغيير يمسّ قاعدة NSG لديك، ولهذا يبدو الانقطاع تلقائيًا.
يمكنك مراقبة ذلك في نحو دقيقة. اتصل، ودوّن عنوان النفق في تفاصيل اتصال العميل، ثم اقطع الاتصال، واتصل بجهاز ثانٍ، ثم أعد اتصال الأول. العنوان الذي ستحصل عليه يعتمد على ما يحتفظ به الجهاز الثاني، ولا إعداد في البوابة سيعيد العنوان السابق عند الطلب.
قاعدة NSG المبنية على IP العميل هي في الحقيقة قاعدة على ترتيب الاتصال
القاعدة التي يكتبها الناس أولًا هي البديهية: قاعدة واردة على NIC لجهاز الإدارة الافتراضي أو على شبكته الفرعية، مع عنوان عميل VPN الداخلي كمصدر. إنها قصيرة، وتنجح في الاختبار يوم كتابتها، وتفشل بمجرد أن يضم التجمع أكثر من عنوان حر واحد.
ينتج عن ذلك نمطا فشل، وواحد فقط منهما يبدو كخلل. يُرفض مستخدم شرعي لأن شخصًا آخر يحمل الآن العنوان الذي تسمّيه القاعدة، فيصل ذلك كتذكرة دعم مزعجة. أو يُسمح لمستخدم غير مقصود لأنهم ورثوا عنوانًا لا تزال القاعدة تثق به، فلا يصل أي شيء حتى يدقّق أحد الوصول.
ولأن القاعدة تتبع الإيجار، فإن السياسة الفعلية تقول «أول من يتصل يحصل على وصول إداري». هذا وصف لترتيب الاتصال في ثوب نيّة، ولا مقدار من نظافة القواعد يجعله يعبّر عن نيّة.
إيجار العميل وعنوان البوابة كائنان مختلفان
معظم الالتباس يأتي من كلمة واحدة. للبوابة عنوان IP عام مستقر نسبيًا؛ وللعملاء عناوين خاصة من التجمع ليست كذلك. في بوابة VPN غير المقاومة للمناطق، يُخصّص العنوان العام ديناميكيًا، لكنه يصمد أمام تغيير الحجم وإعادة الضبط والصيانة الروتينية — يتغيّر عندما تُحذف البوابة نفسها وتُعاد إنشاؤها. أما فئات البوابة المقاومة للمناطق والمناطقية فتستخدم IP عامًا من فئة Standard، ويجب أن يكون ذلك التخصيص ثابتًا.
هذا الاستقرار هو ما يحتاجه النظير المحلي في إعداده، ولا يقول شيئًا عن تحديد هوية عميل فردي. عندما يسأل شريك ما العنوان الذي سيراه، فالجواب هو IP العام للبوابة في site-to-site، أو نطاق NAT مشترك — لا إيجار النفق لحاسوب محمول.
تجمعات المجموعات تمنحك نطاقًا يستحق كتابة القواعد تجاهه
يدعم point-to-site في Virtual WAN مجموعات المستخدمين، ويمكن تخصيص تجمع عناوين عملاء خاص لكل مجموعة. تُحدَّد العضوية بالهوية، فيصبح النطاق الذي يهبط فيه العميل متوقعًا: العمليات في نطاق، والمتعاقدون في آخر، والنطاق شيء يمكن لقاعدة جدار حماية أو NSG أن تسمّيه دون تخمين.
مجموعة القواعد الناتجة لها شكل يمكن مراجعته:
- تجمع واحد لكل جمهور، بحجم يكفي ذروة الجلسات المتزامنة لا عدد الأفراد؛
- عضوية المجموعة تُدار بالهوية، لا بتعديل القواعد كلما انضم أحد؛
- قواعد NSG أو Azure Firewall مكتوبة تجاه نطاقات التجمع، لا تجاه الإيجارات الفردية أبدًا؛
- مركز أو بوابة منفصلة للجمهور الذي يجب ألا يتشارك نطاقًا أبدًا.
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
إدراج التجمع بأكمله في قائمة السماح صادق لكنه فظ: كل عميل متصل في ذلك النطاق يحصل على الوصول نفسه. ذلك قرار سياسة يستحق أن يُقال بصوت عالٍ بدل أن يُكتشف أثناء مراجعة. وأي شيء لا يزال يحتاج جوابًا لكل شخص ينتمي إلى المورد، عبر تعيينات الأدوار، لا إلى مرشّح الحزم.
عندما لا يستطيع النشر الانتقال إلى Virtual WAN
كثير من البوابات تبقى بوابات VPN عادية، والانتقال إلى Virtual WAN ليس تغييرًا هينًا. الجواب العملي هو نقل قرار كل مستخدم من مرشّح الحزم إلى شيء يعرف أصلًا من هو المستخدم.
الهوية على مستوى المورد هي أرخص نسخة. Storage وSQL وKey Vault كلها تدعم مصادقة Entra ID مع تعيينات أدوار لكل مستخدم أو لكل مجموعة، فيكفي أن يثبت VPN إمكانية الوصول الشبكي. ومضيف قفز بحسابات مسمّاة يؤدي المهمة نفسها للعمل الإداري، لأن المضيف يسجّل الإنسان والنفق ينقل الحزم فقط. وتسجيل العملاء في DNS وإدراج الاسم بدل الرقم في قائمة السماح ينقل القاعدة طبقة إلى الأعلى. وهوية طبقة التطبيق — موضوع شهادة، أو ادّعاء رمز، أو عضوية مجموعة — تنجح عندما يكون التطبيق، لا الشبكة، هو من يُطلب منه أن يقرر.
أما الشريك الذي يصرّ على عنوان مصدر ثابت، فالجواب هو site-to-site أو ExpressRoute ببادئة نظير محددة. يضعون بادئة النظير في قائمة السماح، والعنوان الذي يظهر عندهم يخص البوابة، ولا يتغيّر عندما يعيد أحد تشغيل حاسوب محمول.
افحص التجمع قبل أن تعدّل قائمة سماح أخرى
خاصيتان في التجمع تسببان معظم السلوك الذي يلوم الناس عليه العميل. التجمع الصغير جدًا يعيد تدوير الإيجارات سريعًا، فتبدو العناوين متحركة باستمرار وتبدو أي قاعدة مبنية على العنوان متقلبة بطبيعتها. والتجمع المتداخل مع النطاقات المحلية أو مع فضاء الشبكة الظاهرية يخلق غموضًا في التوجيه لا تصلحه أي قاعدة جدار حماية.
ضع ثلاثة أشياء في صفحة واحدة قبل لمس أي قاعدة: تجمع point-to-site، وفضاء عناوين الشبكة الظاهرية، والنطاقات المحلية. يجب ألا تتداخل، ويحتاج التجمع مساحة لكل عميل متزامن مع هامش لإعادة الاتصال.
ثم أغلق الحلقة بهذا الترتيب:
- اتصل من جهازين بالترتيبين ووازن العناوين؛ فإن كان بإمكانهما التبادل، فلا قاعدة مبنية على العنوان آمنة.
- تحقق مما إذا كانت البوابة Virtual WAN؛ فإن كانت كذلك، استخدم تجمعات المجموعات بدل قواعد لكل عنوان.
- اسأل ما يحدث عندما تطابق قاعدة الشخص الخطأ؛ فإن كان الجواب حادثة وصول، فانقل الضبط إلى الهوية.
- سجّل أي نطاق يخص أي مجموعة في المستودع نفسه الذي يحوي تعريفات NSG.
- أعد الاختبار بعد أي تغيير في التجمع أو المصادقة أو البوابة، لأن تلك التغييرات تعيد كتابة التعيين دون إعلان.