لماذا لا يغيّر VPN من نقطة إلى موقع في Azure عنوان IP العام لديك
نفق النقطة إلى الموقع لا يحمل إلا مسارات الشبكة الظاهرية، لذلك يبقى عنوان IP العام لديك محليًا حتى تنقل الأنفاق القسرية وSNAT الخاص بالجدار الناري حركة الخروج إلى Azure.
أوصل عميل Azure VPN على حاسوب محمول يعمل بـ Windows، وأفتح صفحة لصدّ العنوان، فأرى العنوان العام نفسه الذي وزّعه موجه منزلي. وفي الوقت نفسه يستجيب صندوق القفز على 10.20.0.4 ويُحلّ اسم نقطة نهاية خاصة، فالنفق ليس معطلًا. بوابة النقطة إلى الموقع تفعل بالضبط ما يقوله إعدادها الافتراضي: تحمل البادئات الخاصة وتترك كل ما عداها على الرابط المحلي. الحصول على عنوان خروج مملوك لـ Azure هو تغيير في تصميم التوجيه، لا إصلاح.
ما تعلنه البوابة افتراضيًا
تدفع البوابة مسارات لمساحة عناوين الشبكة الظاهرية، إضافة إلى الشبكات النظيرة حيث يُسمح بمرور البوابة، والبادئات المحلية المتعلَّمة عبر اتصال موقع إلى موقع أو BGP. لا يوجد 0.0.0.0/0 في تلك المجموعة. يحتفظ نظام التشغيل لديك بمساره الافتراضي على Wi-Fi أو Ethernet، لذلك لا تدخل حزمة متجهة إلى API عام النفق أصلًا.
العنوان الذي يتلقاه العميل داخل النفق هو إيجار خاص من مجمع النقطة إلى الموقع. يعرّف العميل أمام الموارد في VNet؛ وهو ليس عنوانًا يمكن للإنترنت رؤيته، ولن يظهر أبدًا كمصدر لطلب صادر إلى API لخدمة SaaS. ولا يمكن لقيد في قائمة سماح مبني حول ذلك الإيجار أن يعمل، مهما انتظرت ظهوره في سجلات المورّد.
النفق المنقسم والأنفاق القسرية جنبًا إلى جنب
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
الصف الثاني وحده هو ما يغيّر العنوان الذي تراه خدمة بعيدة. وكل ما عداه في ذلك الجدول تكلفة وسطح تشغيلي تقبله عندما يجب فحص حركة الخروج أو ترجمتها داخل Azure. وإذا طلب منك أحدهم أن تجعل عنوان IP العام يتغيّر، فهو يطلب العمود الأيمن بأكمله، لا تعديلًا في العميل.
هناك خيار وسط يستحق التسمية قبل أن تعيد بناء أي شيء. آلة ظاهرية تعمل كوكيل أو بوابة داخل VNet تمنحك عنوان مصدر مضبوطًا للتطبيقات التي يمكن توجيهها إليه، دون تحريك المسار الافتراضي للعميل. هذا يبقي التصفح العادي محليًا ويرضي شريكًا لا يحتاج إلا إلى وصول استدعاء API واحد من Azure. ويفشل عندما يكون الشرط متعلقًا بكل حركة المرور فعلًا، لأن أي شيء يتجاهل إعداد الوكيل يخرج محليًا أيضًا.
اجعل النفق يحمل المسار الافتراضي
على بوابة شبكة ظاهرية، الطريقة المدعومة لتوجيه كل حركة إنترنت العميل إلى النفق هي إضافة مسارات مخصصة إلى إعداد النقطة إلى الموقع. نصفان يغطيان فضاء IPv4 كله، وكل واحد منهما أكثر تحديدًا من المسار الافتراضي المحلي، لذلك يفضّله العميل دون حذف أي شيء:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1ذلك السطر للتوضيح لا للنسخ واللصق الكامل: اجلب كائن البوابة أولًا باستخدام Get-AzVirtualNetworkGateway واستبدله بـ GWOBJ، وتأكد من أن SKU ونموذج النشر يقبلان المسارات المخصصة قبل تشغيله. تظهر البادئات نفسها في البوابة على صفحة إعداد النقطة إلى الموقع، وهي المكان الأكثر أمانًا لضبطها إن لم تكن تكتب البوابة برمجيًا أصلًا.
تغيير تلك البادئات يبطل حزمة العميل. نزّل حزمة عميل VPN مرة أخرى وأعد تثبيتها، لأن المسارات تسافر داخل ملف التعريف. والعميل الذي يعيد الاتصال بملفه القديم يحتفظ بمجموعة المسارات القديمة، وقد تخسر ساعة في تصحيح تغيير لم يصل إليه قط.
في مركز WAN ظاهري مؤمّن يكون المكافئ مسارًا افتراضيًا في جدول مسارات المركز المرتبط ببوابة النقطة إلى الموقع، مع أخذ Azure Firewall في المركز للحركة. يترجم الجدار الناري الاتصالات المتجهة إلى الإنترنت إلى عناوين IP العامة الخاصة به، ومن تلك الترجمة يأتي عنوان الخروج الجديد. وعندما يملك الجدار الناري عدة عناوين IP عامة، يمكن أن يظهر أي منها كمصدر، لذا يجب أن تحتوي قائمة السماح عليها كلها.
كلا التصميمين أعلاه IPv4. والبادئتان /1 لا تفعلان شيئًا لـ IPv6، ودعم النقطة إلى الموقع لـ IPv6 ضيق بما يكفي لأن تختبر المزيج قبل أن تعِد بالتماثل.
تحقق من المسار، ثم من المخرج
بعد إعادة تثبيت الحزمة وإعادة الاتصال، تأكد من أن العميل ثبّت النصفين فعلًا. على Windows، يجب أن يسمّي Get-NetRoute -DestinationPrefix 0.0.0.0/1 والاستعلام نفسه لـ 128.0.0.0/1 واجهة النفق، ويُظهر route print كليهما بجانب المسار الافتراضي الأصلي. على Linux، يجب أن يسرد ip route show البادئتين؛ وإن لم يفعل، فلم يحملهما ملف التعريف قط.
ثم أعد فحص العنوان العام من العميل واقرأ سجل الجدار الناري للاتصال نفسه. ينبغي أن يكون المصدر عنوان IP العام للجدار الناري مع منفذ مترجَم. أما عميل لا يزال يخرج محليًا مع وجود المسارين معًا، فمعناه أن الحزم وصلت إلى Azure وغادرت عبر طريق آخر: مسار معرّف من المستخدم على شبكة البوابة الفرعية، أو جدار ناري هو نفسه في نفق قسري إلى الموقع المحلي، أو سياسة تُسقط التدفق قبل الترجمة.
أعد اختبار وجهة خاصة واحدة في الجلسة نفسها. مضيف قفز يتوقف عن الاستجابة بعد التغيير هو العلامة المعتادة على أن البادئات الجديدة أزاحت شيئًا، إما مسار محلي أضيق كان يُعلن سابقًا أو تحليل أسماء يذهب الآن إلى محلل بلا مُمرِّر لمناطقك الخاصة.
متى تترك النفق المنقسم وشأنه
إذا كان الهدف مجرد الوصول إلى API خاص أو نقطة نهاية خاصة أو صفحة إدارة داخلية، فالسلوك الافتراضي أرخص وأهدأ. تضيف الأنفاق القسرية ساعات جدار ناري وتكاليف معالجة بيانات، ومسارًا أطول، ومكانًا آخر يمكن أن يفشل فيه كل تدفق عميل. كما تلتقط حركة مرور أكثر بكثير من الوجهة الواحدة التي كنت تهتم بها.
تلجأ إليها عندما يُصاغ الشرط من حيث الخروج: يجب أن يرى شريك عنوان Azure ثابتًا، أو تريد الأمن تسجيل الاتصالات وفحصها، أو يجب أن تغادر البيانات من نقطة مضبوطة واحدة. وحتى حينها يمنح التصميم كل مستخدم مخرجًا مشتركًا، لذا يجب أن تأتي مساءلة كل مستخدم من الهوية في التطبيق لا من عنوان المصدر.
قبل أن تغلق التغيير، تأكد من أربعة أمور: أن حزمة العميل المثبتة هي الجديدة، وأن مساري /1 على واجهة النفق، وأن وجهة خاصة ما تزال تستجيب، وأن سجل الخدمة البعيدة يُظهر عنوان الجدار الناري.