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