अगाडि Nginx, VPN पछाडि निजी ब्याकएन्ड

रेलमा रहेको फोनबाट एउटा अनुरोधलाई निजी सञ्जालभित्र मात्र रहने ब्याकएन्डसम्म पछ्याउनुहोस्। फोनले सार्वजनिक नाम समाधान गर्छ, पोर्ट 443 मा सार्वजनिक ठेगानासँग जोडिन्छ र सामान्य TLS ह्यान्डसेक पूरा गर्छ। Nginx ले त्यो जडान स्वीकार्छ र त्यसपछि दोस्रो, पूर्ण रूपमा छुट्टै जडान त्यस्तो ठेगानातर्फ खोल्छ जहाँ उसले VPN इन्टरफेसबाट मात्र पुग्छ। फोनमा केही बदलिँदैन, र फोनले कहिल्यै थाहा पाउँदैन कि सुरुङ संलग्न थियो।

एउटा अनुरोध दुई जडानबाट पछ्याउने

आउने भाग सार्वजनिक HTTP कारोबार हो। यसको सार्वजनिक नाम, सार्वजनिक प्रमाणपत्र र प्रतिक्रिया मार्ग छ जुन त्यस क्षणमा आगन्तुकसँग भएको जुनसुकै ठेगानाका लागि चल्नुपर्छ। त्यो मार्ग बिथोल्ने जुनसुकै परिवर्तनले एकैचोटि सबै आगन्तुकलाई बिगार्छ। त्यसैले सार्वजनिक भाग त्यो हो जसमा तपाईं सबैभन्दा कम प्रयोग गर्न चाहनुहुन्छ।

बाहिर जाने भाग निजी हो। Nginx क्लाइन्ट बन्छ, आन्तरिक नाम समाधान गर्छ वा स्थिर ठेगाना प्रयोग गर्छ, र इन्टरनेटबाट आउने जडान अस्वीकार गर्ने सेवासम्म पुग्छ।

Public client  -> frontend public address:443   (TLS, public name)
Frontend       -> VPN private backend 10.40.0.20:8443  (TLS, private name)

यिनलाई मनमा छुट्टाछुट्टै राख्नुहोस् र कन्फिगरेसन स्वतःस्पष्ट हुन्छ। यिनलाई मिसाउनुभयो भने अन्त्यमा तपाईं सार्वजनिक क्लाइन्टलाई सुरुङमा सहभागी गराउने प्रयास गर्नुहुनेछ, र यस डिजाइनको अधिकांश अलमल त्यहीँबाट आउँछ। निजी भाग नाजुक हुन सक्छ। सार्वजनिक होइन।

यसमध्ये केही पनि बनाउनुअघि एप्लिकेसन प्रकाशित गर्नु जानाजानी हो भनी पुष्टि गर्नुहोस्। चल्ने प्रोक्सी पनि चल्ने खुलासा हो, र प्रमाणीकरण मोडेल निर्णय हुनुपर्छ, साइड इफेक्ट होइन।

गेटवेको नाम सुरुङबाट बाँच्नुपर्छ

नाम समाधानमा एउटा सूक्ष्म जाल छ। यदि निजी DNS ले VPN प्रोफाइलले आफ्नै गेटवेका लागि प्रयोग गर्ने त्यही नाम अधिलेखन गर्छ भने, पुनः जडान अन्त्यमा त्यही सुरुङबाट त्यो गेटवेसम्म पुग्न खोज्न सक्छ जुन उसले आफैं बनाउनुपर्ने हुन्छ। क्लाइन्टलाई यो नाम सुरुङ अस्तित्वमा आउनुअघि समाधान भएको चाहिन्छ। एकपटक यो सुरुङभित्र समाधान भएपछि जडान कहिल्यै बनाउन सकिँदैन।

गेटवे र ब्याकएन्डका लागि छुट्टाछुट्टै स्वीकृत नाम प्रयोग गर्नुहोस्, र समाधानकर्ताको नीति यसरी सीमित गर्नुहोस् कि हरेक नाम उसको उपभोक्तालाई आवश्यक पर्ने ठेगानामा समाधान होस्। कुनै एप्लिकेसनको Host हेडर बदल्नुले यहाँ केही गर्दैन, किनकि खोज VPN क्लाइन्टले गर्छ।

त्यसपछि दायराबारे सोच्नुहोस्। फ्रन्टएन्डलाई ब्याकएन्डको ठेगानासम्म मार्ग चाहिन्छ, र उसले सार्वजनिक क्लाइन्टलाई जवाफ दिन पनि जारी राख्नुपर्छ। त्यो होस्टमा पूरा सुरुङले पहिलो शर्त पूरा गरेर दोस्रो तोड्न सक्छ।

जहाँ नीतिले अनुमति दिन्छ, त्यहाँ विशेष गन्तव्यको सुरुङ बढी सफा डिजाइन हो। जहाँ नीतिले पूरा सुरुङ अनिवार्य गर्छ, फ्रन्टएन्ड छुट्टै सञ्जाल सन्दर्भमा पर्छ, चिनिएका आगन्तुकका लागि तदर्थ मार्गले टालिएको होइन।

सर्भर ब्लक यसरी लेख्नुहोस् कि दुवै भागले प्रमाणित गरून्

