لماذا تتجاوز شبكة فرعية واحدة مسار VPN الافتراضي رغم ذلك

تُبدّل الـVPN إلى النفق الكامل، فيمتثل معظم حركة المرور، ثم يستجيب عنوان واحد مباشرةً — طابعة أو NAS أو مضيف عبور على 10.x. القراءة البديهية أن النفق يتسرّب، فتُخفّض المقياس على المسار الافتراضي ولا يتغيّر شيء. تلك المحاولة الفاشلة هي الدليل: المسار الافتراضي احتياطي وليس حكمًا. إن بحث التوجيه يأخذ أطول بادئة مطابقة قبل أن يقارن المقاييس أصلًا، لذا تظل /24 تفوز على /0 أيًّا كان الرقم الذي تعلّقه على أيٍّ منهما. وبعد أن يتضح هذا الترتيب، يكون «التسريب» عادةً مسارًا نصّبه أحدهم عمدًا، أو بادئة لم يقصد العميل تغطيتها.

ما الذي يَعِد به المسار الافتراضي فعلًا

يطابق 0.0.0.0/0 كل وجهة IPv4 بصفر من البتات المحدِّدة. وهو موجود كي يستطيع المضيف الوصول إلى أي شيء لا يصفه جدوله وصفًا أفضل. المسار إلى 192.168.1.0/24 يحمل 24 بتًّا مطابقة، لذا فهو يفوز للوجهة 192.168.1.40 قبل أن يقارن أحد المقاييس أو المسافة الإدارية أو أيًّا كان ما يسميه العميل حقل الأولوية. والقاعدة نفسها تسري في FIB الخاص بـLinux وجدول توجيه Windows ومكدس BSD خلف macOS.

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

أنصاف المسارات الافتراضية، أو لماذا قد يبدو الإدخال الافتراضي سليمًا

إن redirect-gateway def1 في OpenVPN هو المثال الأنظف. فبدلًا من حذف مسارك الافتراضي واستبداله، يضيف 0.0.0.0/1 و128.0.0.0/1. معًا يغطي الزوجان كل IPv4، وكل بادئة أطول من /0، وكلاهما يتغلب على مسار الموجّه الافتراضي مع إبقائه في مكانه. شغّل سرد المسارات بعد ذلك وستجد المسار الافتراضي الأصلي ما زال هناك، ما زال يشير إلى بوابتك؛ لكنه ببساطة لا يُختار أبدًا لوجهات الإنترنت.

يبلغ wg-quick من WireGuard النتيجة نفسها عبر التوجيه بالسياسات. فمع AllowedIPs التي تغطي 0.0.0.0/0، ينشئ جدوله الخاص، ويرسل الحزم المعلَّمة إليه، ويضيف قاعدة تتجاهل البادئة صفرية الطول في الجدول الرئيسي. يحتفظ الجدول الرئيسي بإدخاله الافتراضي، وتقرر القواعد أن جدول النفق يُستشار أولًا لحركة المرور التي تملكها الواجهة.

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

المقاييس تحسم التعادل، والبادئات تحسم الفائز

لا تُقارن المقاييس إلا بين المرشحين الذين يطابقون الوجهة بالقدر نفسه. على Linux، ip route get 10.20.5.9 يطبع الفائز مع جدوله، و ip route show table all يسرد المرشحين، بما في ذلك أي أنصاف افتراضية وأي جدول تشير إليه قاعدة. على Windows، Find-NetRoute -RemoteIPAddress 10.20.5.9 يعيد المسار المحدد وعنوان المصدر، بينما Get-NetRoute يعرض الجدول الخام — لكن التكلفة الفعلية هي مقياس المسار زائد مقياس الواجهة، لذا يمكن لمهايئ بطيء أن يخسر تعادلًا يبدو أنه يكسبه.

ثلاث حالات تغطي معظم ما ستراه:

• الوجهة نفسها، /24 مقابل /0: تفوز /24 بطول البادئة، مهما قالت المقاييس.
• الوجهة نفسها، بادئتا /24 بمقياسين مختلفين: يفوز المقياس الفعلي الأدنى.
• الوجهة نفسها، جدولان، أحدهما تختاره قاعدة سياسة: تختار القاعدة الجدول أولًا، وتحدث مقارنة البادئات داخله.

الحالة الثالثة هي حيث تنتهي معظم هذه التقارير. فقد ترسل قاعدة ip rule في Linux أو مرشّح حركة مرور VPN في Windows الترافيك إلى جدول لم يحتوِ قط على المسار الافتراضي للنفق، بينما يبدو الجدول الرئيسي سليمًا طوال الوقت.

من يملك هذا التجاوز عادةً

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

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

ثم افحص IPv6 على حدة. إن ip -6 route و Get-NetRoute -AddressFamily IPv6 تحتفظان بحالة منفصلة ومسارات افتراضية منفصلة وسلوك عميل منفصل. تدقيق IPv4 فقط لا يقول شيئًا عن مضيف مزدوج المكدس يفضّل بهدوء مسار IPv6 أصليًا، وهذا وحده قد يجعل العميل يبدو منقسم النفق.

أكّد من خلال تدفّق التطبيق نفسه

سجّل الوجهة التي يستخدمها التطبيق فعلًا، ثم اسأل النظام عن المسار الذي سيسلكه من عنوان المصدر الذي يرتبط به ذلك التطبيق. ip route get 10.20.5.9 from 192.168.1.40 يجيب عن ذلك على Linux؛ Find-NetRoute -RemoteIPAddress 10.20.5.9 مع العنوان المحلي يفعل ذلك على Windows. قارن النتيجة بما يدّعيه الملف الشخصي. صفحة IP العامة في المتصفح تختبر وجهة واحدة على بروتوكول واحد ولا تقول شيئًا عن العنوان الخاص الذي بدأ الشكوى.

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

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

• سمِّ الوجهة وعنوان المصدر الذي يستخدمه التطبيق فعلًا.
• اطبع المسار الفائز باستخدام ip route get أو Find-NetRoute.
• تحقق مما إذا كان زوج /1 أو جدول سياسة يملك مسار الإنترنت.
• اسرد كل بادئة أطول من /0 تطابق الوجهة.
• كرّر فحص IPv6 بشكل منفصل.
• تتبّع المسار الباقي إلى الملف أو الملف الشخصي أو المرشّح الذي يثبّته.
• أعد الاتصال وأعد تشغيل الاستعلام قبل اعتباره مُصلحًا.

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