NAT பின்னால் SoftEther: நேரடி டிராவர்சல் அல்லது VPN Azure ரிலே?

உங்கள் SoftEther சேவையகம் நீங்கள் மாற்ற முடியாத வழங்குநரின் ரவுட்டருக்குப் பின்னால் உள்ளது, வாடிக்கையாளர்கள் இன்னும் இணைகிறார்கள், எனவே ரிலே எல்லாவற்றையும் சுமக்கிறது என்று நீங்கள் கருதுகிறீர்கள். அது உண்மையா என்பது எந்த வழிமுறை வேலையைச் செய்தது என்பதைப் பொறுத்தது: DNS பெயர், ஒருங்கிணைந்த UDP பாதை அல்லது ரிலேக்கு வெளிச்செல்லும் சுரங்கப்பாதை. மூன்றும் இணைக்கப்பட்ட வாடிக்கையாளரை உருவாக்கலாம், அவை வெவ்வேறு நிலைகளில் தோல்வியடைகின்றன. பயனர்கள் அல்லது ஹப்களைத் தொடும் முன் நீங்கள் எந்தப் பாதையை வாங்குகிறீர்கள் என்பதைத் தீர்மானிக்கவும்.

மூன்று வழிமுறைகள், மூன்று வெவ்வேறு வாக்குறுதிகள்

மாறும் DNS என்பது பெயரிடுதல். மாறும் முகவரிக்கு ஹோஸ்ட் பெயரைத் திசைதிருப்பி வைத்திருப்பதால் மக்கள் எண்ணைத் துரத்துவதை நிறுத்துவார்கள், வேறு எதையும் செய்யாது. உள்ளூர் NAT டிராவர்சல் என்பது ஒருங்கிணைப்பு: இரண்டு SoftEther முனைப்புள்ளிகள் தகவலைப் பரிமாறிக்கொண்டு, அவற்றுக்கு இடையிலான மொழிபெயர்ப்பு சாதனங்கள் வழியாக பயன்படுத்தக்கூடிய UDP பாதையைத் திறக்க முயல்கின்றன. VPN Azure ஒரு ரிலே: சேவையகம் சேவைக்கு வெளியே அழைக்கிறது, வாடிக்கையாளர்கள் ரிலேயின் உள்கட்டமைப்பில் உள்ள ஹோஸ்ட் பெயர் வழியாக வருகிறார்கள்.

மூன்றும் ஒன்றையொன்று நிறைவு செய்கின்றன, ஒரே அம்சத்தின் பதிப்புகள் அல்ல. ஒரு பயன்பாடு பெயரிடுதலைப் பயன்படுத்தலாம், ஆனால் அதன் இணைப்பு உண்மையில் டிராவர்சல் அல்லது ரிலேயைச் சார்ந்துள்ளது.

வாடிக்கையாளர் மற்றும் நெட்வொர்க்கிலிருந்து தீர்மானிக்கவும்

தேர்வு வாடிக்கையாளரில் தொடங்குகிறது, ஏனெனில் டிராவர்சல் உள்ளூர் SoftEther இணைப்பு வழிமுறையில் மட்டுமே உள்ளது. ஒரே சேவையகத்தில் உள்ள OpenVPN, L2TP/IPsec மற்றும் SSTP கேட்பான்கள் அதைப் பெறுவதில்லை, ஒரு ஹோஸ்ட்டைப் பகிர்ந்தாலும். பயனர் எதை இயக்குவார், பின்னர் நெட்வொர்க் எதை அனுமதிக்கிறது என்பதைப் பாருங்கள். TCP 443 ஐ மட்டும் அனுமதிக்கும் நிறுவன நெட்வொர்க் அந்தப் போர்ட்டில் உள்ள ரிலேக்கு உங்களைத் தள்ளுகிறது, அதேசமயம் டிராவர்சலுக்குத் தேவையான UDP போர்ட்டுகளைக் கடக்க அனுமதிக்கும் நெட்வொர்க் நேரடிப் பாதையை முயற்சிக்கலாம்; இரண்டையும் உண்மையான வெளியேற்றக் கொள்கைக்கு எதிராக உறுதிப்படுத்தவும்.

