محول OpenVPN يتذبذب على Windows؟ ابحث عن عنوان IP مكرر

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

هذا الفرق مهم، لأن كل خطوة استكشاف أخطاء تستهدف إعداد النفق ستغفل عن عنوان مكرر على جانب الخادم.

ابدأ من سجل أحداث Windows، لا من سجل العميل

يسجّل Windows تعارضات العناوين في سجل النظام، بمعرّفي الحدث 4198 و4199. الأول يبلّغ عن تعارض مكتشف لعنوان، والثاني يبلّغ عن أن واجهة لم تستطع استخدام العنوان الذي ضُبطت به. لا يذكر أي منهما OpenVPN، وهذا بالضبط سبب سهولة إغفالهما.

اسحب الأحداث الأخيرة وقارن طوابعها الزمنية بدورة تجديد المحول: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. تعارض كل خمس عشرة ثانية يوافق عميلًا يعيد محاولة العنوان نفسه لدى مالك يستمر في الإجابة عنه. أما التعارض الواحد عند وقت الاتصال فيشير إلى تصادم عابر. في الحالتين، السؤال التالي هو من يحمل العنوان غيره.

ثلاثة ترتيبات تضع مضيفين على عنوان واحد

اسأل الخادم عمّن يعتقد أنه يحمل العنوان، ثم اسأل الشبكة عمّن يجيب عنه. grep -H ifconfig-push /etc/openvpn/ccd/* يسرد كل عنوان نفق مثبّت والشهادة التي ينتمي إليها. ip -4 neigh show dev tap0 يعرض ما تعلمه الجسر في الطبقة الثانية. ومقارنة هاتين القائمتين تكشف معظم التكرارات في أقل من دقيقة.

ثلاثة ترتيبات تفسّر معظمها: مدخل client-config-dir يثبّت عنوانًا واحدًا لشهادتين، أو مقطع tap موصول بجسر يمنح جهازًا عنوانًا يملكه مضيف آخر بشكل ثابت، أو ملف تأجير قديم يعيد عنوانًا يعتقد عميل ما زال متصلًا أنه يملكه. الحالة الثالثة هي الأخفى، لأن ifconfig-pool-persist يعيد استخدام العناوين عمدًا للعملاء المعروفين.

اجعل العنوان فريدًا بدلًا من التسابق عليه

ترتيب الإقلاع يحدد الفائز اليوم فقط، لذا عامل أي إصلاح يعتمد على تسلسل إعادة التشغيل على أنه مؤقت. امنح كل عميل سطر ifconfig-push الخاص به، أو خصّص عناوين ثابتة من نطاق لا تمسه أي واجهة جسر أو خادم. راجع قائمة العملاء بحثًا عن أسماء شائعة مكررة أيضًا، لأن duplicate-cn يسمح لجلسين بمشاركة هوية واحدة وبالتالي عنوان واحد مثبّت. وإذا كان جهاز موصول بجسر يحتاج حقًا عنوانًا ثابتًا، فانقله إلى شبكته الفرعية أو احجزه من البِرك في مكان يسجّله الخادم.

لا تحذف ملف persist إلا بعد أن تعرف أي تأجيرات يحتفظ بها، وإلا فستوزع إعادة الاتصال التالية العناوين نفسها مرة أخرى.

أعد التشغيل بالترتيب الصحيح وأكّد مالكًا واحدًا لكل عنوان

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

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

راقب دورة تجديد كاملة قبل إغلاق التذكرة

قراءة نظيفة واحدة لا تثبت شيئًا. راقب المحول عشر دقائق على الأقل وافرض إعادة اتصال في المنتصف: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. يجب أن يصمد العنوان عبر إعادة الاتصال ويبقى في حالة مفضّلة.

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

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