هل يصمد مفتاح الإيقاف في VPN بعد إعادة التشغيل؟ وكيف تتحقق من ذلك

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

إعادة التشغيل تطرح ثلاثة أسئلة منفصلة

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

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

اعثر على الشيء الذي يعيد تطبيق الحجب

على لينكس تعيش قواعد netfilter في النواة. لا شيء يعيد كتابتها عند الإقلاع إلا إذا رتّبت ذلك: iptables-save بالإضافة إلى netfilter-persistent، nftables.service يُحمّل /etc/nftables.conf، أو وحدة systemd تشغّل سكربتك الخاص. تحقق مما هو مُفعّل بدلًا مما تتذكر أنك أعددته.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

الأمر الثاني يكتب wfpstate.xml في الدليل الحالي. ابحث عن مرشحات ذات إجراء حجب موجودة مسبقًا قبل أن يتصل العميل. يبدأ محرك التصفية الأساسي مبكرًا في الإقلاع ويعيد المرشحات التي أُضيفت بالعلامة الدائمة، ولهذا تحجب بعض مفاتيح الإيقاف المرور قبل وجود أي نافذة عميل وأخرى لا تفعل. على ماك أو إس، sudo pfctl -s info يخبرك ما إذا كان pf مفعّلًا، sudo pfctl -s rules يُظهر ما هو محمّل، وعادةً تربط عملاء VPN قواعدهم بمرساة بدلًا من مجموعة القواعد الرئيسية. قاعدة تسمّي utun3 يمكن أن تشير إلى واجهة مختلفة بعد الإقلاع التالي، لأن ذلك الرقم يُعطى وقت التشغيل.

راقب الفجوة بين صعود الشبكة وصعود النفق

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

على مضيفي systemd، اقرأ الترتيب بدلًا من تخمينه. شغّل systemctl cat على وحدتي VPN وجدار الحماية وابحث عن After= أو Before= مقابل network-pre.target و network-online.target. وحدة جدار حماية مرتّبة بعد network-online.target تخسر أمام الواجهة؛ أما الوحدة التي تُطلب من network-pre.target وتُرتّب قبله، تفوز. على ويندوز الأسئلة المكافئة هي نوع بدء الخدمة واعتمادياتها، لأن خدمة مضبوطة على Manual لا يمكنها حجب عملية وقت الإقلاع. إذا تضمن شرطك مرورًا قبل تسجيل الدخول، فلا يفي به إلا ترتيب على مستوى الجهاز: نفق جهاز Always On VPN يتحقق بشهادة جهاز ويتصل قبل أن يسجل المستخدم الدخول، و توثّق مايكروسوفت تهيئة نفق الجهاز بشكل منفصل عن نفق المستخدم. يأخذ أندرويد الطريق الآخر، فيفرض VPN الدائم ويحجب الاتصالات بدونه من النظام بدلًا من عملية تطبيق.

شغّل الاختبار، ثم قارن خطين زمنيين

أعد التشغيل مع وجهة لا تكلف شيئًا إذا تسربت، والتقط الحالة خلال الفجوة بدلًا من بعدها. أنظف طريقة هي مسبار وقت الإقلاع: وحدة oneshot أو مهمة مجدولة تبدأ بأبكر ما تسمح به المنصة، وتسجل المسار الافتراضي وحالة جدار الحماية، وتحاول طلبًا واحدًا بمهلة قصيرة وتضيف سطرًا إلى ملف محلي. قارن ذلك السجل بوقت بدء خدمة VPN من journalctl -b -u أو سجل النظام.

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

أغلق الفجوة دون أن تقطع طريق عودتك

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

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

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