الخطوة التالية في مسار VPN: لماذا يجب أن تكون البوابة قابلة للوصول محليًا
يجب أن يكون عنوان via في المسار قابلًا للوصول على الرابط الذي ترسل منه. تتبَّع التسليم، وتحقق من البحث، واختبر من المضيف الذي يملك حركة المرور.
يحمل المسار إلى شبكة VPN عنوانين يسهل الخلط بينهما: بادئة الوجهة التي تحاول الحزمة الوصول إليها، والخطوة التالية التي ستنقلها خطوة أقرب. على مضيف LAN، يجب أن تكون تلك الخطوة التالية موجّهًا يمكنك الوصول إليه فعلًا على الرابط نفسه. عنوان VPN البعيد ليس خطوة تالية، مهما كان مطابقًا بدقة للوجهة التي في ذهنك.
يغطي هذا الدليل الحالة العادية: حاسوب محمول على 192.168.20.0/24، وبوابة VPN بعنوان LAN هو 192.168.20.5، وشبكة بعيدة 10.70.0.0/24 خلف تلك البوابة. تفترض كل الأوامر أدناه أنك على الحاسوب المحمول ما لم يُذكر خلاف ذلك.
عنوانان، مسار واحد
الإدخال المقصود هو 10.70.0.0/24 via 192.168.20.5. تحدد البادئة إلى أين تذهب الحزمة؛ ويحدد عنوان via من يحملها إلى هناك. ترفض النواة تثبيت مسار لا تستطيع الوصول إلى بوابته عبر الواجهة التي تسميها، وهذا الرفض هو جوهر الأمر: الخطوة التالية التي تحتاج إلى النفق لتكون قابلة للوصول لا يمكن أن تكون الخطوة التالية التي تبني النفق.
إذن الفحص الأول ليس «هل البوابة تعمل» بل «هل البوابة على هذا الرابط». يجب أن تتفق الشبكة الفرعية للحاسوب المحمول، وإدخال ARP أو الجار، والواجهة في المسار. العنوان الموجود داخل 10.70.0.0/24 فقط يمكن أن يكون وجهة لمسار ثانٍ، ولا يمكن أبدًا أن يكون via للمسار الأول.
ما تُلزم به الخطوة التالية البوابة
تثبيت المسار على الحاسوب المحمول يحدد التسليم الأول فقط. تحتاج البوابة بعد ذلك إلى مسارها الخاص: تمكين التمرير، ومسار نفق إلى 10.70.0.0/24، وأي سياسة وصول تحكم من يجوز له استخدامه. على Linux يكون ذلك net.ipv4.ip_forward=1 مع مسار نفق؛ وتحتاج جدار الحماية أمامه إلى قاعدة تسمح بالتدفق الممرَّر.
الاتجاه العكسي هو الجزء الذي ينساه الناس. يجب أن يكون لدى الجانب البعيد مسار عودة إلى 192.168.20.0/24، أو يجب أن يحوّل التصميم مصدر الحاسوب المحمول إلى شيء يعرفه الجانب البعيد. نجاح ping من البوابة يثبت أن البوابة تستطيع الوصول إلى الشبكة البعيدة؛ ولا يقول شيئًا عن نجاة حزم الحاسوب المحمول في رحلة العودة.
تحقق من البحث من المضيف الذي يرسل
اسأل النواة أي خطوة تالية ستختار، واقرأ الواجهة في الجواب:
ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5
إذا أبلغ البحث عن البوابة وواجهة LAN، فإن الساق الأولى مضبوطة كما هو مقصود. وإذا أبلغ عن جهاز النفق، فإن شيئًا أبكر في الجدول أكثر تحديدًا وهو الذي يفوز. وإذا رفض المسار التثبيت أصلًا، فالنواة تخبرك أن البوابة غير قابلة للوصول، وتلك الرسالة أنفع من أي التقاط حزم.
ثم كرر الاختبار من المكان الصحيح. الطلب الذي يُنشأ على البوابة يستخدم عنوان مصدر البوابة نفسه، وهذا قد يخفي مسار عودة مفقودًا أو سياسة تسمح بمصادر معينة فقط. دليل ip-route يفصل بين الوجهة والبوابة وتجاوز onlink، ويستحق التجاوز أن يُفهم قبل استخدامه.
لا تستخدم onlink لاصطناع إمكانية الوصول
يقول onlink للنواة أن تتخطى فحص إمكانية الوصول للبوابة وترسل إليها رغم ذلك. إنه لا ينشئ مسارًا، ولا يحل ARP لعنوان غير موجود، ولا يجعل موجّهًا بعيدًا يجيب على مقطع Ethernet الخاص بك. وهو مشروع للبوابات التي تجيب لكنها لا تقع في شبكة فرعية متصلة، وهو فخ حين يُستخدم لإسكات خطأ لم تشرحه.
إذا كان المسار يُثبَّت فقط مع onlink، فالسؤال التالي هو لماذا ليست البوابة حيث تظنها. VLAN خاطئ، أو عنوان ثانٍ على الواجهة الخاطئة، أو خطأ مطبعي في الثمانية الأخيرة، كلها تنتج هذا، وكل منها يكسر مسار العودة أيضًا بمجرد أن تبدأ الحركة بالتدفق.
أنفاق النقطة إلى النقطة ليست Ethernet
جهاز النفق لا يقوم بـ ARP وغالبًا ليس لديه شبكة فرعية ذات معنى من الجيران. مساراته تبدو غالبًا مثل 10.70.0.0/24 dev tun0، دون أي via، لأن النظير هو الطرف الآخر الوحيد. نسخ via على نمط LAN إلى ذلك الجدول ينتج مسارًا قد ترفضه النواة أو، الأسوأ، مسارًا يشير إلى عنوان لا يجيب عنه النظير أبدًا.
أبقِ النموذجين منفصلين في الدليل: مسار LAN له بوابة قابلة للوصول، ومسار النفق له واجهة ونظير. WireGuard و OpenVPN و IPsec تعرض جميعها أشكالًا مختلفة قليلًا، لذا سجّل الشكل الذي استخدمته فعلًا بدلًا من التعميم من مضيف واحد.
أضف، وأكّد، وتراجع
التغيير كله ثلاثة أوامر وفحص واحد، وينبغي كتابته بهذا الترتيب:
sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5
أكّد المسار، وأكّد وجهة واحدة، ثم أبقِ سطر الحذف جاهزًا في حال جعل التغيير المضيف غير قابل للوصول بطريقة لم تتوقعها. إذا كان على المسار أن يبقى بعد إعادة التشغيل، فضعْه في إعدادات شبكة المضيف بدلًا من ملف تعريف shell، واختبر إعادة التشغيل قبل الاعتماد عليه. المسار الذي يوجد فقط في الصدفة التي أضافته هو مسار ستصلحه مرتين.