لا يزال WireGuard يستخدم نقطة النهاية القديمة بعد تغييرات DNS

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

يُحلّ الاسم مرة واحدة، لا باستمرار

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

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

قارن السجل بالعنوان المستخدم

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

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

توثّق دليل wg(8) الأوامر الفرعية show التي تستخدمها هذه الأسطر. قارن عائلة العنوان بالإضافة إلى العنوان، لأن سجلًا اكتسب مدخل IPv6 يمثل مقارنة مختلفة عن سجل تغيّر عنوان IPv4 فيه. إذا اختلفت نقطة النهاية عن السجل، فإن الواجهة تعمل بمعلومات قديمة ولم يكن الاسم هو المشكلة أبدًا. وإذا تطابقا وظل النفق يفشل، فانتقل إلى المستمع والقواعد لا إلى الملف الشخصي.

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

أعد التشغيل عبر مدير الواجهة

بعد تأكيد أن نقطة النهاية قديمة، حدّثها عبر الآلية التي تملك الواجهة بدلًا من تحرير الإعداد الحيّ. بالنسبة لواجهة بدأها wg-quick فهذا إيقاف وتشغيل، وبالنسبة لوحدة systemd فهو إعادة تشغيل، وبالنسبة لواجهة يملكها مدير فهو تغيير يُجرى في ذلك المدير، لأن التحرير أثناء التشغيل يُستبدل عند التطبيق التالي:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

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

المصافحة أولًا، ثم مسار البيانات

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

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