நீங்கள் கட்டமைக்க முடியாத NAT-க்குப் பின்னால் VPN: இன்னும் எது வேலை செய்கிறது

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

மேப்பிங் அட்டவணையே எல்லாவற்றையும் தீர்மானிக்கிறது

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

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

சந்திப்புச் சேவை என்ன செய்ய முடியும், என்ன செய்ய முடியாது

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

மேப்பிங் நடத்தையே மீதியைத் தீர்மானிக்கிறது, மேலும் RFC 4787 மூன்று வடிவங்களைப் பெயரிடுகிறது: முனையம் சாராதது, முகவரி சார்ந்தது, முகவரி மற்றும் போர்ட் சார்ந்தது. கடைசியில், சகா இலக்கு வைக்க வேண்டிய போர்ட் ஒவ்வொரு இலக்கிற்கும் மாறுகிறது, எனவே ஊகம் நம்பகமானதாக இருக்காது. அங்குதான் இந்த நுட்பம் தன் முட்டுச்சந்தையை அடைகிறது, ஏனெனில் இயக்குநர் நிலை NAT மற்றும் கடுமையான நிறுவன ஃபயர்வால் இரண்டும் திட்டத்திற்குத் தேவையான முன்கணிப்பை நீக்குகின்றன, எத்தனை மறுமுயற்சிகளும் அதைத் திரும்பக் கொண்டுவராது.

கீப்அலைவ், மறுதொடக்கம் மற்றும் நகரும் முனையம்

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

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

காணாமல் போன ஃபார்வர்டைச் சுற்றி மூன்று வழிகள்

முதல் வழி ரவுட்டரையே பதிவை உருவாக்கச் சொல்கிறது, UPnP IGD, NAT-PMP அல்லது PCP வழியாக, அம்சம் இருந்து இயக்கப்பட்டிருந்தால். இரண்டாவது போக்குவரத்தைப் பொது முகவரி கொண்ட ரிலேவுக்கு ஒப்படைக்கிறது, அது எப்போதும் வேலை செய்கிறது, எப்போதும் பேண்ட்விட்த்துடன் வேறு நம்பிக்கை எல்லையையும் செலவழிக்கிறது. மூன்றாவது திசையைத் திருப்புகிறது: உள் ஹோஸ்ட் பொது சேவையகத்தை நோக்கி வெளிச்செல்லும் டன்னலைத் திறக்கிறது, மற்ற அனைத்தும் அதற்குள் பயணிக்கின்றன.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

ரவுட்டரின் உரிமையாளருக்குத் தீர்வைப் பொருத்துங்கள்

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

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