OpenVPN இன் UDP பதில் தவறான முகவரியிலிருந்து வருவது ஏன்

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

மூலம் மாறும்போது வாடிக்கையாளர் என்ன பார்க்கிறார்

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

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

multihome விருப்பம் உண்மையில் என்ன செய்கிறது

இந்த அறிவுறுத்தல் கட்டமைப்புக் கோப்பில் multihome ஆகவும் கட்டளை வரியில் --multihome ஆகவும் எழுதப்படுகிறது, மேலும் வாடிக்கையாளரின் பாக்கெட் எட்டிய முகவரியிலிருந்து UDP சேவையகம் பதிலளிக்கச் செய்கிறது. பெறும்போது கர்னல் அசல் இலக்கு முகவரியைக் கூடுதல் தரவாக வழங்குகிறது, OpenVPN அந்த மதிப்பைப் பதிலின் மூலமாகப் பயன்படுத்துகிறது. இவ்வாறு பொது முகவரியில் கேட்கும் சேவையகம், IPv4 க்கு local 0.0.0.0 அல்லது அதன் IPv6 சமமானம், ஒவ்வொரு வாடிக்கையாளரும் தனி கேட்பானை எட்டியது போல நடந்துகொள்கிறது. பொது முகவரி வழியாக வந்த வாடிக்கையாளர்கள் பொது முகவரியிலிருந்து பதில்களைப் பெறுகிறார்கள், உள் முகவரியில் உள்ள வாடிக்கையாளர்கள் அந்த முகவரியிலிருந்து பெறுகிறார்கள். பாக்கெட்டின் பாதையில் வேறு எதுவும் நகர்வதில்லை: பாதை, வடிகட்டி விதிகள் மற்றும் சுரங்கப்பாதை கட்டமைப்பு இருந்தபடியே இருக்கும்.

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

நிலையான உள்ளூர் முகவரி எப்போது தவறான இயல்புநிலை

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

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

பதிலின் மூலத்தை வெளியிலிருந்து நிரூபியுங்கள்

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

பாதையமைப்பு, கண்டறிதல் மற்றும் வடிகட்டுதல் தனித்தனியாக இருக்கும்

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

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