केवल VPN के लिए NGINX साइट: लिसनर, फ़ायरवॉल और HTTP अनुमति सूची

निजी साइट और इंटरनेट के बीच तीन स्वतंत्र निर्णय खड़े हैं: कौन-सा सॉकेट कनेक्शन स्वीकार करता है, कौन-सा पथ उसे पहुँचा सकता है, और चुना गया सर्वर किन HTTP क्लाइंट को उत्तर देता है। सर्वर ब्लॉक केवल पहला निर्णय लेता है। बाकी दो को अलग नियंत्रण मानें, वरना साइट निजी दिखेगी जबकि पुराना प्रवेश खुला रहेगा। केवल VPN के लिए बने अधिकांश NGINX विफलता केवल पहली परत जाँचने से आते हैं।

उदाहरण tun0 पर 10.90.0.1 पर Linux OpenVPN गेटवे, 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 परिवर्तन इनमें से कोई भी हिला सकता है, और चार नामित मान काम करते ब्राउज़र टैब की तुलना में तुलना करने में आसान हैं।