VPN இணைக்கப்பட்டுள்ளது ஆனால் ஒரு சேவை தோல்வியடைகிறது: நிலையை தனிமைப்படுத்துங்கள்

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

பெயரில் தொடங்குங்கள், சுரங்கப்பாதையில் அல்ல

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

resolvectl query host.internal
getent hosts host.internal

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

கர்னல் எந்தப் பாதையைத் தேர்ந்தெடுத்தது என்று கேளுங்கள்

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

ip route get 10.20.30.40
ip -brief address show

dev, via மற்றும் src புலங்களை அதே வரிசையில் படியுங்கள், ஏனெனில் ஒவ்வொன்றும் வேறு சந்தேகத்தை நீக்குகிறது. இந்த நிலை வாடிக்கையாளர் நிறுவிய நிலையையும் கொண்டுள்ளது, ஏனெனில் firewall விதிகள் மற்றும் வழித்தடங்கள் அசாதாரண வெளியேற்றத்திற்குப் பிறகும் இருக்கலாம். அதனால்தான் «சுரங்கப்பாதை இல்லாமல் இணையம் இல்லை» மற்றும் «வாடிக்கையாளர் இயங்காவிட்டால் இணையம் இல்லை» இரண்டல்ல, ஒரே குறை குடும்பம்.

பாக்கெட் அளவைச் சோதியுங்கள்

பெரிய பரிமாற்றம் நிற்கும்போது திரும்பி வரும் சிறிய பதில் முதலில் பாதையின் MTU-வைச் சுட்டுகிறது. சுரங்கப்பாதையின் உள்ளிருந்து அனுப்பப்பட்ட, do-not-fragment பிட் அமைக்கப்பட்ட ஒரு ஆய்வு இந்த நிலையை மற்றவற்றிலிருந்து பிரிக்கிறது. ஆய்வு தோல்வியடையும் வரை சுமையை உயர்த்துங்கள், முக்கியமான எண் உங்களிடம் இருக்கும்.

ping -M do -s 1400 10.20.30.40

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

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

தொலை முனையைச் சோதியுங்கள்

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

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

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

புகாரை ஒரு நிலையுடன் இணைக்கவும்

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

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

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