Linux EHOSTUNREACH மற்றும் OpenVPN: தோல்வியடைந்த அடுத்த ஹாப் எது?

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

கிளையன்ட் உண்மையில் பயன்படுத்தும் முகவரியையும் namespace-ஐயும் தேர்ந்தெடுங்கள்

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

தேடல் தோல்வியடையும் பயன்பாட்டின் அதே மூலம், mark மற்றும் அட்டவணை சூழலைப் பயன்படுத்த வேண்டும், இல்லையெனில் யாரும் கேளாத கேள்விக்கு பதிலளிக்கலாம். விளக்கமான IPv4 peer ஒன்றுக்கு, படிக்க-மட்டும் சோதனைகள்:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

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

வெளிப்படையான unreachable வழி பாக்கெட்டை உள்ளூரிலேயே நிராகரிக்கிறது

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

வழி வகைகள் ஒன்றுக்கொன்று மாற்றக்கூடியவை அல்ல. blackhole அனுப்புநருக்குப் பிழையின்றி பாக்கெட்டை நீக்குகிறது, prohibit EACCES-ஐத் திருப்பித் தருகிறது, unreachable EHOSTUNREACH-ஐத் திருப்பித் தருகிறது. மீண்டும் இணைக்கும்போது sink வழியை நிறுவும் VPN உதவியான், சுரங்கப்பாதை எழுந்தபின் மறையும் host-unreachable பிழைகளின் வெடிப்பை உருவாக்கலாம், அதேசமயம் blackhole வழி அதற்குப் பதிலாக அமைதியான நேர முடிவுகளை உருவாக்கும்.

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

இறந்த அண்டை Ethernet-இல் அதே பிழையை உருவாக்குகிறது

தேர்ந்தெடுக்கப்பட்ட வழி on-link நுழைவாயிலைப் பயன்படுத்தும்போது, விநியோகத்திற்கு தீர்க்கப்பட்ட இணைப்பு-அடுக்கு முகவரி தேவை. கர்னல் ARP அல்லது IPv6 அண்டை வினவலை அனுப்புகிறது, பதில் வராவிட்டால் பாக்கெட்டை சட்டகமாக்க முடியாது. அப்போது வழி செல்லுபடியாக இருந்தாலும் அனுப்புதல் EHOSTUNREACH-உடன் தோல்வியடைகிறது.

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

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

தொலை அறிக்கைகள் மற்றும் ஒத்திசையா UDP பிழைகள்

EHOSTUNREACH வெளியிலிருந்தும் வரலாம். பாக்கெட்டை அனுப்ப முடியாத ரவுட்டர் ICMP host unreachable அனுப்பலாம், கர்னல் அந்த அறிக்கையை ஓட்டத்தை வைத்திருக்கும் socket-க்கு அனுப்புகிறது. அப்போது வழியும் அண்டையும் சரியாக இருக்கும், தோல்வி உள்ளூர் பிணையத்திற்கு அப்பால் உள்ள ஹாப்புக்கு உரியது.

UDP காரணத்தைக் கண்டறிவதைக் கடினமாக்குகிறது. பின்னர் வரும் send அல்லது receive அழைப்பு திருப்பித் தரும் பிழை முந்தைய datagram-ஐக் குறிக்கலாம், எனவே தோல்வியடையும் அழைப்பின் முகவரியும் நேரமும் அறிக்கையைத் தூண்டிய பாக்கெட்டுடன் பொருந்தாமல் போகலாம். இணைக்கப்பட்ட UDP socket பிழையை ஒருமுறை பெறும், இணைக்கப்படாத socket அதை ஒருபோதும் காணாமல் போகலாம்.

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

குறியாக்கத்தை மாற்றுவதற்கு முன் அடுக்குகளைப் பிரிக்கவும்

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

அங்கீகாரம் மற்றும் பேச்சுவார்த்தைப் பிரச்சினைகள் போக்குவரத்து peer-ஐ அடைந்தபின் அவற்றின் சொந்தப் பிழைகளாக வெளிப்படும். சைஃபரை மாற்றுவதோ கிளையன்டை மீண்டும் நிறுவுவதோ உள்ளூர் unreachable வழியைச் சரிசெய்ய முடியாது, உண்மையான காரணத்திற்குத் தேவைப்படும் வழி மற்றும் அண்டை சான்றையும் அழிக்கும்.

முதல் மாற்றத்திற்கு முன் இலக்கு, namespace, தேர்ந்தெடுக்கப்பட்ட அட்டவணை, அடுத்த ஹாப், அண்டை நிலை மற்றும் பிழை நேரத்தைப் பதிவு செய்யுங்கள். சரிசெய்த பின் அதே தேடலை மீண்டும் இயக்குங்கள்; இப்போது சுரங்கப்பாதையை நோக்கும் வழியும் இப்போது தீர்க்கப்படும் அண்டைப் பதிவும் தொடர்பில்லாத முகவரிக்கு வெற்றிகரமான ping-ஐ விட வலுவான சான்று.