VPN للفرع عبر 4G: حافظ على ثبات الهوية عندما يتغير عنوان IP

ابدأ من الفرع نفسه، على صفحة حالة WAN في راوتر 4G. إذا كان العنوان الذي تراه يقع في النطاق الخاص بالمشغّل بدلًا من نطاق عام، فلن يسمح أي توجيه منافذ على ذلك الجهاز للمحور بالاتصال الوارد أبدًا، وسيتعين بناء النفق من الفرع نحو الخارج. هذه الملاحظة الواحدة تحدد التصميم. أما بقية العمل فهي التأكد من أن المحور يتعرف على الفرع بشيء أفضل من عنوان يتغير كل بضع ساعات.

من أين يجب أن يبدأ النفق

افحص العنوان مقابل فضاء العناوين المشترك الذي يستخدمه المشغّلون لـ NAT الخاص بهم، 100.64.0.0/10، ومقابل النطاقات الخاصة العادية. رؤية أحدها على وصلة متنقلة تعني عادةً أن NAT على مستوى المشغّل يقع بين الفرع والإنترنت، وأن الاتصالات الواردة غير متاحة بأي ثمن يستطيع الفرع دفعه. وعندما يكون عنوان WAN عامًا لكنه متغير، فلديك مشكلة أخرى أسهل.

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

افصل العنوان الذي تتصل به عن الهوية التي تطابقها

يحتاج المحور إلى شيء ثابت يُعثر عليه عنده، عنوان ثابت معتمد أو اسم مضيف مُصان. ويحتاج الفرع إلى طريقة ثابتة للتعرف عليه، وهي في IKEv2 حمولة الهوية التي يقدمها أثناء المصادقة، بصرف النظر عن عنوان المصدر الذي تحمله حزمه. سلسلة مثل @branch-a.vpn.example تصلح كهوية حتى مع تغير العنوان المتنقل كل ساعة.

تطابق تلك السلسلة ضد السياسة، ولا تُحل عبر DNS، فلا تتوقع حدوث استعلام عند إنشاء النفق. يجب أن يسمّي إعداد المحور الهوية المتوقعة صراحةً، ومع مصادقة الشهادات يجب أن تتوافق الهوية أيضًا مع ما تؤكده الشهادة فعليًا.

قبول أي هوية لأن عنوان المصدر يبدو معقولًا هو نمط الفشل الذي يجب تجنبه. على المستجيب يعني ذلك قبول أي نظير، ببطاقة هوية عامة وسر مشترك، وهو ما يصادق على سلسلة لا على جهاز.

اكتب جانب المحور كنظير مسمّى

بمصطلحات strongSwan، جانب المستجيب هو اتصال يحمل right=%any، الذي يقبل نظيرًا من أي عنوان مصدر، بالإضافة إلى [email protected]، الذي يثبّت ما يجب أن يدّعيه ذلك النظير. أضف rightsubnet=10.20.0.0/16 لشبكات LAN الفرعية، و auto=add ليُحمَّل الاتصال دون طلب، و dpd_delay=30s للحيوية، و mobike=yes ليُستوعب تغير العنوان بدلًا من معاملته كنظير جديد.

يعبّر بائعو آخرون عن الكائنات نفسها بأسماء مختلفة، عادةً نوع نظير ديناميكي أو لنظير مكتب فرعي بحقل هوية وحقل شبكة فرعية محمية. املأهما معًا؛ ومربع اختيار ديناميكي عام ليس خطة توافق.

أبقِ الفرع هو المبادر

على الفرع تنطبق الصورة المعكوسة: left=%defaultroute ليُستخدم عنوان المتنقل المحلي كما هو حاليًا، و [email protected] لتقديم الهوية، و right=hub.example.com لاسم المحور الثابت، و auto=start ليصعد النفق دون تدخل بشري. وعندما تعيد الوصلة المتنقلة الاتصال، يبدأ الفرع من جديد ويطابق المحور الهوية نفسها ضد كائن السياسة نفسه.

اسمح بـ IKE على UDP 500، وبعبور NAT على UDP 4500، وبـ ESP المغلف الذي يليه، على الجانبين. ثم اتركها مسموحة: فقاعدة تُفتح فقط خلال ساعات العمل ستبدو نفقًا متقطعًا.

اختبر تغيير العنوان، لا المصافحة الأولى فقط

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

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

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