ما يمكن لجدار حماية الشركات أن يراه داخل VPN وما لا يمكنه
قد يحجب جدار الحماية نفقًا ومع ذلك لا يقرأ ما بداخله. افحص ما تكشفه الترويسة الخارجية، وهل ينطبق فحص TLS، وتحقّق من السلسلة.
الحاسوب نفسه يصل إلى VPN من المنزل ولا يستطيع الاتصال من المكتب، إذن لا بد أن أحدًا يقرأ حركة المرور. الحجب والقراءة سلطتان منفصلتان، والثانية وحدها تحتاج موضعًا على المسار وشهادة يثق بها العميل. الصندوق الوسيط الذي يُسقط مصافحتك لم يتعلّم شيئًا عمّا كنت سترسله. تحديد أيّ الاثنين تواجهه هو المهمة كلها.
الحجب والقراءة سلطتان مختلفتان
الرفض رخيص وواضح: يُفتح المقبس ولا يجيب شيء، أو يصل إعادة تعيين فورًا. لا شيء من ذلك يعني الفحص، لأن أي حِمل لم يعبر السلك.
القراءة تحتاج نقطة نهاية تنهي الحماية، وتُثبت نفسها بشهادة، وتبدأ اتصالًا جديدًا إلى الأمام. تلك النقطة يجب أن تكون على المسار وأن يثق بها العميل. جدار الحماية الذي يمرّر الحزم فقط لا يملك موقعًا ولا اعتمادًا.
ما يمنحه الغلاف مجانًا
لكل حزمة نفق خارج، والخارج يجب أن يكون قابلًا للتوجيه. هذا يعني عنوانين وبروتوكولًا ومنفذًا وطولًا، إضافة إلى التوقيت والحجم. أي موجّه يتعامل أصلًا مع تلك الحقول، وترجمة العناوين NAT تعيد كتابة العنوان والمنفذ لتبقي جدول تعيينها متناسقًا. يبقى الحِمل مغلقًا، فتتوقف الملاحظة عند حقيقة وجود نفق بين مضيفين.
اسم المضيف ليس من بينها. تتسرّب المواقع عبر أبواب أخرى، وأوسعها DNS: إذا كان الحاسوب لا يزال يسأل المُحلّل المحلي، تظهر الأسماء في العراء.
التوقيت والحجم يستحقان الاحترام دون مبالغة. بايتات في الدقيقة يمكن أن تُظهر نقلًا كبيرًا يبدأ عند 14:20؛ ولا يمكنها أن تُظهر أي ملف انتقل. هذا كشف حقيقي عن السلوك، وفئة مختلفة عن قراءة المحتوى.
اعتراض TLS يحتاج جذرًا تثق به أصلًا
الجهاز الفاحص لا يكسر TLS؛ بل ينهيه. يجيب العميلَ شهادةٌ من جذر تملكه المؤسسة، ويذهب اتصال ثانٍ إلى الوجهة الحقيقية. يقبل العميل ذلك لأن ذلك الجذر موجود في مخزن ثقته، ولهذا لا يُظهر حاسوب مُدار أي تحذير. لم تُهزم التشفير قط؛ بل نُقلت نقطة النهاية.
لهذا أيضًا يترك هذا الترتيب أدلة. المصدر على السلسلة المعروضة يخص المؤسسة لا سلطة شهادات عامة، ويستطيع العميل رؤية ذلك دون أدوات خاصة. السلسلة التي تنتهي عند جذر داخلي هي بصمة الاعتراض، لا خلل.
لماذا قناة VPN ليست جلسة HTTPS
قناة بيانات VPN لا تمنح الفاحص موطئ قدم كهذا. يشغّل IKEv2 وWireGuard مصافحاتهما وجداول مفاتيحهما، دون TLS لإنهائه، بينما OpenVPN يستعير TLS لقناته التحكمية بصيغة معدّلة قبل أن يحمي البيانات بطريقته. الوكيل المبني لـ HTTPS لا يتعرّف على تلك الجلسة كشيء يستطيع تحليله.
الجهاز الذي لا يستطيع تحليل جلسة يستطيع مع ذلك إسقاطها. لهذا يبدو حجب VPN عادةً كأنه مهلة لا كتحذير شهادة، ولهذا لا يغيّر الاستثناء شيئًا.
التحقق من جهازك
ابدأ بالسلسلة التي يعرضها الموقع. تفاصيل الموقع في المتصفح تُظهر المصدر، وسطر الأوامر يبلّغ الشيء نفسه دون الملخص:
openssl s_client -connect example.com:443 -servername example.comثم افصل المصافحة المرفوضة عن الحركة الداخلية المفلترة بالعدادات. سجّل منفذ النقل قبل أي قاعدة إسقاط واقرأها بعد المحاولة:
iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbersغياب أي سطر سجل عند المقبس الخارجي يعني أن المصافحة لم تخرج قط، فالمسار يرفض النفق. المصافحة المكتملة مع فشل بعض الوجهات فقط تعني أن النفق يعمل وأن السياسة داخله لا تعمل. لم يتطلب أي من النتيجتين قراءة بايت واحد من الحِمل.
القراءة التي تحدث فعلًا تقع عند الأطراف: النفق المنقسم يسلّم HTTPS الداخلي لوكيل الشركة، والمركّز المملوك لصاحب العمل يكشف كل شيء عند المخرج. ومهما وجدت، لا تُعطّل التحقق من الشهادة لإجبار اتصال، لأن ذلك الفحص هو الشيء الوحيد الذي يفصل الفحص عن المهاجم.