ஹேர்பின் NAT: உள்ளிருந்து VPN முனை ஏன் தோல்வியடைகிறது

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

பொதி வெளியே சென்று மீண்டும் உள்ளே வருகிறது

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

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

RFC 4787 இந்த நிலையில் NAT-லிருந்து எதிர்பார்க்கப்படும் நடத்தையை விவரிக்கிறது, சுருக்கமாக அது கோட்பாட்டில் குறிப்பிடப்பட்டிருந்தும் நடைமுறையில் விருப்பத்தேர்வு. சில திசைவிகள் இந்த அமைப்பை NAT loopback என்கின்றன, மற்றவை ஹேர்பின் NAT அல்லது NAT reflection என்கின்றன, சில எதையும் காட்டுவதில்லை. இது இல்லாத திசைவி தவறாக அமைக்கப்பட்டதல்ல; அது சாதாரணமானதைச் செய்கிறது, தீர்வு வேறெங்கோ உள்ளது. உள்ளூர் சோதனை தோல்வியடைந்ததால் பொது அனுப்புதல் விதி தவறு என்று முடிவெடுக்க வேண்டாம்.

சரிபார்ப்பு 1: இரண்டு பாதைகளையும் தனித்தனியாகச் சோதிக்கவும்

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

துல்லியமான உள்ளூர் சோதனை புரவலன் பெயரை வைத்துக்கொண்டு முகவரியை மட்டும் மாற்றுகிறது: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ சரியான சேவையகப் பெயரை வழங்கியபடியே கோரிக்கையை பொது முகவரிக்கு அனுப்புகிறது. இது பெயர்த் தீர்வுச் சிக்கலை மொழிபெயர்ப்புச் சிக்கலிலிருந்து பிரிக்கிறது, அதே பெயர் கஃபேயிலிருந்து வேலை செய்யும்போது இரண்டும் எளிதில் குழப்பமடைகின்றன. வாடிக்கையாளர் TCP இணைப்பில் தோல்வியடைகிறாரா அல்லது பின்னர் TLS-இல் என்பதைக் கவனியுங்கள், ஏனெனில் முதலாவது மொழிபெயர்ப்பையும் இரண்டாவது அடையாளத்தையும் குறிக்கிறது.

சரிபார்ப்பு 2: சேவையகம் என்ன பார்க்கிறது என்பதைப் படியுங்கள்

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

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

சரிபார்ப்பு 3: வெளிப்பாதையைத் தொடாமல் சரிசெய்யுங்கள்

ஆதரிக்கப்பட்ட மூன்று வடிவங்கள் உள்ளன, தாக்கத்தின் ஆரம் அதிகரிக்கும் வரிசையில். மிகக் குறுகியது பிளவுபட்ட DNS: உள்ளகப் பதிவை வெளியிட்டு அதே சேவையகப் பெயர் LAN-இல் உள்ள வாடிக்கையாளர்களுக்கு உள்ளக முகவரிக்குத் தீர்க்கப்படும், இது பொது பாதையை முழுவதுமாகத் தவிர்க்கிறது. அடுத்தது திசைவியின் ஆவணப்படுத்தப்பட்ட loopback அல்லது reflection விருப்பத்தை இயக்கி அதை இந்தச் சேவைக்கு மட்டும் பயன்படுத்துவது. மிக விரிவானது திசைவியில் source-NAT விதி, அது LAN-இலிருந்து வரும் போக்குவரத்தை சேவையகத்திற்கு மீளெழுதி பதில் திசைவி வழியாகத் திரும்ப வைக்கிறது; Linux திசைவியில் அது சேவையகத்தின் முகவரி மற்றும் துறையுடன் பொருந்தும் MASQUERADE விதி POSTROUTING ஆகும். மூன்றும் வெளிப்பாதையைத் தொடாமல் வைக்கின்றன, பாதுகாக்க வேண்டிய பண்பு அதுவே.

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

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

சரிபார்ப்பு 4: பின்னர் இரண்டு பாதைகளையும் சரிபார்க்கவும்

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

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