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 మార్పు వాటిలో ఏదైనా కదిలించవచ్చు, నాలుగు పేరున్న విలువలను పని చేసే బ్రౌజర్ ట్యాబ్ కంటే పోల్చడం సులభం.