OpenVPN UDP కోసం Nginx stream రిలే: ఏమి మారుతుంది

UDP, HTTP location లో ఉండదు. దాన్ని stream పొరకు తరలించండి, VPN కోసం సెషన్ సమయ పరిమితిని నిర్ణయించండి, మరియు మూలంగా ప్రాక్సీని ఆశించండి.

మీ క్లయింట్ UDP పై సెట్ చేయబడింది, Nginx సర్వర్‌లో VPN పోర్ట్‌ను సూచించే location బ్లాక్ ఉంది, కానీ ఏమీ రాదు. ఇది ఆశించినదే: HTTP location ఏ UDP డేటాగ్రామ్‌ను మోయలేదు, ముందు భాగానికి ఏ పేరు ఇచ్చినా. దీనికి Nginx కి stream శ్రోత అవసరం, కాన్ఫిగరేషన్‌ను అక్కడికి తరలించిన తర్వాత సెషన్ నిలిచి ఉంటుందో లేదో వివరాల రెండవ సమూహం నిర్ణయిస్తుంది.

ప్రాక్సీ పొర చిరునామా కంటే ముందు వస్తుంది

Nginx యొక్క stream మాడ్యూల్ HTTP ను పార్స్ చేయకుండా TCP మరియు UDP ను ప్రాక్సీ చేస్తుంది. దాని HTTP మాడ్యూల్ అభ్యర్థన పంక్తి, హెడర్లు మరియు ప్రతిస్పందనను ఆశిస్తుంది, వాటిలో ఏదీ స్థానిక OpenVPN డేటాగ్రామ్‌లో లేదు. అందువల్ల పొరను ఎంచుకోవడం మొదటి నిర్ణయం, మరియు శ్రోత IPv4 లేదా IPv6 అనే దానిపై అది ఆధారపడదు.

TCP OpenVPN తో పనిచేస్తున్నట్టు కనిపించే కాన్ఫిగరేషన్ UDP కేసు గురించి ఏమీ చెప్పదు. ఇక్కడ రవాణా ప్రోటోకాల్‌లో భాగం, అమలు వివరం కాదు.

శ్రోత మరియు backend

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

ఏదైనా సవరించే ముందు build లో stream మాడ్యూల్ ఉందని నిర్ధారించుకోండి; పంపిణీ ప్యాకేజీ దాన్ని ప్రత్యేక మాడ్యూల్‌గా విభజించవచ్చు, మాడ్యూల్ లేకపోతే టన్నెల్‌కు బదులు కాన్ఫిగరేషన్ లోపం వస్తుంది. బ్లాక్‌ను ప్రధాన కాన్ఫిగరేషన్ సందర్భంలో ఉంచండి, http లోపల కాదు, మరియు డాక్యుమెంటేషన్ చిరునామాను నిజమైన backend తో భర్తీ చేయండి.

రెండు మార్గాలు మరియు రెండు ఫైర్‌వాల్‌లు డేటాగ్రామ్‌లను అనుమతించాలి: శ్రోత వరకు మార్గం మరియు ప్రాక్సీ నుండి backend వరకు మార్గం. IPv6 శ్రోత IPv4 మార్గాన్ని కూడా సృష్టించదు, కాబట్టి కొన్ని క్లయింట్లు ఇంకా IPv4 వాడుతుంటే, ఆ శ్రోత తన స్వంత పరీక్షతో ప్రత్యేక నమోదు. backend యొక్క స్వంత ఫైర్‌వాల్‌ను ప్రాక్సీ చిరునామా నుండి తనిఖీ చేయండి, మీ ల్యాప్‌టాప్ నుండి కాదు.

సెషన్ సమయ పరిమితులు అభ్యర్థన సమయ పరిమితులు కావు

