جهاز واحد عبر VPN الراوتر يحتاج إلى ثلاث قواعد، لا إلى مفتاح تبديل

لا يوجد مفتاح منفصل لكل جهاز على VPN الراوتر؛ فالزر الذي تبحث عنه هو اختصار يكتب نيابة عنك قواعد توجيه السياسات. فبمجرد أن يضطر حاسوب محمول واحد، أو نطاق منافذ واحد، أو قائمة عناوين واحدة، أو مقطع شبكة محلية واحد إلى استخدام النفق بينما يبقى كل ما عداه على WAN، فأنت تبني مسار سياسة لا تشغّل ميزة. وللمهمة ثلاثة أجزاء متحركة، وكل جزء يفشل بطريقته: جدول موسوم بلا مسار يشبه الصمت، ووسم يُطبَّق في السلسلة الخطأ يبدو كأن شيئًا لم يحدث، وقاعدة NAT المفقودة تبدو كنفق يتصل ولا يحمل شيئًا. وهناك جزءان آخران يضيعان لأنهما لا يظهران أبدًا في قاعدة mangle، وهما DNS وIPv6.

الوهم: النفق إعداد في العميل

يفعل عميل VPN على جانب الراوتر شيئًا واحدًا فظًا بإتقان: يضع 0.0.0.0/0 في جدول التوجيه الرئيسي ويوجهه إلى النفق. يستنتج WireGuard ذلك من AllowedIPs، ويستنتجه OpenVPN من redirect-gateway مدفوع، وكلاهما يغيّر المسار لكل مضيف خلف الراوتر. تضييق AllowedIPs أو إضافة route-nopull يغيّر ما يثبّته العميل. لكنه لا يغيّر على من ينطبق التثبيت، لأن العميل لا يرى الأجهزة أبدًا. إنه يرى الحزم فقط.

اختيار المصدر أو الوجهة قرار توجيه، لذا ينتمي إلى طبقة السياسات في الراوتر: قاعدة mangle مع جدول ثانٍ على RouterOS، أو MARK مع ip rule على OpenWrt أو DD-WRT، أو قاعدة جدار ناري تكون بوابتها هي النفق على pfSense. وصفة عميل WireGuard من Netgate هي ما يجب قراءته قبل التخمين، لأن بوابة القاعدة وتعيين الواجهة وإدخال NAT الصادر كلها يجب أن تتفق قبل أن يستخدم عميل واحد النفق.

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

الجزء الأول: نفق ليس المسار الافتراضي

على RouterOS، أضف العميل دون مسار افتراضي وامنح النفق جدوله الخاص. المسار الأول هو الافتراضي الموسوم؛ والثاني هو نصف الفشل.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

المسار غير القابل للوصول هو سبب تفوق جدول موسوم على قائمة استثناءات في الجدول الرئيسي. فعندما يسقط النفق، تتلقى الحزم الموسومة «غير قابل للوصول» فورًا بدلًا من التراجع بهدوء إلى WAN، فيظهر الفشل في رسالة خطأ التطبيق بدلًا من صفحة تحديد موقع تراجعها بعد ساعة.

يقسم RouterOS 7 ما أبقاه 6.x مجتمعًا: تصرّح بالجدول عبر /routing table add name=vpn fib، ثم تشير إليه بالاسم في المسار وفي قاعدة mangle. أما مقتطف 6.x الذي يضع routing-mark ضمنيًا دون تعريف الجدول فيُحمَّل بنظافة ولا يطابق شيئًا. والحالة الكلاسيكية الأخرى هي نصفا 0.0.0.0/1، أو افتراضيان على المسافة نفسها في جدول واحد: تختار النواة أحدهما، وقد يتغير السلوك بعد إعادة التشغيل.

الجزء الثاني: الوسم قبل البحث في المسار

المحدد يقرر أي الحزم تدخل ذلك الجدول. يبدأ RouterOS عادة بقائمة عناوين لسياسة الوجهة، أو بعنوان مصدر لسياسة الجهاز:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

تفعل برامج Linux الثابتة الشيء نفسه بوسم netfilter وقاعدة توجّه الحزم الموسومة إلى جدول ملأته:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

السلسلة ليست خيار أسلوب. فحين تصل الحزمة إلى FORWARD يكون البحث في المسار قد حدث بالفعل، لذا لا يمكن لـ MARK أو DROP هناك إلا أن يعيد الكتابة أو يتجاهل. يجب أن يقع الوسم في PREROUTING لحركة المرور المعاد توجيهها وفي OUTPUT لحركة المرور التي ينشئها الراوتر نفسه، وهي حيث يعيش DNS وNTP وفحوص التحديث في الراوتر. وهذا المسار الصادر هو السبب المعتاد في أن إعدادًا منفّقًا بالكامل ما زال يجيب من محلل ISP في اختبار تسرب.

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

الجزء الثالث: NAT وDNS واستثناء الشبكة المحلية

حركة المرور الخارجة عبر النفق تحتاج إلى عنوان مصدر يجيب عليه الجانب البعيد. احصر الترجمة في واجهة النفق: out-interface=VPN_NAME على RouterOS، و-o tun0 على Linux، وإدخال NAT صادر مطابق على pfSense. وقاعدة masquerade بلا هذا الحصر تعيد كتابة حركة كنت تقصد تركها وشأنها، والعَرَض أن الجهاز غير المنفّق يفقد عنوانه العام.

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

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

عندما تطابق القاعدة لكن التطبيق ما زال يستخدم WAN

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

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

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

تحقق بجهازين وإعادة تشغيل

اختبر الجهاز الذي ينبغي أن يكون منفّقًا والجهاز الذي لا ينبغي، وقارن القفزة الثانية بدلًا من رقم سرعة. يُظهر traceroute من كل منهما إما بوابة النفق أو بوابة ISP عند القفزة الثانية؛ فإن تطابق الاثنان، فالوسم أو الجدول لا يفعل ما تقوله القاعدة. استخدم اتصالات جديدة للاختبار.

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

إذا فشل شيء، أزل الوسم أولًا وانظر هل تعود حركة المرور الطبيعية، ثم أزل الجدول. هذا الترتيب يخبرك هل تطارد مشكلة توجيه أم مشكلة جدار ناري، ويترك المنزل بطابعة عاملة بينما تنهي المهمة.