Ping એ પુરાવો નથી: બે સાઇટ વચ્ચેનો માર્ગ ચકાસો

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

જે ક્લાયન્ટને સેવાની જરૂર છે તેનાથી શરૂ કરો

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

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

દરેક કિનારે માર્ગ ચાલો

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

જો વિનંતી દૂરના કિનારે દેખાય પણ પાછળ કોઈ જવાબ ન હોય, તો સમસ્યા સામેની બાજુ છે: ફાયરવોલ, ખૂટતો રિટર્ન રૂટ, અથવા એવો હોસ્ટ જે સ્રોત સ્વીકારતો નથી. જો વિનંતી ક્યારેય દેખાય નહીં, તો સ્થાનિક રૂટ કે ટનલ સિલેક્ટર તેને લઈ ગયા નથી, અને સામેની બાજુ હજી તપાસને પાત્ર નથી.

એપ્લિકેશન જે પ્રોટોકોલ વાપરે તે જ વાપરો

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

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

જે સ્થિતિમાં નિષ્ફળ જાય તે ફરી ઉત્પન્ન કરો

ફક્ત મોટા સ્થાનાંતરણ સાથે દેખાતી નિષ્ફળતાઓ માપની સમસ્યા છે, જોડાણની નથી. don't-fragment બિટ સેટ કરીને મોટું પેકેટ મોકલો અને જુઓ ક્યાં અટકે છે. જો નાની વિનંતી સફળ થાય અને મોટી અટકી જાય, તો ટનલનું MTU અને ગેટવે પરની MSS સંભાળ આગલા શંકાસ્પદ છે.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

સુધારા પછી એ જ પરીક્ષણ ફરી કરો

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

ચાર આધાર મૂલ્યો અને પરિણામ નોંધો. સમાન લક્ષણનો આગલો અહેવાલ પછી પિંગને બદલે પુરાવાથી શરૂ થઈ શકશે.