لماذا يعرض جدول توجيه VPN في Windows العنوانين 0.0.0.0/1 و128.0.0.0/1

اتصل بشبكة VPN على Windows وافتح جدول التوجيه، وستبرز لك مداخلتان: 0.0.0.0/1 و128.0.0.0/1. وهما ليستا خطأ مطبعيًا ولا تحلّان محل المسار الافتراضي. ويعتمد ظهورهما على خيار واحد في الملف الشخصي، والزوجان هما الطريقة التي يُبنى بها النفق الكامل وليس ميزة من ميزات النفق المنقسم. اقرأ الخيار والبادئة والواجهة معًا قبل تغيير سطر واحد.

ما الذي يثبّته خيار البوابة الافتراضية

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

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

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

التفكيك أرخص من الاحتفاظ ببوابة

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

عملاء آخرون يصلون إلى التصميم نفسه. ملف OpenVPN الشخصي مع redirect-gateway def1 يثبّت هاتين البادئتين بدلًا من حذف الافتراضي، وعميل Windows يتبع النمط للسبب نفسه في التوجيه.

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

أطول بادئة تفوز قبل أي مقياس

طول البادئة يحدد البحث قبل أي حقل آخر. أما المقياس فيكسر التعادل فقط بين مسارات لها البادئة نفسها، لذا يتغلب مدخل /1 على افتراضي /0 حتى لو كان مقياسه أسوأ. وربط الواجهة يحدد ما يتبقى عندما يشترك مساران في بادئة ويتعين على Windows اختيار المحوّل الذي يرسل الحزمة.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

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

اختر مالكًا واحدًا لبادئة المكتب

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

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

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

الملكية هي السؤال الذي يجيب عنه هذا القسم، لا الصياغة. مالكان لبادئة واحدة هو نمط الفشل الجدير بالتجنب.

تحقّق بوجهة، لا بموقع ويب

اختبر الوجهة التي يجب أن تعبر النفق، لا موقعًا يبلّغ عن عنوان خروج. Find-NetRoute يعيد المسار المختار وعنوان المصدر، فترى هل فازت بادئة المكتب أم الافتراضي الفيزيائي، ثم تفتح المشاركة نفسها.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

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

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