फक्त 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 निर्देशांची यादी करा आणि ते पुरवतात त्या रूटची तुलना करा. दुसऱ्या ॲपसाठी जोडलेला ब्लॉक त्याच upstream वर प्रॉक्सी करू शकतो, आणि जुना डीफॉल्ट सर्व्हर नवीन स्थापित झाल्यावरही उत्तर देत राहू शकतो. ते आउटपुट खरी यादी आहे, नुकतीच संपादित केलेली फाइल नाही. तीच सामग्री पुरवणाऱ्या प्रत्येक रूटची तुलना करा.

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 बदल त्यांपैकी कोणतेही हलवू शकतो, आणि चार नामांकित मूल्ये कार्यरत ब्राउझर टॅबपेक्षा तुलना करणे सोपे आहे.