إعادة تعيين TCP لا تثبت أن VPN الخاص بك محجوب

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

إعادة التعيين حزمة، لا حكم

يحدد TCP معالجة إعادة التعيين: مقطع يحمل علم RST يُنهي الاتصال فورًا. والمستقبل لا يتفاوض ولا يعيد المحاولة ولا يسأل عن السبب. بل يبلّغ عن إعادة التعيين ويمضي.

هذا كل ما يعرفه العميل. قد تكون RST جاءت من الخادم أو وسيط أو جدار ناري أو موازن أحمال فقد حالته.

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

أكّد أي اتصال أُعيد تعيينه

تحقق أولًا من أن الملف الشخصي النشط يستخدم TCP فعلًا. إعادة تعيين على نفق UDP لا معنى لها، وسجل من وسيط HTTP قد يتعلق بجزء TCP مختلف عن VPN نفسه.

سجّل الوجهة والمنفذ ووقت المحاولة والمرحلة التي وصل إليها العميل.

المرحلة هي الحقل الأكثر فائدة. إعادة تعيين أثناء مصافحة TLS تشير إلى مجموعة مشتبهين؛ وإعادة تعيين بعد المصادقة تشير إلى مجموعة أخرى. وبدون المرحلة تنطبق كل نظرية.

قارن طرفي المسار

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

التقط عند العميل وعند الخادم إن أمكن. إعادة تعيين تظهر عند العميل ولا تظهر عند الخادم لم تنشأ عند الخادم.

راقب مقاطع RST في الاتجاهين:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

ضيّق النطاق بمقارنة مضبوطة

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

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

حافظ على التمييز بين «هذا المسار يفشل» و«هذا الفاعل المسمّى تسبب فيه». الأول قابل للاختبار؛ والثاني عادةً ليس كذلك من عميل واحد.

تحقق من الإصلاح دون تغيير إعدادات الثقة

لا تعطّل التحقق من TLS، ولا تعِد توليد بيانات الاعتماد، ولا تعلن سياسة حجب بناءً على سطر إعادة تعيين واحد. كل تغيير من هذه يغيّر النظام قيد الاختبار ويجعل المقارنة التالية بلا معنى.

أصلح المكوّن المحدد عبر مالكه، ثم أعد الملف نفسه والملاحظة نفسها:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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