ડુપ્લિકેટ IKE પેકેટ: ખોવાયેલું સંક્રમણ શોધો
વારંવાર આવતી IKE વિનંતી ટાઇમર ઘટના છે, નિદાન નહીં. સાચા આવૃત્તિ ઓળખકર્તાઓ સાથે ઇનિશિયેટરથી જવાબ સુધી એક પુરાવા-શૃંખલા બનાવો.
લોગ એ જ IKE વિનંતી બે વાર બતાવે છે, કોઈ મોબાઇલ અપલિંક તરફ ઇશારો કરે છે, અને ટિકિટ એક અનુમાન સાથે બંધ થાય છે. એ અનુમાન જ ભ્રમ છે: પુનરાવર્તિત પેકેટ એક વિનિમય વિશેનું અવલોકન છે, લિંકનું નિદાન નહીં. પુનઃપ્રસારણ પોતાના નિયમો સાથેનું સામાન્ય વર્તન છે, અને જવાબ ધીમો હોય ત્યારે સ્વસ્થ માર્ગો પર પણ દેખાય છે. ઇન્ટરફેસને દોષ આપતા પહેલાં જવાબને અનુસરો.
ભ્રમ: પુનરાવર્તિત વિનંતી એક લિંક પર નુકસાન સાબિત કરે છે
બે અલગ વસ્તુઓ ડુપ્લિકેટ બનાવે છે અને તેમાંથી કોઈ દોષિતનું નામ લેતું નથી. વિનંતીકર્તા જવાબ ન મળવાથી વિનંતીનું પુનરાવર્તન કરી શકે છે, અથવા સ્ટેક સાથે ક્યાં જોડાયેલું છે તેના કારણે કેપ્ચર બિંદુ એ જ પેકેટ બે વાર બતાવી શકે છે. જે ટેપ એક જ હોસ્ટ પર ઇનગ્રેસ અને ઇગ્રેસ જુએ છે તે એક પેકેટને બે તરીકે ખુશીથી લોગ કરશે, અને તે લોગ વાંચતા ઓપરેટર પાસે વિનિમય ઓળખકર્તાઓ વિના ફરક પારખવાનો કોઈ રસ્તો નથી. બેમાંથી કયું તમારા હાથમાં છે તે કહી શકે ત્યાં સુધી ડુપ્લિકેટને ટાઇમર ઘટના તરીકે ગણો.
બે અપલિંક મૂંઝવણને સુધારવાને બદલે વધારે છે. એક લોગ લાઇન એક ઇન્ટરફેસનું નામ લે છે, જ્યારે જવાબ બીજા દ્વારા નીકળી ગયો હોઈ શકે છે, તેથી સંદેશમાંનું ઇન્ટરફેસ પેકેટ ક્યાં જોવાયું તે વર્ણવે છે, વાતચીતનો આકાર નહીં. એટલે જ પહેલો પ્રશ્ન એ છે કે તમે કયો વિનિમય જોઈ રહ્યા છો, કઈ લિંક ખામીયુક્ત છે તે નહીં.
પુનઃપ્રસારણ ખરેખર તમને શું કહે છે
IKEv2 માં, પુનઃપ્રસારણ આ રીતે કામ કરે છે: જવાબ ન આવ્યો હોય ત્યારે વિનંતીકર્તા વિનંતીનું પુનરાવર્તન કરે છે, અને જવાબ આપનાર નવો ગણતરી કરવાને બદલે તેનો કેશ કરેલો જવાબ ફરી મોકલી શકે છે. સંદેશ ઓળખકર્તાઓ તે વિનિમયના છે, અને એટલે જ સમાન ઓળખકર્તા સાથેની પુનરાવર્તિત વિનંતી નવો પ્રયાસ નહીં પણ પ્રોટોકોલનું કામ ઓળખાય છે. પ્રારંભિક પ્રયાસને સહસંબંધ માટે ઘણી વાર સ્રોત સરનામા કે ઇનિશિયેટર SPI કરતાં વધુ જરૂર પડે છે, તેથી પ્લેટફોર્મનું પોતાનું વિનિમય રેકોર્ડ પેકેટ યાદી કરતાં સારું છે. IKEv1 જુદા ઓળખકર્તાઓ સાથે જુદા નિયમો અનુસરે છે, અને પ્રથમ પેકેટના ડુપ્લિકેટ વિશે વેન્ડરની ચેતવણી બધી આવૃત્તિઓમાં એક અર્થ ધરાવતી નથી.
તેથી પુનઃપ્રસારણનો સમયગુણ કહે છે કે ટાઇમર સમાપ્ત થયો. તે કહેતું નથી કઈ હોપ ધીમી હતી, અને ચોક્કસપણે કહેતું નથી કે ઓપરેટર દોષિત છે. એ અલગ દાવા છે, અને ટિકિટમાં ફક્ત બીજો જ ઉપયોગી છે.
વ્યવહારુ પરિણામ એ છે કે નિષ્કર્ષ કાઢતા પહેલાં વિનિમય નોંધો. સ્થાનિક સ્વીકાર સરનામું, નીતિએ પસંદ કરેલો જવાબ માર્ગ, પીઅર ટ્યુપલ અને વિનિમય ઓળખકર્તાઓ એક જ જગ્યાએ લખો, કારણ કે રેકોર્ડ પછીથી વંચાય ત્યારે તેમાંથી દરેક અલગ પ્રશ્નનો જવાબ આપે છે.
એક શૃંખલા તરીકે ચાર અવલોકન બિંદુ
વિનિમયને શૃંખલાની ચાર કડીઓ તરીકે વિચારો, જોવા માટેની ચાર અલગ જગ્યાઓ તરીકે નહીં. કડી પુરાવો રાખે છે અથવા અજાણી રહે છે, અને શૃંખલા તેની સૌથી નબળી નોંધાયેલી કડી જેટલી જ માહિતીપ્રદ છે. નીચેનું કોષ્ટક યાદી છે: દરેક સ્થાન શું સ્થાપિત કરી શકે છે અને શું અડ્યા વિના છોડે છે.
| સ્થાન | તે આપી શકે તેવો પુરાવો | શું ખુલ્લું છોડે છે |
|---|---|---|
| ઇનિશિયેટર મોકલે છે | વિનંતી આ હોસ્ટ છોડી ગઈ | તે પીઅર સુધી પહોંચી કે નહીં |
| રિસ્પોન્ડર સ્વીકારે છે | વિનંતી પહોંચી | જવાબ બન્યો કે નહીં |
| રિસ્પોન્ડર મોકલે છે | જવાબ ગેટવે છોડી ગયો | તે ઇચ્છિત માર્ગ અનુસર્યો કે નહીં |
| ઇનિશિયેટર સ્વીકારે છે | વિનિમય પૂર્ણ થયો | નીતિએ પરિણામ સ્વીકાર્યું કે નહીં |
જ્યાં તમને પ્રવેશ છે ત્યાં જ શૃંખલા ભરો, અને બાકીનું અનુમાન કરવાને બદલે અજાણ્યું ચિહ્નિત કરો. એક મશીન પર પેકેટ નોંધતો હૂક દૂરના મશીને શું મેળવ્યું તે વિશે કંઈ કહેતું નથી, અને વિનંતી જોવાઈ એવી લોગ લાઇન એ પુરાવો નથી કે ક્યારેય જવાબ નીકળ્યો. પ્રામાણિક ગાળાઓ અનુમાનથી બનેલા પૂર્ણ દેખાતા રેકોર્ડ કરતાં વધુ ઉપયોગી છે.
પહેલું ખોવાયેલું સંક્રમણ શોધો
ઇનિશિયેટરથી બહારની તરફ શૃંખલા ચાલો અને પુરાવા વગરની પહેલી કડી પર અટકો. જો ગેટવે ક્યારેય વિનંતી લોગ ન કરે, તો ખામી તેની પહેલાના માર્ગ પર છે. જ્યારે ગેટવે એ જ વિનંતી વારંવાર લોગ કરે અને ક્લાયન્ટ ક્યારેય જવાબ લોગ ન કરે, ત્યારે પરત દિશા શંકાસ્પદ છે: સ્રોત સરનામું, અનુવાદ અને તમે નિયંત્રિત કરો તે દરેક સીમા પર ગાળણી. જો જવાબ આવે અને ક્લાયન્ટ તો પણ આગળ ન વધે, તો પ્રશ્ન પરિવહન છોડીને નીતિ કે સ્થિતિ બની ગયો છે.
તુલના કરતી વખતે પીઅર અને પ્રોટોકોલ સ્થિર રાખો, અને યાદ રાખો કે વિલંબ, નુકસાન, નીતિ અને સ્થિતિ દરેક અલગ સમયરેખા બનાવે છે. મોબાઇલ નેટવર્ક આપોઆપ કારણ નથી, અને ફિક્સ્ડ લાઇન દરેક જરૂરિયાત માટે આપોઆપ પૂરતી વિશ્વસનીય પણ નથી. વિનિમય જીવંત હોય ત્યારે બંને દિશાઓ કેપ્ચર કરો:
tcpdump -ni any -vv 'udp port 500 or udp port 4500'
જ્યારે દૂરના છેડા પહેલાં પ્રવેશ અટકે, તો રેકોર્ડ ક્યાં અટકે છે તે કહે તો પણ મદદ કરે છે. ફક્ત ઇનિશિયેટર પરનું કેપ્ચર બતાવી શકે કે વિનંતી નીકળે છે અને કોઈ જવાબ આવતો નથી, જે ખામીને તે હૂક પછીની દરેક વસ્તુ સુધી સંકુચિત કરે છે, કઈ હોપે તેને પાડ્યું તે જાણવાનો ઢોંગ કર્યા વિના. દૂરની કડીઓને અજાણી ચિહ્નિત કરો અને પ્રવેશ ધરાવતી આગલી વ્યક્તિને તે ભરવા દો. આ રીતે લખવાથી રેકોર્ડ પ્રામાણિક અને હજી ટૂંકો રહે છે.
કંઈપણ બદલતા પહેલાં તુલના કરો. એ જ પીઅર સામે એ જ પ્રોટોકોલ સાથે એ જ વિનંતીનું પુનરાવર્તન ચલોને ગણી શકાય તેવા રાખે છે, જ્યારે કેપ્ચર વચ્ચે રીસેટ, કી નવીકરણ કે નીતિ સંપાદન તુલનાનો નાશ કરે છે. જો ફેરફાર અનિવાર્ય હોય, તો તરત જ પછી ફરી કેપ્ચર કરો જેથી પહેલાં અને પછી હજી એ જ વિનિમયનું વર્ણન કરે.
ઉપયોગી અહેવાલ શું કહે છે
કાર્ય યોગ્ય અહેવાલ એક વિનંતીને તેના જવાબ સાથે જોડે છે અને પાછળ પુરાવો ન હોય તેવું પહેલું પગલું નામ આપે છે. એ વાક્ય એક અઠવાડિયા પછી ત્યાં ન હતા તેવા ઇજનેર દ્વારા વંચાવાનું ટકી રહે છે, અને આગલી વ્યક્તિને શંકાસ્પદ વ્યક્તિને બદલે શરૂઆતનું સ્થળ આપે છે.
ફક્ત પુનઃપ્રસારણનો સિદ્ધાંત ચકાસવા માટે ઓળખ ચકાસણી ક્યારેય નબળી ન કરો કે માન્ય પ્રોટોકોલ સમૂહને પહોળો ન કરો. કોઈપણ રીસેટ પહેલાં મૂળ પેકેટ અને ઘટના રેકોર્ડ સાચવો, કારણ કે રીસેટ બરાબર એ જ સામગ્રીનો નાશ કરે છે જે તમે એકત્રિત કરવાના હતા અને એ સમય હટાવે છે જે બતાવતો હતો કે વિનિમય ક્યાં અટક્યો.
ભ્રમ એ છે કે એક ડુપ્લિકેટ સાબિત કરે છે કે ઓપરેટર દોષિત છે. વાસ્તવિકતા એ છે કે એક ડુપ્લિકેટ સાબિત કરે છે કે ટાઇમર સમાપ્ત થયો, અને જવાબ જવાબના માર્ગ પર જીવે છે.