عنوانان عامان على جهاز Azure VPN واحد: ما وظيفة كل منهما

يخلق وجود عنوانين عامين على جهاز Azure VPN واحد توقعًا نادرًا ما يتحقق: أن يكون العنوان الذي يتصل به العملاء هو نفسه العنوان الذي تراه المواقع. تصدر هذه النتيجة عن ثلاثة قرارات مستقلة، ولا يتعلق منها إلا الأول بمستمع النفق. والثاني هو مصدر الضيف المستخدم لحركة العميل المُمرَّرة، والثالث هو أسلوب الخروج في Azure المطبق على ذلك المصدر. غيّر أحدها فيبقى الاثنان الآخران كما هما، فقرر كل واحد منها صراحةً.

القرار 1: أين ينتهي النفق

يرتبط عنوان IP العام في Azure بتكوين IP خاص على بطاقة الشبكة NIC، وليس عنوانًا تضيفه داخل نظام تشغيل الضيف. اقرأ الارتباط بدل افتراضه: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. وأي عنوان خاص يعيده ذلك الاستعلام فهو العنوان الذي يجب أن يحمله الضيف فعليًا.

يمكن لبطاقة NIC واحدة أن تحمل عدة تكوينات IP، لذا لا يتطلب عنوانان عامان بطاقتين. وإذا استخدم التصميم بطاقتين فعلًا، فكل واحدة تجلب مسارات الضيف والقفزات التالية الخاصة بها، وتكون قد أضفت قرار توجيه بدل أن تبسطه.

بالنسبة لخدمة ذات ارتباط محلي صريح، اربط بالعنوان الخاص الحقيقي للضيف، لا بعنوان العنصر النائب العام. المستمع الذي يقبل كل العناوين يستقبل الحركة عبر كل تكوين IP يصل إليه، لذا قيّد الدخول بمجموعة أمان الشبكة وجدار حماية المضيف بدلًا من الاعتماد على ترتيب الارتباط.

القرار 2: أي مصدر يستخدمه العميل المُمرَّر

بعد أن يفك البوابة تشفير طلب العميل، تكون الحزمة التي يمررها مختلفة عن الحزمة التي وصلت إلى مستمع VPN. يحتاج الضيف إلى تمكين التمرير، وسياسة جدار حماية تسمح بالتدفق، وعنوان مصدر يسمح به تصميم السحابة. وإذا ترجمت عنوان العميل الداخلي، فإن ذلك المصدر المترجم هو ما ستقيّمه Azure، لا العنوان الداخلي للعميل.

يمكن لقاعدة SNAT ضيقة أن تختار مصدرًا خاصًا بالضيف، لكنها لا تستطيع تجاوز ترجمة لاحقة في Azure. اختر SNAT عندما تحتاج إلى مساءلة لكل عميل داخل الجهاز الافتراضي؛ وتجاوزها عندما يوفر تصميم الخروج في الشبكة الفرعية مصدرًا عامًا مستقرًا، فأي ترجمة ثانية لن تضيف إلا حالة.

القرار 3: أي أسلوب خروج في Azure يفوز

توثق Microsoftترتيب أسبقية الخروج: المسار المطبق إلى جهاز أو بوابة يأخذ الأولوية، واتصال NAT Gateway في الشبكة الفرعية يأخذ الأولوية على عنوان IP عام على مستوى المثيل في المسار المعني. ولهذا الترتيب فإن الترجمة إلى 10.20.0.5 لا تثبت أن الموقع سيرى 198.51.100.20. اقرأ جدول التوجيه الفعلي وارتباط NAT Gateway وعنوان IP العام لبطاقة NIC معًا قبل أن تقبل تصميم الخروج.

أبقِإعداد التمرير في بطاقة Azure NICمنفصلًا عن التمرير في Linux. تسمح علامة السحابة بالحزم التي لا يكون مصدرها أو وجهتها معينًا لبطاقة NIC؛ وهي لا تفعّل net.ipv4.ip_forward، وإعداد الضيف لا يمنح إذن السحابة.

لمقبس النفق قرار المصدر الخاص به

يعيّن Address في WireGuard ضمن wg-quick عنوانًا لواجهة WireGuard، وليس تعليمة ربط UDP خارجية. يتبع مصدر المقبس المشفر جدول التوجيه، لذا يمكن لمسار سياسة أو مسار افتراضي ثانٍ أن ينقله دون لمس عنوان الواجهة. أماOpenVPNفخياره local وmultihome عبر UDP يتصرفان بالطريقة نفسها: يتعلقان بالمستمع وردوده، لا بمصدر الإنترنت لكل عميل مُمرَّر.

حافظ على مسار الطبقة الأساسية الذي يحمل النفق، وتأكد من أن العميل ما زال يتلقى ردودًا موثقة من ترتيب المدخل المتوقع. لا تعتمد على ترتيب قائمة العناوين كسياسة دائمة لاختيار المصدر، لأن العنوان التالي الذي يضاف إلى بطاقة NIC قد يغيّر أي عنوان يفوز.

ما الذي تقبله، وبأي ترتيب

اقبل ثلاث نتائج منفصلة. أولًا، يصل عميل خارجي إلى مدخل VPN المقصود. ثانيًا، يغادر طلب جديد مسموح به من ذلك العميل عبر مخرج الإنترنت الموثق. ثالثًا، تبقى مسارات المستمع والتمرير غير المقصودة مرفوضة. سجّل مطابقات العنوان العام إلى الخاص ومالكي كل قرار من جانب الضيف والسحابة في المكان نفسه.

لا يثبت النفق الناجح إلا الجزء الأول. اختبر الخروج بتدفق جديد، لأن اتصالًا مخزنًا في ذاكرة التخزين المؤقت قد يظل يستخدم المصدر القديم بعد تغيّر المسار بوقت طويل.