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

ما يلي إجراء قرار لا ورقة بناء. كل خطوة تنتهي بفحص يثبت أن الدور الذي أضفته للتو معزول فعلاً.

اختر مالك العنوان قبل المنافذ

يمكن لنقطة نهاية نفق وخادم ويب أن يتشاركا نواة واحدة؛ مشاركة عنوان واحد ومنفذ وبروتوكول واحد في الوقت نفسه هي ما يفشل. عادةً يأخذ WireGuard المنفذ UDP 51820، OpenVPN يأخذ UDP 1194 أو TCP 443، وخادم الويب يأخذ TCP 443. الثنائي المؤلم هو OpenVPN عبر TCP 443 بجوار HTTPS، لأن كليهما يريد المقبس نفسه والنواة تسلمه لمن يرتبط أولاً. ولا يسمح لهما بمشاركة ذلك المنفذ إلا مفكك تعدد إرسال في المقدمة، مثل sslh أو وكيل يدرك TLS، وهو يضيف مكوناً يبدو عطله تماماً كمشكلة جدار حماية.

انظر إلى المالكين قبل أن تغيّر أي شيء: ss -lntup يطبع العنوان المحلي والمنفذ والعملية لكل مقبس يستمع. صفّان يعرضان 0.0.0.0:443 يعنيان أن الخدمة الثانية لم ترتبط قط، مهما كان سكربت التهيئة الخاص بها مبتهجاً. الجسر ينقل المالك أيضاً. عندما eth0 ينضم إلى br0، ينتقل عنوان IP إلى br0 وكل قاعدة جدار حماية تذكر eth0 تتوقف عن المطابقة، لذا اربط الخدمات على الجسر وتأكد باستخدام ip -br addr.

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

التوجيه بين الشبكتين المحليتين أو NAT لجهة واحدة

يمكن لشبكتين محليتين لا ترى إحداهما الأخرى أن تطلبا المضيف العام، الذي يمرر بعد ذلك بين النفقين. يحتاج هذا التصميم الموجّه إلى ثلاثة أمور: تفعيل التمرير، ومسار يشير إلى كل بادئة بعيدة، وسياسة تمرير تسمح بالعبور. sysctl -w net.ipv4.ip_forward=1 يغطي الأول، ip route add 10.20.0.0/24 dev wg1 الثاني، وسطر nftables مثل nft add rule inet filter forward iifname "wg0" oifname "wg1" accept الثالث.

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

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

اختبر الفصل بينما يكون دوران متوقفين

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

ثلاثة أوامر تجعل ذلك الاختبار ملموساً. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ يثبت أن المستمع المحلي يجيب دون DNS خارجي، wg show على العميل يثبت أن المصافحة اكتملت، و tcpdump -ni any port 51820 على المحور يفصل مشكلة التوجيه عن مشكلة المفتاح. مصافحة لا تظهر أبداً في الالتقاط ماتت قبل المضيف: جدار حماية المزود، أو عنوان عام خطأ، أو قاعدة NAT في الطريق.

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

أبقِ مجموعة القواعد قابلة للقراءة أثناء طرح الأدوار. nft list ruleset يجب أن تعرض قاعدة قبول واحدة لكل اتجاه تحتاجه فعلاً، وسلسلة تمرير تقبل كل شيء ليست فصلاً، بل عرض عملي.

خطوط وصول IPv6 فقط وخدمات IPv4

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

اختبر كل عائلة على حدة باستخدام curl -4 و curl -6، لأن طلباً ناجحاً واحداً لا يقول شيئاً عن المسار الذي لم تجربه. ملكية المنافذ لا تتغير بين العائلات، لكن المستمع يتغير: ss -lntup يعرض مقابس IPv4 وIPv6 كصفوف منفصلة، و 0.0.0.0:443 لا يغطي [::]:443 ما لم تطلب العملية مقبساً مزدوج المكدس.

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

مقالات ذات صلة