முன்னே Nginx, VPN பின்னே தனியார் பேக்எண்ட்

உலாவி Nginx-உடன் பேசுகிறது, Nginx சுரங்கத்தில் இரண்டாவது இணைப்பைத் திறக்கிறது. இரண்டையும் வழிமாற்று, இரண்டு சான்றிதழ்களையும் சரிபார், பொது வழிமாற்றல்களைப் பொதுவாக வைத்திரு.

ரயிலில் இருக்கும் தொலைபேசியிலிருந்து ஒரு கோரிக்கையை தனியார் வலையமைப்புக்குள் மட்டுமே இருக்கும் பேக்எண்ட் வரை கண்காணி. தொலைபேசி ஒரு பொது பெயரைத் தீர்க்கிறது, போர்ட் 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 நல்ல முடிவு. திட்டமிடாத மூலத்திலிருந்து தேக்ககப்படுத்தப்பட்ட பக்கம் அப்படி இல்லை.

தொடர்புடைய கட்டுரைகள்