OpenConnect vpnc-script: أي ملف يشغّله العميل فعلاً؟

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

برنامجان ومسؤوليتان

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

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

حدّد المساعد الذي يستخدمه العميل العامل

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

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

إذا كان سطر العملية يحمل وسيط --script ، فإن ذلك الملف يتغلب على الافتراضي المدمج. ومسارات أقدم مثل /etc/vpnc/vpnc-script قد توجد وتبقى غير مستخدمة، ولهذا فإن حذفها أو تعديلها لا يغيّر شيئاً في بناء حديث. تحقق من تاريخ التعديل أيضاً، لأن مساعداً لم يمسّه أحد لسنوات دليل قوي على أن الافتراضي المحزَّم هو الذي يقوم بالعمل.

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

اقرأ أول عملية فاشلة، لا آخر تحذير

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

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

تحقق من الاتصال وإعادة الاتصال وفصل الاتصال

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

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

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

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