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

اقرأ النواة، لا تسمية الحالة

النفق الذي يبلّغ عن اتصال ثبّت ارتباطًا فرعيًا واحدًا على الأقل، وليس بالضرورة الذي تتوقعه. على Linux تُظهر النواة ما يُطبّق: ip xfrm policy يسرد أزواج المحدّدات، ويعرض swanctl --list-sas (أو ipsec statusall الأقدم) ما تفاوض عليه الطرفان، بما في ذلك محدّدات الحركة في كل اتجاه. إن لم تظهر البادئة الجديدة في أي منهما فهي غير محمية مهما قال ملف الإعداد.

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

الأنفاق القائمة على السياسة: يجب أن يسرد الطرفان البادئة الجديدة

في مصطلحات strongSwan يعيش المحدّد في local_ts وremote_ts ضمن إعداد الفرع، وهما خلفا leftsubnet وrightsubnet. يجب أن تظهر البادئة الجديدة على الطرفين متطابقة بالانعكاس: ما يسميه الموقع A محليًا يسميه الموقع B بعيدًا. ونادرًا ما ينتج عدم التطابق خطأ واضحًا؛ فالطرفان يضيّقان إلى التقاطع، فيبقى القديم يعمل ويفشل الجديد بصمت.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

في pfSense أو OPNsense يعني ذلك إدخال Phase 2 ثانٍ يقرن الشبكة المحلية الجديدة بالشبكة البعيدة الجديدة ثم تطبيق. أبقِ الإدخال القديم؛ استبداله ينقل الشبكة الأصلية بدل أن يضيف إليها. وإن كان Phase 2 قائم يغطي شبكة فائقة مثل 0.0.0.0/0 أو نطاقًا مجمّعًا، فلا تضف إدخالًا أضيق بجانبه: المحدّدات المتداخلة تثبّت سياسات متنافسة، وترتيب التقييم يحدد الفائز.

يجعل IKEv1 كل زوج شبكات Phase 2 خاصًا به، والطرف الذي يأخذ زوجًا واحدًا لكل تبادل يُسقط الباقي. ويستطيع IKEv2 حمل عدة أزواج محدّدات في فرع واحد، لكن فقط إذا قبلتها التنفيذتان. القائمة من swanctl --list-sas هي الحقيقة، وما كتبته طلب.

الأنفاق القائمة على المسار: المسار هو السياسة

واجهة XFRM أو جهاز VTI يحمل الحركة وفق جدول التوجيه. توجّه البادئة الجديدة إلى الجهاز في الموقعين، وتُطبّق الحالة المرتبطة بتحويل الواجهة. لا يوجد زوج محدّدات للمزامنة، ولهذا يتوسّع هذا التصميم أفضل مع تكاثر الشبكات الفرعية. يشرح دليل إعادة التوجيه في strongSwan جانب النواة بمزيد من التفصيل.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

يذهب WireGuard أبعد في الفكرة نفسها. AllowedIPs هو قائمة السماح التشفيرية و، عبر wg-quick، إدخال جدول التوجيه في الوقت نفسه. أضف البادئة على طرف واحد فقط فتحصل على مصافحة وحزم صادرة وصمت، لأن الطرف البعيد يُسقط الحزم التي ليس مصدرها في قائمة سماحه. صيغة wg set تستبدل القائمة كاملة، فأعد ذكر البادئات التي كانت تعمل وإلا قطعتَها:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

ذلك الأمر الثاني ليس اختياريًا عندما استخدمت wg set بدل wg-quick. تقبل النواة قائمة السماح الجديدة فورًا، لكن لا شيء يضيف مسارًا لها، فتبقى الحركة المولّدة محليًا تخرج عبر البوابة الافتراضية. وهو السبب الأكثر شيوعًا لعمل شبكة WireGuard جديدة من مضيف النفق لا من حاسوب محمول.

مسار العودة يفشل أكثر من النفق

على مضيفي الشبكة البعيدة الجديدة إرسال الردود عبر بوابة VPN. وحين لا تكون تلك البوابة موجّههم الافتراضي يذهب الرد إلى موجّه الشبكة المحلية، الذي إما يُسقطه أو يمرّره إلى الإنترنت بعنوان مصدر خاص. اختبر من مضيف في الطرف البعيد لا من البوابة: ip route get 10.30.20.15 على Linux أو Find-NetRoute -RemoteIPAddress 10.30.20.15 في PowerShell يُظهر القفزة التالية التي سيستخدمها المضيف فعلًا. وإن لم يكن الجواب نقطة نهاية النفق، أضف مسارًا ثابتًا للبادئة الجديدة هناك.

ترجمة العنوان المصدري في الموقع الذي يفتقد مسار العودة بديل مشروع، وهو كيف تتجنب كثير من عمليات hub-and-spoke لمس كل خادم. طبّقها على البادئة الجديدة في بوابة جهة الوجهة أيضًا:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

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

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

احسم بثلاثة أسئلة ثم تحقق بالحركة

النسخة السريعة: هل يسمّي إعداد الطرف البادئات (قائم على السياسة)، أم تتوجّه الحركة إلى واجهة (قائم على المسار)؟ هل يسرد الطرفان البادئة الجديدة؟ هل يوجد مسار عودة من الشبكة الجديدة إلى نطاق المصدر الأصلي؟

Tunnel styleWhere the prefix goesWhat breaks if you skip it
Policy-based IPsecSelector pair on both peersOld subnets work, the new one fails with no clear error
Route-based XFRM or VTIRoute into the device on both sitesPackets routed but not transformed, or the state never matches
WireGuardAllowedIPs on both peers plus a routeHandshake succeeds, replies are dropped
Overlapping supernetAdjust the existing entry insteadA shadowed policy wins or loses by evaluation order

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

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

في نفق قائم على السياسة يجب أن ترتفع عدادات ip xfrm state في الاتجاهين؛ العدادات الثابتة تعني أن الحزمة موجّهة لكن غير مختارة. وفي WireGuard يعرض wg show النقل لكل طرف، والمصافحة بصفر بايتات مستلمة تشير إلى قائمة سماح الطرف البعيد أو مسار عودته.

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

مقالات ذات صلة