VPN કનેક્ટ થાય છે પણ LAN ઉપકરણો સુધી પહોંચતું નથી: શું તપાસવું

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

હવેથી ગેટવેની બીજી બાજુ પર કંઈક પરીક્ષણ કરો. ફોરવર્ડિંગ ગમે તેટલું તૂટેલું હોય, ગેટવેનું પોતાનું સરનામું જવાબ આપતું રહેશે.

ગેટવે તેના પોતાના સ્ટેકમાંથી જવાબ આપે છે

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

ટનલ દ્વારા પહોંચાતા વ્યવસ્થાપન પૃષ્ઠો પણ પ્રથમ શ્રેણીમાં આવે છે. તે ટનલ વિશેનો પુરાવો છે, તેની પાછળના નેટવર્ક વિશે નહીં.

પ્રવાહને પ્રથમ સીમા સુધી અનુસરો જે તેને પડતો મૂકે છે

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

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

પરત માર્ગો અને હોસ્ટ ફાયરવોલ અલગ રીતે નિષ્ફળ જાય છે

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

ક્લાયન્ટથી મોકલીને અને પરત આવવાનું નિરીક્ષણ કરીને પરત માર્ગનું જાણી જોઈને પરીક્ષણ કરો. એકદિશીય કેપ્ચર સેકંડોમાં એ નક્કી કરે છે જે એક કલાકની અટકળ નહીં કરી શકે.

ક્લાયન્ટના સ્રોત સરનામા સાથે દરેક હોપની પુષ્ટિ કરો

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

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

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

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