NGINX stream సందర్భంలో TLS passthrough కనెక్షన్ను అనుమతించండి
NGINX TLSని ముగించకుండానే TCP TLS రిలేను తిరస్కరించగలదు. అనుమతి నియమాన్ని HTTP locationలో కాకుండా streamలో ఉంచండి, మరియు ఏ peer చిరునామా వస్తుందో తనిఖీ చేయండి.
సర్టిఫికెట్ను ఎప్పుడూ పట్టుకోకుండా ఎన్క్రిప్ట్ చేసిన బైట్లను ముందుకు పంపడమే TLS passthrough రిలే చేసే పని, మరియు ఈ ఏర్పాటు సౌకర్యవంతంగా మరియు కొంచెం గందరగోళంగా ఉంటుంది. ఏదీ డీక్రిప్ట్ కాకపోవడంతో, ఫిల్టర్ చేయడానికి HTTP ఆకారంలో ఏదీ లేదు, కాబట్టి సాధారణ location బ్లాక్ మరియు దాని యాక్సెస్ నియమాలు ఇక్కడ ఉపయోగపడవు. NGINX వద్ద ఉన్న నిర్ణయం కనెక్షన్ గురించే: ఏ నెట్వర్క్ peer తట్టింది, మరియు ఆ peerను అసలు పంపాలా.
నిర్ణయం HTTPలో కాదు, streamలో ఉంది
stream సందర్భంలో NGINX TCP సెషన్లతో పని చేస్తుంది. కనెక్షన్ peer చిరునామాను చూస్తుంది మరియు ఏ బైట్ backend చేరే ముందు దానిపై క్రమబద్ధమైన allow మరియు deny నియమాలను వర్తింపజేయగలదు. ఇది పూర్తి అనుమతి నిర్ణయం మరియు దీనికి ప్రైవేట్ కీ, సర్టిఫికెట్ లేదా HTTP పార్సింగ్ అవసరం లేదు.
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
ఆ మూడు పంక్తులు ఎప్పుడూ ఒకదానికొకటి ప్రత్యామ్నాయం కావు. 443 పోర్టును పేర్కొనే ఏ ఫైల్లోనైనా HTTP యాక్సెస్ సూచనను కాపీ చేయడం ఏమీ మార్చదు, ఎందుకంటే stream సర్వర్ ఎప్పుడూ http సందర్భాన్ని చదవదు.
పంపే ముందు కనెక్షన్ను అంగీకరించండి
stream మరియు stream-access మాడ్యూల్స్ అందుబాటులో ఉన్న ప్రస్తుత ఇన్స్టాలేషన్ ఉందని భావించండి, VPN క్లయింట్లు మూల చిరునామాలను 10.90.0.0/24లో ఉంచుతారు, మరియు 192.168.50.20:443లోని backend ఇప్పటికే ఉద్దేశించిన HTTPS గుర్తింపును అందిస్తోంది.
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}దీన్ని నడుస్తున్న కాన్ఫిగరేషన్కు నేరుగా ప్రత్యామ్నాయంగా కాకుండా కొత్త listener యొక్క భాగంగా చదవండి. మొదట ఉన్న listener మరియు includeలను సమీక్షించండి, ఎందుకంటే ఇప్పటికే ఆక్రమించిన పోర్టులో రెండవ listener అభ్యర్థన సమయంలో కాదు, reload సమయంలో విఫలమవుతుంది.
ఏది లేదో గమనించండి: listen ... ssl లేదు, సర్టిఫికెట్ సూచన లేదు. NGINX ఎన్క్రిప్ట్ చేసిన ప్రవాహాన్ని పంపుతుంది, backend TLSని ముగించి క్లయింట్ ధృవీకరించే సర్టిఫికెట్ను ప్రదర్శిస్తుంది. allowlistలో విఫలమైన క్లయింట్ TCP సెషన్ తిరస్కరించబడుతుంది, HTTP 403 పేజీ కాదు, మరియు స్థితి కోడ్ను ఆశించే ఏ సాధనమైనా పనికిరాని విషయాన్ని నివేదిస్తుంది.
allowlist ఏమి కవర్ చేస్తుంది, ఏమి చేయదు
రిలే ఇప్పటికే సర్వర్ పేరు ద్వారా backendలను ఎంచుకుంటే, మాడ్యూల్ అందుబాటులో ఉంటే ssl_preread మరియు map ఆ పనిని కొనసాగించగలవు. పేరును ఇంకా క్లయింటే అందిస్తుంది, మరియు పేరు ప్రదర్శించడం క్లయింట్ VPNలో చేరిందని నిరూపించదు.
ఉదాహరణ నియమం మొత్తం stream listenerను కవర్ చేస్తుంది. ఇది పబ్లిక్ మరియు VPN-మాత్రమే సైట్ల మిశ్రమాన్ని అందించే ఒకే ప్రవేశ బిందువుకు అనుకూలంగా ఉండదు, అక్కడ ప్రతి పేరుకు మినహాయింపు అవసరం; వేర్వేరు listenerలు సాధారణంగా ఎవరూ చదవలేని పేరు-ఆధారిత విధానం కంటే స్పష్టంగా ఉంటాయి.
మరో రెండు లోపాలను పేర్కొనవచ్చు. prefix సరిపోలిక ప్యాకెట్ ఏ ఇంటర్ఫేస్ నుండి వచ్చిందో చెప్పదు, మరియు మరెక్కడో ఉన్న HTTP నియమం ఈ listenerను పరిమితం చేయలేదు. రెండూ ఒక allow పంక్తిని మొత్తం సరిహద్దుగా పరిగణించకుండా హోస్ట్ స్థాయి ingress విధానాన్ని చిత్రంలో ఉంచడానికి కారణాలు. సరిహద్దును ఏకీభవించాల్సిన రెండు నియంత్రణలుగా రాయండి, తద్వారా ఏదైనా ఒకదానిలో మార్పు సమీక్షించబడుతుంది.
NGINX నిజానికి ఎవరి చిరునామాను చూస్తుంది?
లోడ్ బ్యాలెన్సర్, మరో proxy లేదా source NAT NGINX ముందు మధ్యవర్తిని ఉంచవచ్చు, కాబట్టి కనిపించే peer VPN క్లయింట్ యొక్క అంతర్గత చిరునామా కాదు. prefix ఎంచుకునే ముందు నిజమైన మార్గాన్ని పరిశీలించండి, ఎందుకంటే తప్పు చిరునామా కోసం రాసిన allowlist అనువాదకుడి వెనుక ఉన్న అందరినీ అనుమతిస్తుంది లేదా ఎవరినీ అనుమతించదు.
PROXY ప్రోటోకాల్ మరియు నిజమైన IP నిర్వహణ చట్టబద్ధమైన సమాధానాలు, మరియు అవి సరిపోయే, స్పష్టంగా విశ్వసనీయ పంపినవారి కోసం మాత్రమే కాన్ఫిగర్ చేయాలి. రెండు విధానాలు పంపినవారు చెప్పేది నమ్ముతాయి, అందుకే పంపినవారి జాబితా చిన్నదిగా ఉండాలి. ఏ ఇంటర్నెట్ క్లయింట్ నుండైనా వచ్చే గుర్తింపు శీర్షికను నమ్మడం మూల సమాచారాన్ని తిరిగి విశ్వసనీయం చేయదు; అది సరైన తిరస్కారాన్ని నకిలీ అంగీకారంగా మారుస్తుంది.
reload ముందు రెండు ఫలితాలను పరీక్షించండి
కాన్ఫిగరేషన్ను ధృవీకరించి, reload చేయండి, ఆపై రెండుసార్లు పరీక్షించండి: పని చేయాల్సిన కొత్త అనుమతించిన సెషన్, మరియు పని చేయకూడని తిరస్కరించిన సెషన్. అనుమతించిన పరీక్షలో సాధారణ backend సర్టిఫికెట్ ధృవీకరణను ఉంచండి, ఎందుకంటే కనెక్ట్ అయ్యే కానీ backendను ధృవీకరించలేని రిలే ఒక సమస్యను పరిష్కరించి మరొకటి సృష్టించింది.
nginx -t
ss -tnp | grep ':443'backend మార్గం మరియు ప్రతిస్పందనను విడిగా కూడా తనిఖీ చేయండి. allowlist దాటడం NGINX సెషన్ను అంగీకరించిందని మాత్రమే నిరూపిస్తుంది; చేరుకోలేని backendను ప్రతిస్పందించేలా చేయలేదు, మరియు మీరు ప్రారంభించే ముందు లేని తిరిగి వచ్చే మార్గాన్ని సరిచేయలేదు.