أين تراقب حركة عميل OpenVPN على البوابة

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

حدّد أي ترتيب تنظر إليه

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

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

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

اربط العنوان بجلسة أولًا

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

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

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

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

اقرأ جدول التدفق على بوابة موجِّهة

بعد تثبيت العنوان والفترة، تُظهر قائمة للقراءة فقط بالاتصالات المتعقَّبة ما تمرره البوابة من أجله. رشّح على المصدر الأصلي حتى لا تقرأ الجدول كله.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

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

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

التقاط واحد محدود لتأكيد القراءة

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

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

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

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

سجلات الوكيل، وحدود ما رأيته

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

افحص إعدادات التسجيل في النسخة المنشورة بدلًا من افتراض أن كل طلب يُسجل افتراضيًا.

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