البوابة تستضيف صفحة إدارتها: عنوان داخلي أم عام
تحتاج خدمة على بوابة VPN نفسها إلى مدخل داخلي يستطيع النفق الوصول إليه. انشرها بشكل خاص، ثم تأكد من أن المستمع العام لم يبق مفتوحًا.
صفحة إدارية تستجيب من هاتف على بيانات الجوال وتنتهي مهلتها من حاسوب محمول منضم إلى VPN. لا شيء في النفق معطل، لأن الطلب لا يدخله أبدًا. يُحل اسم المضيف إلى العنوان العام للبوابة، وهذا العنوان لا يمكن الوصول إليه إلا من خارج النفق الذي تُنهيه. إصلاح ذلك يعني منح الخدمة مدخلًا خاصًا بدلًا من تحريك نقطة النهاية الخارجية.
الصفحة تُحمّل من الخارج لا عبر النفق
يُقارن طلبان مختلفان. من بيانات الجوال يصل المتصفح إلى العنوان العام مباشرة. من داخل النفق يُحل الاسم نفسه إلى العنوان العام نفسه، وعلى الحزمة الآن أن تخرج عبر النفق لتصل إلى عنوان على الجانب البعيد من النفق نفسه. الاسم نفسه، والعنوان نفسه، وموقعان مختلفان تمامًا.
مسار الوجهة يختار عنوانًا لا منفذًا. لا شيء في جدول التوجيه يعرف أن المنفذ 443 للإدارة والمنفذ 1194 هو النقل، لذا يُعامل الاثنان كالوجهة نفسها.
لهذا تعمل الصفحة أحيانًا ولا تعمل أحيانًا أخرى، حسب الاسم والشبكة التي استخدمها العميل. إنها مشكلة مسار لا مشكلة مصادقة. كلا العميلين يصادقان بنجاح تام.
أبقِ نقطة النهاية الخارجية قابلة للوصول
ملفات تعريف النفق الكامل تحتاج إلى مسار استثناء لنقطة نهاية VPN، وخيار redirect-gateway في OpenVPN يوثق ذلك بالضبط: تحتفظ نقطة النهاية البعيدة بمسار عبر البوابة الموجودة مسبقًا حتى لا يوجّه النفق إلى نفسه. أزل هذا الاستثناء فيتبع النقل المشفر النفق، وهذا ينهي الجلسة في حلقة. هذا الاستثناء هو سبب بقاء عنوان نقطة النهاية قابلًا للوصول من داخل النفق.
النتيجة أن العنوان العام يبقى قابلًا للوصول من العميل، وهذا أيضًا سبب قدرة طلب المتصفح إلى ذلك العنوان على اتباع الاستثناء نفسه والخروج دون دخول النفق. الاستثناء يؤدي عمله، والاسم هو ما يسبب الضرر.
اقرأ قرار التوجيه لا قائمة الواجهات قبل تغيير أي شيء. الأوامر أدناه تطبع القرار لا الجرد. شغّلها من العميل الذي فشل.
ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table allإذا أظهر البحث مسار نقطة النهاية عبر البوابة الفيزيائية، فالسلوك صحيح وصفحة الإدارة تُرسل ببساطة في المسار الخاطئ. هذه هي النقطة التي يصبح فيها حل الأسماء هو الإصلاح.
امنح الخدمة اسمًا خاصًا
تحتاج الخدمة إلى اسم يُحل إلى عنوان البوابة داخل النفق، مع الحفاظ على دلالات الشهادة واسم المضيف التي يتوقعها التطبيق. سجل منطقة خاص لاسم الإدارة هو الجواب المعتاد، وهو يترك اسم النقل دون مساس.
لا تعد توجيه اسم النقل إلى العنوان الداخلي، لأن إنشاء النفق التالي سيحاول حينها الوصول إلى عنوان لا يوجد إلا داخل نفق. ذلك الخطأ ينتج VPN يعمل مرة واحدة بالضبط.
افحص عائلتي العناوين أيضًا، لأن سجل AAAA متروكًا يمكن أن يرسل المتصفح إلى مكان لم تغطه الخطة الخاصة.
dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/طابق السياسة مع مكان تشغيل العملية
العملية الأصلية المستمعة على البوابة يُوصل إليها عبر مسار الإدخال المحلي، لذا تحدد سلسلة الإدخال وربط المقبس ما إذا كان الطلب مقبولًا. قواعد التمرير وتمرير IP لا تجعل مستمعًا محليًا يجيب. اسمح لمصادر النفق في سياسة الإدخال وتأكد من أن العملية مربوطة بعنوان يستطيع النفق الوصول إليه.
الحاوية المنشورة على منفذ مضيف تتبع مسارًا مختلفًا، لأن الحزمة تُترجم وجهتها وتُمرر. ذلك الطلب يلاقي سياسة التمرير لدى المضيف وقواعد Docker الخاصة، ولهذا يمكن أن يتعايش مستمع أصلي عامل مع حاوية ترفض المنفذ نفسه.
ترتيب بدء التشغيل مهم في الحالتين، لأن الربط بعنوان لا يظهر إلا بعد صعود النفق يفشل بصمت عند الإقلاع.
افحص الوصول الخاص ومسارًا عامًا مرفوضًا
أنشئ طلبًا مسمى جديدًا من عميل مصرح مع بقاء فحوص هوية التطبيق سليمة. ثم جرّب الخدمة نفسها من خارج النفق وتأكد من أنها لا تجيب. الاسم الخاص تسهيل لا قيد، والمستمع الذي ما زال مربوطًا بالعنوان العام ما زال مكشوفًا. ذلك الفحص الأخير هو ما تتخطاه معظم المراجعات.
اقرأ الربط وحالة التصفية لا اسم المضيف الذي أُعطي للمستخدمين. الانكشاف خاصية للمقبس لا للاسم. ذلك التمييز يصمد أمام كل تغيير في DNS.
ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/عندما يعيد الطلب الداخلي الصفحة وينتهي وقت الطلب الخارجي، فللخدمة مسار خاص واحد متعمد ويبقى النقل قابلًا للوصول. وعندما يستمر الطلب الخارجي في الإجابة، يلزم تضييق المستمع أو مدخل حاوية منشور قبل أن يصف أحد الخدمة بأنها داخلية فقط.