VPN الضيف وVPN المضيف: أي مسار يفوز فعلاً

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

سجّل ارتباط الضيف أولاً

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

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

تتبّع نقطة نهاية الضيف نحو الخارج

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

المسار الواسع في أي من السياقين يلتقط حركة مرور توقعها العميل الآخر. مسار 0.0.0.0/0 داخل الضيف وعميل مضيف بنفق كامل يطالبان بكل شيء، والأسبق تطبيقاً في النهاية هو من يفوز. التداخل بين الشبكات الافتراضية للضيف والشبكة المحلية والشبكات البعيدة ينتج الأثر نفسه للبادئات الخاصة، مع أعطال تشبه مشكلات المصادقة؛ وسلوك ترجمة العناوين هو نفسه الموصوف في شبكات الحاويات.

قارن سجلاً قبل التغيير وبعده

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

أبقِ الملكية واضحة عبر إعادات التشغيل

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

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