stream ప్రాక్సీ UDP సెషన్ కోసం స్థితిని ఉంచుతుంది మరియు తన సమయ పరిమితి, ప్రతిస్పందన సెట్టింగ్‌ల ప్రకారం దాన్ని విసిరేస్తుంది. DNS రిలే నుండి కాపీ చేసిన చిన్న సమయ పరిమితి గంటల తరబడి డేటాగ్రామ్‌లు మార్పిడి చేసుకోవాలని ఆశించే VPN కి సరిపోదు, మరియు వైఫల్యం ప్రారంభించడానికి నిరాకరించే కనెక్షన్ కాకుండా నిశ్శబ్దంగా చనిపోయే కనెక్షన్‌గా కనిపిస్తుంది.

అమలు యొక్క ప్రభావవంతమైన proxy_timeout మరియు ప్రతిస్పందన గణన సెట్టింగ్ ఏదైనా చదవండి, తర్వాత వాటిని VPN నిజంగా ఉపయోగించే keepalive ప్రవర్తనతో పోల్చండి. వేర్వేరు వ్యక్తులు వేర్వేరు ఫైళ్లలో రాసిన రెండు సంఖ్యలు పనిచేస్తున్న వ్యవస్థ యొక్క సాధారణ స్థితి. ఎప్పుడూ పోల్చని రెండు సంఖ్యలు అడపాదడపా ఆగిపోయే వ్యవస్థ యొక్క సాధారణ స్థితి. పోలిక ఒకసారి, పగటి వెలుగులో జరగడానికి రెండింటినీ సేవా రికార్డులో రాయండి.

రిలే ఏమి మారుస్తుంది, ఏమి మార్చదు

stream ప్రాక్సీ OpenVPN యొక్క TLS నియంత్రణ ఛానెల్‌ను ముగించదు, దాన్ని HTTPS గా మార్చదు. backend VPN సేవగానే ఉంటుంది, మరియు ధృవపత్ర సంబంధం క్లయింట్ మరియు ఆ సేవ మధ్యే ఉంటుంది. ఉద్దేశించిన backend గుర్తింపును కాపాడటం ఇంకా క్లయింట్ మరియు సర్వర్ పని.

సాధారణ ప్రాక్సీయింగ్ backend చూసే మూల చిరునామాన్ని కూడా మారుస్తుంది. లాగ్‌లు ప్రాక్సీని చూపుతాయి, మరియు VPN సర్వర్‌లో IP ఆధారిత ఏ యాక్సెస్ నియమమైనా క్లయింట్ చిరునామాకు బదులు ఆ చిరునామాను మూల్యాంకనం చేస్తుంది. పారదర్శక మూల పరిరక్షణ వేరే రూటింగ్ మరియు ప్రత్యేక హక్కుల డిజైన్, శ్రోతకు udp జోడించడం నుండి వచ్చేది కాదు. క్లయింట్ చిరునామాపై ఆధారపడే విధానం రాసే ముందు దాన్ని ప్రణాళిక చేయండి.

పోర్ట్ నుండి కాదు, క్లయింట్ నుండి ధృవీకరించండి

UDP పోర్ట్ తెరిచి ఉందని స్థానిక తనిఖీ శ్రోత ఉనికిని నిరూపిస్తుంది. క్లయింట్ దాని ద్వారా ప్రామాణీకరించుకోగలదని లేదా ట్రాఫిక్ మార్పిడి కొనసాగించగలదని అది నిరూపించదు. ఆమోదించిన క్లయింట్ నుండి నిజమైన కనెక్షన్ పూర్తి చేయండి, తర్వాత సెషన్ అర్థవంతంగా నిలిచి ఉంటుందని నిర్ధారించండి.

Nginx UDP చేయలేదని ఎవరైనా నివేదించినప్పుడు, దానికి బదులు సాధారణ రిలే సాధనం పనిచేసిందని, ఆ రెండు వాస్తవాలకు సంబంధం లేదు. సాధనం backend ప్రతిస్పందిస్తుందని నిరూపించింది; ముందు భాగం ఏమి మద్దతిస్తుందనే దాని గురించి ఏమీ చెప్పలేదు. రెండూ నిజం కావచ్చు, మరియు వాటిలో ఒకటి మాత్రమే ఈ అమలుకు కాన్ఫిగరేషన్.

సంబంధిత వ్యాసాలు