Azure نقطة إلى موقع يتصل لكن لا يستجيب أي مورد خاص
الاتصال يعني فقط أن النفق قام. افحص ما يمكن للبوابة حمله، وقارن فضاءات العناوين، ثم حلّ اسمًا واختبر الخدمة نفسها.
الاتصال حالة من حالات النفق، وليس تصريحًا بإمكانية الوصول. يمكن لعميل نقطة إلى موقع أن يُنهي IKE ويحصل على عنوان ومع ذلك لا يصل إلى شيء، لأن البوابة لا تمرر إلا حركة الشبكات التي يعرفها VNet مسبقًا. نفّذ هذه الفحوص الخمسة بالترتيب وتوقّف عند أول إخفاق. القفز إلى الأمام هو كيف يُعالَج مشكل DNS على أنه مشكل جدار حماية لمدة ساعة.
الترتيب أهم من القائمة.
الفحص 1: حدّد ما يُفترض أن يحمله النفق
تُنهي Azure VPN Gateway النفق وتمرر الحركة التي تنتمي إلى VNet؛ فهيليست مخرجًا عامًا إلى الإنترنت. إذا كان المستخدمون يتوقعون أن يخرج تصفحهم عبر Azure، فالتصميم خاطئ قبل أن يدخل أي إعداد للعميل في الصورة. فعّل النفق المنقسم split tunneling ليبقى الإنترنت المحلي على المسار المحلي، واستخدم نسخة NAT أو نفق موقع إلى موقع عندما يكون عنوان الخروج الثابت مطلوبًا فعلًا.
اكتب ما يجب أن يصل إليه العميل قبل أن تختبر أي شيء. بدون تلك القائمة، تبدو كل نتيجة جزئية كأنها تقدّم.
الفحص 2: قارن فضاءات العناوين قبل الشهادات
يُحكم على التداخل بالنطاقات الأوسع، فشبكتان تبدوان مختلفتين على مستوى الشبكة الفرعية تتصادمان إذا تداخلت كتلتاهما الأب. يجب أن تكون الشبكة الفرعية للبوابة مخصصة وكبيرة بما يكفي لـ SKU، ويجب ألا يتصادم تجمّع عناوين العميل مع VNet أو مع أي شيء يمكن الوصول إليه عبر peering. غيّر الخطة وأعد النشر، لأن إضافة مسارات للتعويض تُنتج نفقًا يعمل مع بعض الوجهات ولا يعمل بشكل غير مفهوم مع غيرها. يفشل التزويد هنا بصوت عالٍ، وهذه هي الحالة الجيدة.
المصادقة هي البوابة التالية. ملفات الشهادات وRADIUS وEntra ID ليست قابلة للتبادل، وحزمة العميل تختلف لكل منها.
الفحص 3: حلّ اسمًا خاصًا من الداخل
يحتفظ العميل بمحلله الخاص ما لم يكن الملف الشخصي الذي جرى تنزيله يحمل خوادم DNS الخاصة بـ VNet، وتُضمَّن تلك القائمة وقت التنزيل. أضف مُمرِّرًا داخل VNet، واضبطه كخادم DNS للـ VNet، ثم نزّل حزمة العميل واستوردها مرة أخرى. إعادة استخدام الحزمة القديمة تختبر قائمة المحلل القديمة فقط.
اختبر عنوانًا أولًا، لأنه يفصل التوجيه عن التسمية في خطوة واحدة: Test-NetConnection 10.20.1.4 -Port 3389.
إذا استجاب العنوان ولم يستجب الاسم، فاسأل المحلل مباشرة بـ Resolve-DnsName files.corp.example -Server 10.20.0.4. وإذا فشل الاثنان، فالعطل ليس في DNS وعليك التوقف عن تعديل إعدادات DNS. إن DNS الخاص بمنصة Azure على 168.63.129.16 لا يجيب إلا من داخل VNet، لذا لا يمكن لعميل خارجها استخدام ذلك العنوان كمحلل.
الفحص 4: اختبر الخدمة خلف النفق
النفق السليم والمنفذ المغلق يبدوان متطابقين من جهة العميل. افحص جدار حماية الضيف، ثم مجموعة أمان الشبكة على الشبكة الفرعية أو NIC، ثم ما إذا كانت الخدمة تستمع على العنوان الخاص بدل الاستماع على loopback فقط. اسمح لتجمّع العميل كمصدر بدل فتح قاعدة نحو الإنترنت، وتذكّر أن SMB إلى Azure Files يحتاج مسار نقطة النهاية الخاصة عبر النفق. عندما يستجيب مورد عبر IP وليس عبر الاسم، ارجع إلى الفحص 3 بدل لمس البوابة.
جدول واحد يفصل الطبقات أثناء عملك:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
الفحص 5: سجّل الملف الشخصي قبل التصعيد
ضع نوع البوابة ونوع النفق وطريقة المصادقة ونظام تشغيل العميل في التذكرة. ملف IKEv2 بشهادة وملف RADIUS يفشلان لأسباب مختلفة، والعميل المبني لنوع نفق آخر لا يتصل إلا عندما تقدم البوابة بروتوكولًا متوافقًا.
لفريق صغير، التصميم المتين هو VNet واحد ومُمرِّر DNS واحد وعميل split tunneling موثّق. إذا كان الشرط خروجًا عامًا ثابتًا، فأنهِ نفق موقع إلى موقع على جدار حماية تتحكم به ووجّه حركة الإنترنت هناك بدل مطالبة بوابة نقطة إلى موقع بفعل شيء لم تُبنَ له أصلًا.