Linux EHOSTUNREACH OpenVPN સાથે: કયો આગળનો હોપ નિષ્ફળ ગયો?

EHOSTUNREACH એટલો જ સ્થાનિક નિર્ણય છે જેટલી દૂરની નિષ્ફળતા. કર્નલ પેકેટને નકારી શકે છે કારણ કે માર્ગ કહે છે કે લક્ષ્ય અગમ્ય છે, કારણ કે Ethernet આગળના હોપે ક્યારેય જવાબ આપ્યો નહીં, અથવા કારણ કે માર્ગ પર વધુ દૂરથી ICMP host-unreachable અહેવાલ આવ્યો. દરેક સ્રોત અલગ ટેબલ અથવા કેશમાં રહે છે, અને દરેકને અલગ જગ્યાએ ઠીક કરવામાં આવે છે. સાઇફરને સ્પર્શ કરતા કે ટનલ ફરી સ્થાપિત કરતા પહેલા પસંદ કરેલો માર્ગ અને આગળના હોપની સ્થિતિ વાંચો.

ક્લાયન્ટ ખરેખર જે સરનામું અને નેમસ્પેસ વાપરે છે તે પસંદ કરો

જે લક્ષ્ય અને નેટવર્ક નેમસ્પેસે ભૂલ ઉત્પન્ન કરી તેને પિન કરીને શરૂ કરો. VPN ક્લાયન્ટ તેના પોતાના નેમસ્પેસમાં ચાલી શકે છે, અને ડિફોલ્ટ નેમસ્પેસમાંથી કરેલી શોધ અલગ નીતિ નિયમોવાળા બીજા રૂટિંગ ટેબલની સલાહ લે છે.

શોધે નિષ્ફળ થતી એપ્લિકેશન જેવો જ સ્રોત, માર્ક અને ટેબલ સંદર્ભ વાપરવો જોઈએ, નહીં તો તે એવા પ્રશ્નનો જવાબ આપી શકે જે કોઈએ પૂછ્યો નહોતો. ઉદાહરણરૂપ IPv4 પીઅર માટે માત્ર-વાંચન તપાસો આ છે:

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

વહીવટી શેલમાંથી મળેલું પરિણામ ફક્ત એ સાબિત કરે છે કે તે શેલ શું કરે. જો ક્લાયન્ટ ફાયરવોલ માર્ક સેટ કરે અથવા VRF સાથે બંધાય, તો મેળ ખાતા માર્ક સાથે અથવા VRFની અંદર શોધનું પુનરાવર્તન કરો, અને પસંદ કરેલો માર્ગ અને આગળનો હોપ સરખાવો. પુષ્ટિ કરવાનું પ્રથમ સરનામું પ્રોફાઇલમાંનું પીઅર સરનામું છે, વપરાશકર્તા જણાવે છે તે ક્લસ્ટર કે સેવા નહીં.

સ્પષ્ટ અગમ્ય માર્ગ પેકેટને સ્થાનિક રીતે નકારે છે

unreachable પ્રકારનો માર્ગ ઇરાદાપૂર્વકનો સ્થાનિક જવાબ છે. તે કર્નલને પેકેટ કાઢી નાખવા અને પ્રેષકને EHOSTUNREACH પરત આપવાનું કહે છે, તેથી ભૂલ તરત જ અને મશીનમાંથી કોઈ ટ્રાફિક નીકળ્યા વિના દેખાય છે. કોઈએ, અથવા કોઈ ઓટોમેશને, તે માર્ગ જાણી જોઈને ત્યાં મૂક્યો છે.

માર્ગના પ્રકારો એકબીજાના બદલે વાપરી શકાતા નથી. Blackhole પ્રેષકને ભૂલ આપ્યા વિના પેકેટ કાઢી નાખે છે, prohibit EACCES પરત આપે છે, અને unreachable EHOSTUNREACH પરત આપે છે. તેથી પુનઃકનેક્શન દરમિયાન સિંક માર્ગ સ્થાપિત કરતું VPN સહાયક host-unreachable ભૂલોનો ઝાપટો ઉત્પન્ન કરી શકે છે જે ટનલ ઊભી થતાં જ અદૃશ્ય થાય છે, જ્યારે blackhole માર્ગ તેના બદલે શાંત સમયસમાપ્તિ ઉત્પન્ન કરે.

દૂરના છેડાને દોષ આપતા પહેલા બધા ટેબલમાં પ્રકાર શોધો. જે નિયમ ટેબલ પસંદ કરે છે તે અંદરના માર્ગ જેટલો જ મહત્વનો છે, અને મુખ્ય ટેબલમાં ઉમેરાયેલો માર્ગ એવા ક્લાયન્ટને મદદ કરશે નહીં જેનો નીતિ નિયમ તેનો ટ્રાફિક બીજે મોકલે છે.

મૃત પડોશી Ethernet પર એ જ ભૂલ ઉત્પન્ન કરે છે

