VPN પર Ping લોસ: ટકાવારી પહેલાં Echo વિનંતીઓનું જૂથ બનાવો

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

પગલું 1: પ્રવાહોને સ્રોત અને ગંતવ્ય પ્રમાણે અલગ કરો

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

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

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

પગલું 2: ઓળખકર્તા અને ક્રમ પર મેળ કરો

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

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

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

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

પગલું 3: ટ્યુપલની સરખામણી એક જ સીમા પર કરો

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

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

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

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

પગલું 4: કેપ્ચર શું સાબિત કરી શકે અને શું નહીં તે કહો

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

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

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

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

જૂથો અને આગલી સીમા જણાવો

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

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

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

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