मान्नुहोस् कि ब्याकएन्डले यो नामका लागि प्रमाणपत्र प्रस्तुत गर्छ: backend.corp.example र निजी ठेगानामा जवाफ दिन्छ। नाम प्रमाणित गर्दै ठेगानासँग जोडिनु ठ्याक्कै त्यही हो जसका लागि प्रोक्सी मोड्युलका SNI र नाम विकल्पहरू छन्।

upstream private_app {
    server 10.40.0.20:8443;
}

server {
    listen 443 ssl;
    server_name app.example.com;

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

    location / {
        proxy_pass https://private_app;
        proxy_ssl_server_name on;
        proxy_ssl_name backend.corp.example;
        proxy_ssl_trusted_certificate /etc/nginx/trust/backend-ca.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 3;

        proxy_set_header Host app.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

माथिको हरेक मार्ग र ठेगाना प्लेसहोल्डर हो। महत्वपूर्ण ती भाग हुन् जसले प्रमाणीकरण खुला राख्छन्: जाँच्ने नाम, त्यसविरुद्ध जाँच्ने ट्रस्ट बन्डल, र स्वीकृत शृंखलासँग मिल्ने गहिराइ।

proxy_set_header Host app.example.com जानाजानी हो। ब्याकएन्डलाई यो सार्वजनिक मूल स्वीकार गर्न कन्फिगर गरिनुपर्छ, र उसले फर्वार्ड गरिएका हेडरमा यही फ्रन्टएन्डबाट मात्र भरोसा गर्नुपर्छ। यसमाथि लेख्नु X-Forwarded-For क्लाइन्ट ठेगानासँग एउटा प्रोक्सीका लागि सही र शृंखलाका लागि गलत हो, त्यसैले बहु-प्रोक्सी परिनियोजनलाई आफ्नै विश्वसनीय ठेगाना व्यवस्था चाहिन्छ।

सार्वजनिक मूललाई सार्वजनिक मूलजस्तै व्यवहार गराउनुहोस्

एप्लिकेसनले सार्वजनिक मूलका लागि निरपेक्ष URL, रिडिरेक्ट र कुकी जारी गर्नुपर्छ। यदि यसले आगन्तुकलाई यहाँ पठाउँछ: backend.corp.example, त्यो आगन्तुक उसले समाधान गर्न नसक्ने नाममा पठाइन्छ।

यसलाई एप्लिकेसनको समर्थित बाह्य URL सेटिङ र समीक्षित रिडिरेक्ट नीतिबाट सुधार्नुहोस्, प्रतिक्रिया निकायमा होस्ट नाम पुनः लेखेर होइन। स्वेच्छाचारी सामग्रीमा स्ट्रिङ बदल्नुले हस्ताक्षरित पेलोड तोड्छ र पछ्याउन कठिन बग बनाउँछ।

कुकी पनि त्यत्तिकै हेरचाहको योग्य छन्। निजी नामसम्म सीमित कुकी केवल सार्वजनिक नाम जान्ने ब्राउजरले कहिल्यै पठाउँदैन।

Nginx ले साँच्चै सार्वजनिक सकेटको स्वामित्व लिन सक्छ भनी पनि पुष्टि गर्नुहोस्। 443 मा रहेको विद्यमान वेब सेवा सर्नुपर्छ वा फ्रन्टएन्ड अन्तै बस्नुपर्छ, किनकि दुई प्रक्रियाले एउटै ठेगाना र पोर्ट बाँध्न सक्दैनन्।

हरेक भागलाई त्यो वास्तवमा चल्ने ठाउँमै जाँच्नुहोस्

कुनै पनि पुनःलोडअघि कन्फिगरेसनलाई स्थापित पार्सरले मान्य गर्नुहोस्, ताकि टाइपिङ गल्तीले अहिले सेवा गरिरहेको सुन्नेलाई ढाल्न नपरोस्।

त्यसपछि ब्याकएन्डको भाग फ्रन्टएन्ड होस्टबाटै, Nginx ले प्रयोग गर्ने त्यही सञ्जाल सन्दर्भमा परीक्षण गर्नुहोस्। सुरुङबाट ping ले पहुँच प्रमाणित गर्छ र TLS, अधिकार वा एप्लिकेसनबारे केही होइन।

अन्त्यमा वास्तविक होस्ट नाममा सामान्य प्रमाणपत्र प्रमाणीकरणसहित ताजा सार्वजनिक अनुरोध गर्नुहोस्, र केवल प्रतिक्रिया निकाय होइन प्रतिक्रिया मार्ग हेर्नुहोस्।

दुवै अवलोकन तैनाथ कन्फिगरेसनसँगै राख्नुहोस् र सुरुङ उपलब्ध नहुँदा के हुन्छ लेख्नुहोस्। फ्रन्टएन्डले नियन्त्रित upstream त्रुटि फर्काउनुपर्छ, कसैले अभिलेख नगरेको अर्को ब्याकएन्डमा चुपचाप झर्नु हुँदैन। स्पष्ट लग लाइनसहित 502 राम्रो नतिजा हो। अनिच्छित मूलबाट क्यास गरिएको पृष्ठ त्यस्तो होइन।