கையால் அணுகக்கூடிய கேட்பான், நிர்வாகி ஒன்றை வெளியிட முடிந்தால் இன்னும் செல்லுபடியாகும் வடிவமைப்பு, ஆனால் அது அதன் சொந்த முகவரியிடல் மற்றும் ஃபயர்வால் வேலையுடன் கூடிய தனித் திட்டம்.

அமர்வு எந்தப் போக்குவரத்தைத் தேர்ந்தெடுத்தது என்பதை உறுதிப்படுத்தவும்

பயன்பாட்டில் உள்ள பாதைக்கு இணைப்பு நிலையே ஒரே நேர்மையான ஆதாரம். அதைச் சேவையகத்தில் படித்து, வாடிக்கையாளர் பெற்ற ஹோஸ்ட் பெயரைத் தீர்க்கவும்.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList எந்த அமர்வுகள் இணைக்கப்பட்டுள்ளன என்பதைக் காட்டுகிறது, அவற்றில் ஒன்றின் மீதான SessionGet இணைப்பு வகையைத் தெரிவிக்கிறது, அமர்வு ரிலே வழியாக வந்ததா என்பதும் உட்பட. ரிலேயின் உள்கட்டமைப்பிற்குத் தீர்க்கப்படும் பதிவு, அமர்வு மூன்றாம் தரப்பு வழியாகச் செல்கிறது என்று சொல்கிறது, அதைச் சோதனையில் அந்தப் பாதையைத் தடுப்பதன் மூலம் உறுதிப்படுத்தலாம். உள்ளூர் வாடிக்கையாளருடன், UDP முடுக்கம் தரவுப் பாதையைக் கட்டுப்பாட்டுப் பாதையிலிருந்து விலக்கலாம், எனவே ஒரு கண்காணிப்பு முழு அமர்வையும் விவரிக்காது. முகவரி மாறிய பிறகு காலாவதியான மாறும் DNS பெயர், மற்றும் பின்தளப் பாதை இல்லாதபோதும் பதிலளிக்கும் ரிலே, தனித்தனியாகச் சோதிக்கத் தகுந்த இரண்டு தோல்வி முறைகள். வடிவமைப்பு நினைத்ததை அல்ல, நீங்கள் அளந்ததைப் பதிவு செய்யுங்கள்.

தேர்ந்தெடுக்கப்பட்ட பாதை எதைச் சார்ந்துள்ளது என்பதைத் திட்டமிடுங்கள்

ஒவ்வொரு பாதையும் ஒரு சார்பைச் சுமக்கிறது. நெட்வொர்க் மாற்றம் அல்லது புதிய மொழிபெயர்ப்புச் சாதனத்திற்குப் பிறகு நேரடி டிராவர்சல் மாறலாம், அதேசமயம் சேவை அல்லது அதன் அணுகக்கூடிய போர்ட் தோல்வியடையும்போது ரிலே அமர்வு தோல்வியடைகிறது. வேறு நெட்வொர்க்கிலிருந்து மீண்டும் இணைந்து, வாடிக்கையாளர் சரிபார்த்த சேவையக அடையாளத்தை உறுதிப்படுத்தவும், முன்பு வேலை செய்த பாதையை அதே சோதனையில் வைத்திருக்கவும். பின்னர் VPN பின்னால் உள்ள தனிப்பட்ட வளத்தைச் சோதிக்கவும், ஏனெனில் அங்கீகாரம், ஹப் உறுப்பினர் நிலை, முகவரி ஒதுக்கீடு மற்றும் திரும்பும் பாதைகள் எப்படியும் உங்கள் பொறுப்பாகவே இருக்கும்.

ஹோஸ்ட் பெயர், நெறிமுறை, அம்ச அமைப்புகள் மற்றும் கவனிக்கப்பட்ட போக்குவரத்தை எழுதுங்கள். அந்த நான்கு பகுதிப் பதிவே அடுத்த நபர் வேலை செய்யும் இணைப்பை மீண்டும் உருவாக்க அனுமதிக்கிறது.