જ્યારે પસંદ કરેલો માર્ગ ઓન-લિંક ગેટવે વાપરે છે, ત્યારે ડિલિવરીને ઉકેલાયેલું લિંક-લેયર સરનામું જોઈએ. કર્નલ ARP અથવા IPv6 પડોશી વિનંતી મોકલે છે, અને જો કોઈ જવાબ ન આવે તો પેકેટને ફ્રેમ કરી શકાતું નથી. પછી મોકલવું EHOSTUNREACH સાથે નિષ્ફળ જાય છે, જોકે માર્ગ પોતે માન્ય છે.

પડોશી ટેબલ તબક્કાનું નામ આપે છે. INCOMPLETE એટલે કે ઉકેલ હજી ચાલુ છે, FAILED એટલે કે છેલ્લા પ્રયાસને જવાબ મળ્યો નહીં, અને REACHABLE અથવા STALE એટલે કે કર્નલ પાસે વાપરી શકાય તેવું સરનામું છે. VPN ગેટવે માટે FAILED એન્ટ્રી સ્થાનિક ડિલિવરી સમસ્યા છે, ટનલની દૂરની બાજુ વિશેનો પુરાવો નહીં.

વાસ્તવિક આગળના હોપ માટે એન્ટ્રી વાંચો, દૂરના ઇન્ટરનેટ સરનામા માટે નહીં. દૂરના સરનામા સુધી સામાન્ય રીતે રાઉટર દ્વારા પહોંચાય છે, તેથી તેનું પોતાનું ARP રેકોર્ડ હશે નહીં; તે માટે પૂછવું એ શ્રેણીગત ભૂલ છે જે લોકોને એવી ખૂટતી એન્ટ્રી શોધવા મોકલે છે જે ક્યારેય હોવી ન જોઈએ.

દૂરના અહેવાલો અને અસિંક્રોનસ UDP ભૂલો

EHOSTUNREACH બહારથી પણ આવી શકે છે. જે રાઉટર પેકેટ ફોરવર્ડ કરી શકતું નથી તે ICMP host unreachable મોકલી શકે છે, અને કર્નલ તે અહેવાલને ફ્લો ધરાવતા સોકેટને પસાર કરે છે. તે કિસ્સામાં માર્ગ અને પડોશી બરાબર છે, અને નિષ્ફળતા સ્થાનિક નેટવર્કની બહારના હોપની છે.

UDP એટ્રિબ્યુશનને મુશ્કેલ બનાવે છે. પછીના મોકલવા કે મેળવવાના કૉલ દ્વારા પરત કરાયેલી ભૂલ અગાઉના ડેટાગ્રામને સંદર્ભિત કરી શકે છે, તેથી નિષ્ફળ જતા કૉલનું સરનામું અને સમય અહેવાલને ઉત્તેજિત કરનાર પેકેટ સાથે મેળ ન ખાઈ શકે. જોડાયેલું UDP સોકેટ ભૂલ એક વાર મેળવે છે, અને ન જોડાયેલું સોકેટ કદાચ તેને ક્યારેય જુએ નહીં.

તેથી સમય પુરાવાનો ભાગ છે. ભૂલ ક્યારે દેખાઈ, સોકેટે કયું પીઅર સરનામું વાપર્યું, અને ટનલ હમણાં જ ફરી જોડાઈ હતી કે નહીં તે નોંધો. માર્ગ ફેરફાર પછી તરત જ આવેલો ઝાપટો સ્થાનિક ટેબલ તરફ ઇશારો કરે છે; સ્થિર પ્રવાહની અંદર મિનિટો પછીની એકલ ભૂલ પથ અહેવાલ તરફ.

ક્રિપ્ટો બદલતા પહેલા સ્તરોને અલગ કરો

ત્રણ પ્રશ્નો ભૂલનું વર્ગીકરણ કરે છે. શું કર્નલે લક્ષ્યને નકારતો માર્ગ પસંદ કર્યો? શું તેણે માન્ય માર્ગ પસંદ કર્યો પણ આગળનો હોપ ઉકેલી શક્યું નહીં? અથવા સ્થાનિક નેટવર્કની બહારથી અહેવાલ આવ્યો? ફક્ત ત્રીજો કિસ્સો ટનલના દૂરના છેડાને સંડોવી શકે છે, અને ત્યારે પણ એન્ક્રિપ્શનને સંડોવતો નથી.

પ્રમાણીકરણ અને વાટાઘાટની સમસ્યાઓ પરિવહન પીઅર સુધી પહોંચ્યા પછી પોતાની ભૂલો તરીકે દેખાય છે. સાઇફર બદલવું કે ક્લાયન્ટ ફરી સ્થાપિત કરવું સ્થાનિક unreachable માર્ગને ઠીક કરી શકતું નથી, અને તે વાસ્તવિક કારણ માટે જરૂરી માર્ગ અને પડોશી પુરાવા નષ્ટ કરે છે.

પ્રથમ ફેરફાર પહેલા લક્ષ્ય, નેમસ્પેસ, પસંદ કરેલું ટેબલ, આગળનો હોપ, પડોશી સ્થિતિ અને ભૂલનો સમય નોંધો. સુધારા પછી તે જ શોધ ફરી ચલાવો; હવે ટનલ તરફ ઇશારો કરતો માર્ગ અને હવે ઉકેલાતી પડોશી એન્ટ્રી અસંબંધિત સરનામા પરની સફળ ping કરતાં વધુ મજબૂત પુરાવો છે.