ముందు 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 మంచి ఫలితం. అనుకోని మూలం నుండి కాష్ చేయబడిన పేజీ అలా కాదు.