لماذا لا تستطيع شبكتك المحلية الوصول إلى خدمة تعمل على عميل VPN

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

النفق ليس ما تعطّل

كلا الطرفين على نطاقات خاصة، وهذه هي الحالة الطبيعية وليست خطأ إعداد. عنوان مثل 10.8.0.6 حقيقي داخل النفق وغير موجود في أي مكان آخر، لذا لا سبب للشبكة المحلية لترسل إليه أي شيء. قبل لمس التوجيه، تأكد من أن الخدمة قابلة للوصول داخل النفق أصلًا: على العميل، يُظهر ss -ltn ما إذا كانت الخدمة تستمع على 127.0.0.1 أو واجهة الشبكة المحلية أو عنوان النفق. والخدمة المرتبطة بـ loopback فقط لا تجيب أحدًا سوى نفسها، ولا يغيّر ذلك أي مسار أو DNAT أو تمرير منفذ.

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

شكل المسار: أخبر الشبكة المحلية أين توجد مجموعة العناوين

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

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

بالنسبة لشبكة فرعية تقع خلف عميل واحد بدلًا من خلف الخادم، يحتاج الخادم إلى مسار نظام وإلى مدخل iroute في ملف ذلك العميل تحت client-config-dir. وبدون iroute يعرف OpenVPN أن البادئة موجودة وليس لديه فكرة عن العميل الذي يملكها: تصل الحزم ولا شيء لدى الخدمة لتطابقها به.

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

شكل NAT: DNAT إلى الداخل، وسطر SNAT الذي يتجاوزه الجميع

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

تستخدم برامج firmware الاستهلاكية أسماء سلاسل خاصة بها ولا تولّد تلك الترجمة لك. على Tomato، تصل قاعدة واردة إلى WANPREROUTING ثم إلى سلسلة تصفية مثل wanin، ومجموعة قواعد تبدو مكتملة ما زالت تحتاج سطر POSTROUTING يدويًا. هذا ليس عيبًا في firmware، بل مجموعة قواعد كُتبت لحركة واردة فقط.

لماذا تُسقط قاعدة تبدو صحيحة الحزمة مع ذلك

معظم هذه الأعطال ليست في القاعدة التي تحدّق فيها. افحص أربعة أشياء بهذا الترتيب، وتوقف عند أول ما لا يتحقق:

• ترتيب السلاسل. يُدرج iptables -I في الأعلى ويضيف -A في الأسفل، لذا تحسم قاعدة أسبق متسامحة أو حاجزة الأمر أولًا.
• السلسلة الخاطئة. الحركة الموجهة إلى الراوتر نفسه تعبر INPUT، والحركة المعاد توجيهها لا تلمسها أبدًا. ونشر خدمة واحدة قد يحتاج قواعد في الاثنتين.
• أعلام الاتجاه. يطابق -i tun0 الحركة القادمة من العملاء ويطابق -o tun0 الحركة الخارجة نحوهم. وقاعدة REJECT بالعلم الخاطئ تحجب شيئًا لم تقصده.
• تقييد المصدر. التمرير الذي يقبل عنوان عميل واحد يعمل من ذلك العميل ويُسقط كل مصدر آخر دون كلمة.

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

التمرير المحلي، عندما لا يمكن تغيير شيء على الشبكة المحلية

تمرير SSH المحلي يتجاوز السؤال كله. لا يحتاج إلى مسار على الشبكة المحلية، ولا تعاون من جدار الحماية على العميل، ولا منفذ منشور في أي مكان:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

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

تحقق من الاتجاهين قبل إضافة قاعدة أخرى

الترجمة تترك آثارًا، وقراءتها أفضل من التخمين. على مضيف VPN، يُظهر conntrack -L هل حدثت الترجمة أصلًا، ويُظهر iptables -t nat -L -n -v هل تحركت العدّادات، ويُظهر tcpdump -ni any port 3000 أي عنوان مصدر وصل فعلًا. وعلى العميل، يؤكد ss -ltn أن الخدمة على عنوان يمكن للنفق الوصول إليه.

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