IPsec બાળ SA ચાલુ છે, પણ પેકેટ કાઉન્ટર શૂન્ય જ રહે છે

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

શૂન્ય કાઉન્ટર ખરેખર શું સાબિત કરે છે

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

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

મોકલતા પહેલાં જે પ્રવાહનું વર્ણન કરી શકો તે મોકલો

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

સ્રોત સરનામું એ મૂલ્ય છે જે લોકો છોડી દે છે, અને તે જ કસોટીને સૌથી વધુ તોડે છે. વાયર્ડ સરનામું, Wi-Fi સરનામું અને ટનલ સરનામું ધરાવતો લેપટોપ રૂટ શોધના આધારે એમાંથી કોઈપણ બાંધી શકે છે, અને ફક્ત એક જ વાટાઘાટ કરેલી શ્રેણીમાં હોઈ શકે. એવું સાધન વાપરો જે સ્રોત પિન કરવા દે, જેમ કે ping -I 10.1.0.5 10.2.0.9 અથવા curl --interface 10.1.0.5, જેથી પેકેટ ચૂપચાપ બીજું સરનામું પસંદ ન કરી શકે. જ્યારે પિન કરેલી રન કાઉન્ટર ખસેડે અને પિન ન કરેલી ન ખસેડે, ત્યારે તમે રૂટિંગ સમસ્યા શોધી છે, IPsec સમસ્યા નહીં.

કયા આંકડા વાંચવા, અને તે ક્યાં રહે છે

Linux પર ip -s xfrm state દરેક સંગઠનને lifetime current: લીટી સાથે છાપે છે જેનો કુલ બાઇટ અને પેકેટ સરવાળો ફક્ત તે SAનો છે, ત્યારપછી રીપ્લે અને ભૂલ કાઉન્ટર માટે stats: લીટી આવે છે. strongSwan પીઅર પર swanctl --list-sas દરેક ઇન્સ્ટોલ થયેલા બાળ માટે એક in લીટી અને એક out લીટી દર્શાવે છે, દરેક બાઇટ ગણતરી અને પેકેટ ગણતરી પર પૂરી થાય છે; જૂનાં stroke સાધનો એ જ જોડીને bytes_i અને bytes_o કહે છે. બંને દિશા અલગ વાંચો, કારણ કે સપાટ રહેલી દિશા જ તારણ છે. બંનેને સરવાળે કરવાથી તમે જે અસમમિતિ શોધો છો તે જ છુપાય છે.

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

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

રૂટ, સિલેક્ટર અને પેકેટ ક્યાં જન્મ્યું

ત્રણ વસ્તુઓ સાથે સાથે સરખાવો: કર્નલ તમારા ગંતવ્ય માટે જે રૂટ પસંદ કરે છે, જે નીતિ ટ્રાફિકને ટનલમાં દોરે છે, અને બાળ SAએ વાટાઘાટ કરેલી સિલેક્ટર જોડી. ip route get 10.2.0.9 from 10.1.0.5 એ ઇન્ટરફેસ અને સ્રોતનું નામ આપે છે જે કર્નલ વાપરતું, અને તે ઘણી વાર તમે ધારેલી જોડી નથી હોતી. ip xfrm policy સ્થાનિક રીતે ઇન્સ્ટોલ થયેલા નમૂના અને સિલેક્ટર દર્શાવે છે, જ્યારે swanctl --list-sas દર્શાવે છે કે પીઅર શું સ્વીકારવા સહમત થયું. જે શોધ પેકેટને ભૌતિક ઇન્ટરફેસ દ્વારા બહાર મોકલે છે તે નીતિ સુધી પહોંચતી જ નથી, તેથી કાઉન્ટર ખસી શકતા નથી.

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

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

એક પાછું વાળી શકાય તેવો ફેરફાર અને સમીક્ષા ટકી રહે તેવો અહેવાલ

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

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