موقع NGINX للـVPN فقط: المستمع وجدار الحماية وقائمة سماح HTTP

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

يستخدم المثال العملي بوابة OpenVPN على Linux عند 10.90.0.1 على tun0، وعملاء في 10.90.0.0/24، ومصادر محفوظة، ومنفذ TCP 8443 محجوز لهذا المدخل. عدّل القيم واحتفظ بالطبقات.

ابدأ بالمقبس، لا باسم المضيف

اربط مستمع HTTPS بعنوان النفق وبمنفذ مخصص. العنوان المحدد أسهل في التحليل من مقبس شامل مع فحص للاسم، لأن النواة لن تسلّم المنفذ إلى عنوان محلي آخر.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

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

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

أغلق كل مستمع آخر لهذا المحتوى

اسرد توجيهات listen وقارن الجذور التي تخدمها. الكتلة المضافة لتطبيق آخر قد تمرر إلى المنبع نفسه، وقد يظل خادم افتراضي قديم يجيب بعد تثبيت الجديد. هذا الناتج هو الجرد الحقيقي، لا الملف الذي عدّلته للتو. قارن كل جذر يخدم المحتوى نفسه.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

افحص عائلتي العناوين. ربط IPv4 يترك مقبس IPv6 دون مساس، وسجل A جديد لا يُنهي إجابة AAAA قديمة ما زالت تشير إلى مسار عام.

أوقف المضيف الافتراضي القديم كتغيير منفصل. إزالة التوأم العام للكتلة الجديدة هي عادةً الخطوة التي تغلق المدخل فعلًا؛ أما المستمع الخاص فيضيف المدخل المقصود فقط.

حدّد نطاق المسار الوارد عند المضيف

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

مع سياسة دخول ترفض افتراضيًا ولا سماح أوسع لهذه الخدمة، تسمّي قاعدة محددة النفق ونطاق المصدر والوجهة والمنفذ معًا:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

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

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

أبقِ قائمة HTTP سليمة مع تغيّر المواقع

يقيّم NGINX مدخلات allow وdeny بالترتيب، وقائمة مستوى الخادم أعلاه تسمح للمجموعة المعلنة قبل deny النهائي. وتسجّل وحدة الوصول أيضًا أن أي موقع يعرّف أي مدخل وصول يستخدم قائمته الخاصة بدل قائمة الأصل. الترتيب مهم بقدر المدخلات نفسها.

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

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

رفض HTTP يحدث بعد وصول اتصال TCP إلى NGINX. وهو يكمّل تقييد الشبكة، ويظل ترخيص التطبيق نفسه ساريًا على كل مستخدم.

تحقق من المسار الحيّ وحالة الفشل

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

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

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

سجّل المقبس والمنفذ ونطاق المصدر وقائمة HTTP التي نجحت. قد يحرّك أي تغيير لاحق في VPN أو DNS أيًا منها، وأربع قيم مسمّاة أسهل في المقارنة من علامة تبويب متصفح تعمل.