هل النفق الكامل أبسط من قائمة طويلة لنفق منقسم؟
قائمة استثناءات تغطي معظم التطبيقات هي إعداد افتراضي متنكّر. عُدّ القواعد، وافحص البوابة، ثم انقل ملفًا شخصيًا واحدًا وتحقق من الحافتين.
تبدأ قائمة النفق المنقسم بثلاثة تطبيقات وتنتهي بتغطية معظم الجهاز، وكل سطر جديد هو استثناء يخص أحدهم. عند تلك النقطة أصبحت القائمة بهدوء إعدادًا افتراضيًا بخطوات إضافية. يعكس النفق الكامل هذا الترتيب: كل شيء يدخل النفق ما لم يقل استثناء موثَّق عكس ذلك. وهل ذلك أبسط يعتمد على البوابة وعلى الخدمات المحلية التي ستعطّلها.
ابدأ بعدّ القواعد التي تصونها
عُدّ المدخلات، ثم عُدّ كم منها له مالك مسمّى وتاريخ جرى التحقق فيه آخر مرة. الرقم الثاني هو المهم، لأن استثناءً لا يملكه أحد لا يمكن تقييمه عندما يُعاد تسمية البرنامج الذي يشير إليه أو يُستبدل. القواعد المرتبطة بمسار ملف تنفيذي تفشل بصمت بعد التحديث، ويبدو الفشل كأن الشبكة الخاصة غير مستقرة لا كأن القاعدة قديمة. اكتب القائمة قبل أن تكون لك رأي فيها.
ينبغي أن يجيب كل مدخل عن ثلاثة أسئلة: ما الذي ينكسر من دونه، ومن قرّر ذلك، وكيف ستلاحظ أن السبب انتهى. المدخلات التي لا تستطيع الإجابة عن الأسئلة الثلاثة كلها مرشحة للحذف لا للترحيل، وحذفها أولًا يجعل المقارنة اللاحقة صادقة.
إذا كانت معظم المدخلات توجّه حصة كبيرة من حركة المرور، فأنت تدير بالفعل نفقًا كاملًا مع عبء صيانة ملحق. يصبح القرار حينها في مكان وجود الإعداد الافتراضي، لا في وجوده من عدمه.
تحقق من قدرة البوابة على حمل الإعداد الافتراضي
ينقل النفق الكامل كل حزمة إلى جهاز واحد، ما يغيّر حمل المعالج في ذلك الجهاز وجدول conntrack وترجمة العناوين ومتطلبات النطاق الترددي الصاعد في الوقت نفسه. البوابة التي خدمت بهدوء شبكات داخلية قليلة قد لا تكون بمقاس تصفّح مستخدم كامل. انظر إلى أكبر عدد جلسات متزامنة تتوقعه لا إلى المتوسط، لأن الذروة هي ما ينكسر أولًا.
ip -s link show dev tun0
conntrack -C
ss -sقِس الحمل نفسه قبل التغيير وبعده بدلًا من الاستنتاج من المواصفات. بعد ظهيرة واحدة من الاستخدام العادي على جهاز واحد سيُظهر ما إذا كانت البوابة قريبة من حدّ ما، ولا يكلّف ذلك شيئًا مقارنة باكتشافه صباح يوم الاثنين.
افحص أيضًا وحدة MTU للمسار من طرف إلى طرف، لأن الإعداد الافتراضي الكامل يعرّض كل تطبيق لأكبر حجم حزمة في النفق. التطبيقات التي عملت خارج النفق قد تعتمد الآن على سلوك تجزئة لم تضطر إلى التفكير فيه قط.
تأكد من أن الخدمات المحلية وDNS الخاص ما زالا يعملان
أحصِ ما يجب أن يبقى محليًا حسب البروتوكول لا حسب اسم التطبيق: بروتوكولات الاكتشاف للطابعات والشاشات، وجسر منزل ذكي، وصفحة إدارة موجه، وخادم تطوير محلي يُوصل إليه باسم لا يُحلّ إلا على الشبكة المحلية. تنكسر هذه عندما يبدأ المسار الافتراضي في الإشارة إلى نفق، وتنكسر بصمت لأن شيئًا لا يسجّل خطأً عند العميل.
DNS الخاص هو الاعتماد الآخر. إذا كانت الأسماء الداخلية تُحلّ سابقًا عبر محلّل النفق فلا يتغير شيء؛ وإذا كانت تُحلّ محليًا فيجب أن يحملها الإعداد الافتراضي الكامل إلى محلّل يعرف المناطق. اختبر اسمًا داخليًا واسمًا عامًا بعد التغيير بدلًا من افتراض أن قائمة المحلّلات نجت.
اكتب الاستثناءات المحلية في الملف الشخصي الذي يملكها. الاستثناء المحفوظ في ذاكرة أحدهم فقط هو أول ما يفقده الترحيل التالي.
رحّل ملفًا شخصيًا واحدًا وتحقق من الحدود
غيّر الملف الشخصي من خلال إعداداته المالكة بدلًا من إضافة إعداد افتراضي جديد فوق مسارات يدوية خلّفتها تجارب سابقة. تلك المسارات المتبقية هي السبب المعتاد لترحيل يبدو ناجحًا ثم يتصرف بشكل غير متسق بعد يوم. أبقِ الملف القديم متاحًا ليكون التراجع اختيارًا لا إعادة بناء.
ثم تحقق من حدّين بشكل منفصل: أن الوجهات العامة والخاصة تعمل معًا، وأن الحركة غير المرغوبة لا تخرج خارج النفق. تحميل صفحة ناجح يثبت الأول ولا يقول شيئًا عن الثاني.
ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.comأعد الفحص بعد إعادة الاتصال وبعد انقطاع، لأن مفتاح الإيقاف الذي يحجب الحركة أثناء الانقطاع خاصية مختلفة عن مسار يُستعاد بشكل صحيح بعد ذلك. التصميم الأبسط هو الذي ما زال بإمكانك شرح تغطيته الحقيقية بعد أن يتغيّر تطبيق أو شبكة.