पुढे 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 हा चांगला निकाल आहे। अनपेक्षित मूळातून साठवलेले पृष्ठ असे नाही।