VPN வாடிக்கையாளருக்கு NGINX எந்த மூல முகவரியைப் பதிவு செய்யும்?
ஒரே ஹோஸ்ட்டில் OpenVPN உடன் NGINX என்ன பார்க்கிறது என்பதை முடிவு செய்யுங்கள்: உள் சுரங்க முகவரி, பொது வெளியேறு முகவரி அல்லது அனுப்பப்பட்ட இணை, பயணித்த பாதையைப் பொறுத்து.
ஒரே ஹோஸ்ட்டில் NGINX மற்றும் OpenVPN அமைப்பில் வாடிக்கையாளரின் மூன்று முகவரிகள் தோன்றும், கோரிக்கை எடுக்கக்கூடிய ஒவ்வொரு பாதைக்கும் ஒன்று. சுரங்க முகவரியை அடையும் உலாவி, பொது முகவரியை அடையும் உலாவி, நுழைவாயிலின் இணையப் பாதையில் வெளியேறும் நிரல் ஆகியவை கேட்கும் சாக்கெட்டில் அனைத்தும் வேறாகத் தெரியும். பதிவு வரியை விளக்குவதற்கு முன் நீங்கள் எந்தப் பாதையைப் பார்க்கிறீர்கள் என்பதை முடிவு செய்யுங்கள். முடிவு வாடிக்கையாளர் பயன்படுத்திய இலக்கு, வெளி VPN இறுதிப் புள்ளிக்காக அவர் வைத்திருக்கும் விலக்கு, மற்றும் வழியில் ஏதேனும் பொதி மொழிபெயர்க்கப்படுகிறதா என்பதைப் பொறுத்தது.
பயனர் யார் என்பதைக் கொண்டு அல்ல, இலக்கைக் கொண்டு முடிவு செய்யுங்கள்
கோரிக்கை அனுப்பப்பட்ட முகவரியில் தொடங்குங்கள், ஏனெனில் அந்த முகவரியே பாதையைத் தேர்ந்தெடுக்கிறது. ஹோஸ்ட்டின் சுரங்க முகவரிக்கான கோரிக்கை சுரங்க இடைமுகத்தில் வாடிக்கையாளரின் உள் முகவரியை மூலமாகக் கொண்டு வரும். ஹோஸ்ட்டின் பொது முகவரிக்கான கோரிக்கை பொதுவாக இணையம் நோக்கிய இடைமுகத்தில் வாடிக்கையாளரின் பொது முகவரியுடன் வரும், அதே மடிக்கணினியில் அந்த நேரத்தில் சுரங்கம் நிறுவப்பட்டிருந்தாலும். எனவே VPN குழுமத்தில் உறுப்பினராக இருப்பது பொதியின் பாதையின் பண்பு, பயனரைப் பின்தொடரும் பண்பு அல்ல.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
பதிவில் சுரங்கத்துடன் எந்தத் தொடர்பும் இல்லாத முகவரியுடன் VPN பயனர் தோன்றும்போது முதலில் சரிபார்க்கத் தகுந்தது இந்த மூன்றாவது வரிதான். ஒரே சுயவிவரத்தில் உள்ள இரண்டு பயனர்கள் வெவ்வேறு பதிவுகளை உருவாக்க முடிவதற்கான காரணத்தையும் இது விளக்குகிறது: அவர்களின் சொந்த அணுகல் வலையமைப்புகள் வேறுபடுகின்றன, சுரங்கத்திற்குள் எதுவும் அதன் மேல் எழுதுவதில்லை.
வெளி இறுதிப் புள்ளி இரண்டாவது பொது பாதையை ஏன் உருவாக்குகிறது
சுரங்கத்தை நிறுவ வாடிக்கையாளர் நுழைவாயிலின் பொது முகவரியை அடைய வேண்டும், எனவே அந்த முகவரிக்கான வழி சுரங்கத்திற்கு வெளியே இருக்க வேண்டும். வாடிக்கையாளர் எல்லா இயக்கத்தையும் உள்ளே திருப்பும்போது, தன்னைச் சார்ந்த சுரங்கத்தைத் தவிர்க்க நியாயமான செயலாக்கம் சேவையகத்தின் பொது முகவரிக்கு வெளிப்படையான ஹோஸ்ட் வழியை வைத்திருக்கிறது. அந்த விலக்கு சேவைகள் விஷயத்தில் தேர்வு செய்யாது, எனவே அதே பொது முகவரிக்கான எந்தக் கோரிக்கையும் அதைப் பின்பற்றும், நுழைவாயிலில் ஹோஸ்ட் செய்யப்பட்ட தளத்திற்கான உலாவிக் கோரிக்கையும் உட்பட.
இந்தத் துறையில் குழப்பமான அறிக்கைகள் பலவற்றின் பின்னுள்ள வழிமுறை இதுவாகும், அது சேவையகத்தை விட வாடிக்கையாளர் செயலாக்கத்தைச் சார்ந்தது. எனவே ஒரே மாதிரியான சுயவிவரங்களைக் கொண்ட இரண்டு வாடிக்கையாளர்கள் வெவ்வேறாக நடந்துகொள்ளலாம். பதிவை »சரிசெய்ய« விலக்கை அகற்றினால் சுரங்கமும் அதனுடன் விழும், எனவே அதை வைத்துக்கொண்டு அதைச் சுற்றி வடிவமைக்கவும்.
சாக்கெட், அட்டவணை மற்றும் பதிவு வடிவமைப்பை ஒன்றாகப் படியுங்கள்
மூன்று அவதானிப்புகள் நீங்கள் எந்தப் பாதையைப் பார்க்கிறீர்கள் என்பதைத் தீர்மானிக்கின்றன: சாக்கெட் எங்கே கேட்கிறது, எந்த இடைமுகம் இலக்குக்குப் பதிலளிக்கிறது, பதிவு வடிவமைப்பு உண்மையில் என்ன பதிவு செய்கிறது. கேட்பவர் சுரங்க முகவரியுடன் மட்டும் பிணைந்திருந்தால், பொதுக் கோரிக்கை அங்கு சென்று சேரவே முடியாது, இது இரண்டு வரிகளை உடனே நீக்குகிறது. வாடிக்கையாளருக்கான தேடல் சுரங்கச் சாதனத்தைத் திருப்பித் தந்தால், கோரிக்கை உள் மூலத்துடன் வந்துள்ளது, பதிவு அதைக் காட்ட வேண்டும்.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44பின்னர் வரியை அல்ல, வடிவமைப்பைப் படியுங்கள். அனுப்பப்பட்ட தலைப்பால் நிரப்பப்படும் புலம் சாக்கெட்டின் இணையை அல்ல, ஒரு கூற்றைப் பதிவு செய்கிறது, கூற்று உடனடி இணை நம்பகமான பதிலாளியாக இருக்கும்போது மட்டுமே முக்கியம். இரண்டு மதிப்புகளையும் பதிவில் எழுதுவது பிந்தைய வாதங்களை முடிக்கிறது, ஏனெனில் உடனடி இணையும் மாற்றப்பட்ட முகவரியும் வெவ்வேறு உண்மைகள், அவற்றில் ஒன்று மட்டுமே வலையமைப்பிலிருந்து வந்தது.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confவிரும்பிய நுழைவுப் புள்ளியைத் தேர்ந்து DNS ஐ ஒப்புக்கொள்ளச் செய்யுங்கள்
தளம் சுரங்கம் வழியாக மட்டும் இருக்க வேண்டுமானால், VPN வாடிக்கையாளர்களுக்கு சுரங்க முகவரிக்கு தீர்க்கப்படும் பெயரைக் கொடுத்து, கேட்கும் சாக்கெட்டில் கொள்கையை நடைமுறைப்படுத்துங்கள். உள் பெயருக்கு 10.24.0.1 திருப்பித் தரும் பிரிக்கப்பட்ட DNS பதில் பெயர் தீர்வின் விவரத்தின் வேடத்தில் உள்ள பாதை முடிவு. தளம் பொதுவாகவும் இருக்க வேண்டுமானால், இரண்டு பெயர்கள் அல்லது இரண்டு துறைகளை வைத்துக்கொண்டு, எது கோரிக்கைக்கு சேவை செய்தது என்பதைப் பதிவு சொல்லட்டும்.
அனுமதி விதிகளும் அதே தர்க்கத்தைப் பின்பற்றுகின்றன. சுரங்கக் குழுமத்திற்கு அனுமதி அளிப்பது பொதுக் கோரிக்கைக்கு அதிகாரம் அளிக்காது, இணையம் வழியாக வந்த இணைப்பில் உள் முகவரியை நிரப்பாது. இரண்டு நுழைவுப் புள்ளிகளையும் ஒரு பெயரின் கீழ் கலப்பது பதிவு செய்யப்பட்ட மூலத்தை வடிவமைப்புத் தேர்வாக அல்லாமல் வாடிக்கையாளர் பாதையின் பக்க விளைவாக மாற்றுகிறது.
பாதையைச் சரிபார்த்து, பிறகு கொள்கையை
நுழைவாயிலில் எடுக்கப்பட்ட பிடிப்பு மற்றும் நீங்கள் கட்டுப்படுத்தும் கோரிக்கை மூலம் பாதையை உறுதிப்படுத்துங்கள். சுரங்கச் சாதனத்தில் ஒரு பிடிப்பும் பொது இடைமுகத்தில் ஒன்றும் எது பைட்டுகளை எடுத்துச் சென்றது என்பதைக் காட்டுகின்றன, பொதிகளின் வரிசை அவற்றுக்கிடையே மொழிபெயர்ப்பு நடந்ததா என்பதைச் சொல்கிறது.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5பிறகு இரு திசைகளிலும் அணுகலைச் சரிபாருங்கள்: நோக்கிய பெயரிடப்பட்ட நுழைவு நோக்கிய வாடிக்கையாளருக்கு வேலை செய்கிறது, அனுமதிக்கப்படாத பொது பாதை மெதுவாக இருப்பதற்குப் பதிலாக நிராகரிக்கப்படுகிறது. ஒரு பொதுவான IP எதிரொலித் தளம் நுழைவாயிலின் இணைய வெளியேற்றம் பற்றி ஏதோ நிரூபிக்கிறது, அதே ஹோஸ்ட்டில் உள்ள இந்தத் தளம் பற்றி எதுவும் நிரூபிக்கவில்லை. ஒரு பக்கம் மற்றும் ஒரு WebSocket உடன்படாதபோது, சேவையக உள்ளமைவைத் தொடுவதற்கு முன் அவற்றின் URL, முகவரிக் குடும்பங்கள் மற்றும் DNS பதில்களை ஒப்பிடுங்கள்.