المستخدمون البعيدون لا يستطيعون الوصول إلى الموقع الثاني عبر مركز VPN

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

المرور يحتاج إلى ثلاث عمليات بحث، لا إلى نفق واحد

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

لهذا فإن اختبار كل نفق على حدة يثبت القليل جداً. فاختبار عنوان LAN الخاص بالمركز بالـ ping يمارس القرار الأول، واختبار المركز من المقر الرئيسي يمارس الثالث. أما الحزمة التي تفشل فمصدرها تجمع المستخدمين ووجهتها الموقع الثاني، لذا اكتب هاتين البادئتين أولاً. هنا التجمع هو 10.80.0.0/24، وشبكة LAN الخاصة بالمركز هي 10.10.0.0/24، والمقر الرئيسي هو 10.20.0.0/24.

ادفع البادئة البعيدة إلى العميل البعيد

على خادم وصول بعيد OpenVPN يتعلم العميل المسارات عند الاتصال. وبدون دفع، يرسل عميل النفق المنقسم 10.20.0.50 إلى بوابته الخاصة، ولا تدخل الحزمة النفق أبداً.

push "route 10.20.0.0 255.255.255.0"

المسار المدفوع يصل عندما يتصل العميل، لذا لا يرى المستخدم الذي يبقى متصلاً شيئاً حتى يعيد الاتصال. تحقق على العميل: ip route get 10.20.0.50 على Linux، و route print على Windows. وينبغي أن يسمّي الناتج واجهة النفق.

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

أعطِ المركز مسار خروج حقيقياً

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

حيث يكون مسار الموقع إلى الموقع نفسه OpenVPN، يمكن أن يقيم المسار في ذلك التكوين مع عنوان نفق النظير كبوابة: route 10.20.0.0 255.255.255.0 172.30.0.2. والبوابة ليست اختيارية. فإن أغفلتها سقطت القفزة التالية إلى افتراضي في التنفيذ يختلف بين عميل ذي مصدر بعيد واحد ومركز متعدد النظير.

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

مدّد الجانب البعيد إلى تجمع المستخدمين

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

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts عند جهاز ما هو remote_ts عند الآخر. انسخ كتلة المركز إلى المقر الرئيسي فينقلب الزوج، فلا يصعد اتحاد الأمان الفرعي أبداً.

صيغة ipsec.conf الأقدم تستخدم leftsubnet مفصولاً بفواصل. يحتفظ اتحاد الأمان العامل بالمحدِّدات التي تفاوض عليها، لذا أعد إنشاء النفق بعد التعديل. فمحدِّد غُيّر في 10:00 واختُبر مقابل اتحاد أمان صعد في 09:40 يظل يفشل، بينما يبدو ملف التكوين صحيحاً طوال الوقت.

ثم افحص القفزة الأخيرة. ip route get 10.80.0.25 على الطرف البعيد ينبغي أن يشير إلى النفق. وإذا كانت الخدمة تستخدم موجّه LAN كبوابتها الافتراضية، فالموجّه يحتاج مسار العودة كذلك، وإلا مات الرد هناك. وتشغيل tcpdump -ni eth1 host 10.80.0.25 على ذلك المقطع يُظهر ما إذا كان الرد قد غادر الطرف أصلاً.

اسمح بالتدفق عند المركز

يجب تمكين التمرير والسماح بالمسار. وحدّد القواعد للبادئتين بدل قبول كل شيء بين الواجهات.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

تصفية مسار العودة هي الإخفاق الصامت المجاور: فمع وجود الضلعين على واجهتين مختلفتين، قد يُسقط rp_filter=1 الرد بينما لا يتحرك عدّاد قاعدة القبول أبداً. قارن iptables -vnL FORWARD قبل المحاولة وبعدها. القاعدة التي لا تزيد أبداً لا تُبلَغ، فلتنظر طبقةً أدنى بدل إعادة كتابتها.

إذا كان فريق واحد فقط يحتاج المرور، فضع المسار في ملف لكل عميل تحت client-config-dir بدل توسيع الدفع العام. كما أن NAT المصدر على المركز يزيل الحاجة إلى مسار عودة على الجانب البعيد، لكنه يخفي عنوان المستخدم، فتتوقف سجلات الموقع البعيد والقواعد المبنية على العناوين عن التمييز بين المستخدمين.

تحقق من العميل، ثم تراجع بالعكس

اختبر منفذ TCP، لا ICMP فقط، لأن ping قد يمر بينما تبقى الخدمة محجوبة. nc -vz 10.20.0.50 445 و traceroute -n 10.20.0.50 من العميل يُظهران ما إذا كانت القفزة الثانية هي عنوان نفق المركز. وعلى المركز، tcpdump -ni tun0 host 10.20.0.50 والمرشح نفسه على واجهة الموقع إلى الموقع: طلب على كليهما بلا رد على أيهما ينقل المشكلة إلى الجانب البعيد.

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

احتفظ بقائمة تراجع، لأن أربعة كائنات تغيرت وثلاثة منها يسهل نسيانها: المسار المدفوع، ومسار المركز، والمحدِّدات، وقواعد جدار الحماية. تراجع عنها بالعكس، وأعد إنشاء اتحاد الأمان، ودع مستخدماً واحداً يعيد الاتصال. فالتراجع الجزئي يترك مساراً يشير إلى نفق لم يعد مطابقاً، وهو أصعب قراءةً من الصمت الأصلي. و دليل OpenVPN 2.6 يوثّق push و route و iroute لإصدارك.