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 परिवर्तनले तीमध्ये कुनै पनि सार्न सक्छ, र चार नाम दिइएका मान काम गर्ने ब्राउजर ट्याबभन्दा तुलना गर्न सजिलो छन्।