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 కంటే బలమైన సాక్ష్యం.