DPD પ્રતિસાદો સાબિત કરે છે કે IKE પીઅર જીવંત છે, તમારો ડેટા વહે છે એ નહીં
જીવંતતાના પ્રતિસાદો, પેડિંગ સૂચના અને સાંકડા થયેલા સિલેક્ટર ત્રણ અલગ વસ્તુઓ વર્ણવે છે. અટકને કોઈ એકને દોષ આપતા પહેલાં તેમને અલગથી વાંચો.
IPsec લોગ તેમની સામેની એપ્લિકેશન અટકી રહી હોય ત્યારે પણ જીવંતતાના પ્રતિસાદો દર્શાવી શકે છે, અને બંને હકીકતો એકસાથે સાચી હોઈ શકે છે. DPD પ્રતિસાદ સ્થાપિત કરે છે કે પીઅરની IKE પ્રક્રિયાએ તે ક્ષણે જવાબ આપ્યો હતો; તે એ વિશે કંઈ કહેતું નથી કે ચાઇલ્ડ SA તમારા માટે મહત્વપૂર્ણ પેકેટ વહન કરે છે કે નહીં. ઓછામાં ઓછા વિક્ષેપની નજીકના દરેક ચેતવણીને તેના કારણ તરીકે ગણવો એ જ રીત છે જેમાં સિલેક્ટર સમસ્યાનું નિદાન પ્રોટોકોલ બગ તરીકે થાય છે. ત્રણ અવલોકનો સૌથી વધુ ગૂંચવાય છે, અને તે ત્રણ અલગ પ્રશ્નોના જવાબ આપે છે. સમયચિહ્ન પ્રમાણે વાંચતા પહેલાં તેમને સંબંધ અને હેતુ પ્રમાણે વાંચો.
દરેક અવલોકન શું સાબિત કરે છે
કોષ્ટક દરેક અવલોકન શું સ્થાપિત કરે છે અને તે ફક્ત શું સાથે લાવે છે તેને અલગ કરે છે.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
ત્રણમાંથી કોઈ પણ જાતે જ ભૂલ નથી. દરેક ફક્ત તમે ડિબગ કરી રહ્યા હો તે પ્રવાહની બાજુમાં જ રસપ્રદ બને છે, અને જે પંક્તિ ચોક્કસ પ્રવાહ સાથે જોડી શકાતી નથી તે પુરાવો નહીં, સંદર્ભ છે.
જીવંતતા એ ડેટાનું સ્વાસ્થ્ય નથી
DPD INFORMATIONAL વિનિમય તરીકે ચાલે છે, IKE ડિમન વચ્ચેની નિયંત્રણ-સપાટીની વાતચીત. પ્રતિસાદ સાબિત કરે છે કે પીઅરની IKE પ્રક્રિયા પહોંચી શકાય તેવી છે અને જવાબ આપવા તૈયાર છે, અને સમય સમાપ્તિ સાબિત કરે છે કે તે નથી. બંનેમાંથી કોઈ પરિણામ ચાઇલ્ડ SA, સિલેક્ટર, ફોરવર્ડિંગ માર્ગ કે એપ્લિકેશનના જવાબની કસોટી કરતું નથી, તેથી અટકેલા ટ્રાન્સફરની બાજુમાં સ્વસ્થ DPD એ સુસંગત ચિત્ર છે, વિરોધાભાસ નહીં.
તેથી લોગની ટોચ પર કેટલું આશ્વાસનજનક લાગે તે પ્રમાણે, જીવંતતાની લાઇનો ડેટા-સપાટીની ટિકિટનો સૌથી ઓછો ઉપયોગી ભાગ છે.
પેડિંગ સૂચના પેડિંગ વિશેનું નિવેદન છે
TFC પેડિંગ આ લોગમાં સૌથી વધુ વધારે વંચાતી લાઇન છે. તે કહે છે કે ટ્રાફિક-ફ્લો-ગોપનીયતા પેડિંગ તે ચાઇલ્ડ SA માટે સ્વીકારવામાં આવશે નહીં, જે ESP સંરક્ષણનો અસ્વીકાર નહીં પણ વૈકલ્પિક પેડિંગ સુવિધા વિશેનું નિવેદન છે. નિષ્ફળતાની નજીક તેને મળવું સામાન્ય રીતે શબ્દાડંબરનો સંયોગ છે, અને પેડિંગ ચાલુ કે બંધ કરવાથી સિલેક્ટર કવરેજમાં કંઈ બદલાતું નથી.
IKEv2 વિનિર્દેશ સૂચના અને સિલેક્ટર વાટાઘાટ બંનેને વ્યાખ્યાયિત કરે છે, અને અમલીકરણનું ચેતવણી લેબલ બંનેમાંથી કોઈ પણ સ્થિતિમાં પ્રોટોકોલના અર્થનું સ્થાન લેતું નથી.
સાંકડું કરવું વધુ શાંત છે અને તેનું મહત્વ હોવાની શક્યતા વધુ છે
પ્રતિસાદ આપનાર સૂચિત સિલેક્ટરનો ઉપગણ સ્વીકારી શકે છે, અને સ્વીકૃત સમૂહ ઘણી એન્ટ્રીઓમાં છપાઈ શકે છે, એક પોર્ટ-લાયક અને બીજી બધા પોર્ટને આવરી લેતી. ફક્ત પ્રથમ પોર્ટ-લાયક લાઇન વાંચવાથી સ્વીકૃત થયેલું ઓછું અંદાજાય છે; ફક્ત પહોળી લાઇન વાંચવાથી તે વધુ અંદાજાય છે. છાપેલી દરખાસ્તને સ્થાપિત નીતિ સાથે સરખાવો, કારણ કે દરખાસ્ત એ છે જે પીઅરે કહ્યું અને નીતિ એ છે જે કર્નલ મેળવશે. જ્યારે તે અસહમત હોય, ત્યારે ટનલ અસ્તિત્વમાં છે અને ટ્રાફિક નથી, જે ક્લાસિક વિરામયુક્ત ફરિયાદ છે. પીઅરની સરખામણી કરતી વખતે સ્થાનિક અને દૂરના દૃષ્ટિકોણને ઉલટાવો, કારણ કે દરેક બાજુનું સ્થાનિક બીજી બાજુનું દૂરનું છે.
પોર્ટ પ્રતિબંધ સાથેના હોસ્ટ-વિશિષ્ટ એન્ટ્રીઓ બે વાર વાંચવા યોગ્ય છે, કારણ કે તે જ ICMP અથવા બીજા પોર્ટને બાકાત રાખે છે જ્યારે ગેટવે તરફનું ping કાર્યરત રહે છે.
નિષ્ફળ જતા પ્રવાહ માટે એક રેકોર્ડ બનાવો
સ્રોત, ગંતવ્ય, સરનામાં કુટુંબ, પ્રોટોકોલ અને પોર્ટ જેમ સંરક્ષણ નિર્ણય વખતે દેખાય તેમ નોંધો, જેમાં કોઈપણ જાણી જોઈને કરેલો અનુવાદ પણ સામેલ છે. આ એ મૂલ્યો છે જે સિલેક્ટર સાથે મેળ ખાવા જોઈએ, અને આ એ મૂલ્યો પણ છે જે ટિકિટ ત્રીજા હાથમાં પહોંચે ત્યારે લોકો યાદશક્તિમાંથી ફરી ટાઇપ કરે છે.
પછી ચાઇલ્ડ SA અને તેના દિશાત્મક કાઉન્ટર ઓળખો: swanctl --list-sas strongSwan હોસ્ટ પર સંગઠનનો સારાંશ આપે છે, અને ip -s xfrm state કાઉન્ટર આપે છે. તેમને તાજી મંજૂર કરેલી વિનંતી પછી વાંચો, સિસ્ટમ નિષ્ક્રિય હોય ત્યારે નહીં. આઉટબાઉન્ડમાં કોઈ વધારો ન હોવો તે પસંદગી અથવા સ્થાનિક માર્ગ તરફ સંકેત કરે છે; અનુરૂપ ઇનબાઉન્ડ વિનાનું આઉટબાઉન્ડ પીઅર, તેના ફોરવર્ડિંગ અથવા તેના પ્રતિસાદો તરફ સંકેત કરે છે.
પૂર્ણ થયેલો એપ્લિકેશન વિનિમય કોઈપણ કાઉન્ટર કરતાં વધુ મહત્વનો છે, તેથી પરીક્ષણ ટનલ સૂચક પર નહીં, એપ્લિકેશન પર પૂરો થવો જોઈએ.
પછી સુધારો પસંદ કરો
તે રેકોર્ડ અસ્તિત્વમાં હોય ત્યારે જ પસંદ કરવા માટે સુધારો હોય છે: સ્વીકૃત સિલેક્ટર, રૂટ, ફિલ્ટરિંગ, પીઅર અમલીકરણ, અથવા હવે તમે દર્શાવેલી સીમા. પીઅર ફરીથી સેટ કરવાથી એકસાથે ઘણી સ્થિતિઓ બદલાય છે અને ઘણી વાર કઈ ખોટી હતી તે સમજાવ્યા વિના ટ્રાફિક પુનઃસ્થાપિત કરે છે, તેથી વિક્ષેપ પાછો આવે છે. કર્નલ સ્થિતિના ડંપ ટિકિટની બહાર રાખો, કારણ કે તેમાં કી હોઈ શકે છે અને સાંકડો સારાંશ મદદ કરવા માંગતા કોઈપણ માટે પૂરતો છે.
જ્યારે રેકોર્ડ તમારા પ્રથમ સિદ્ધાંતનો વિરોધ કરે, ત્યારે રેકોર્ડ પર વિશ્વાસ કરો અને સિદ્ધાંત ફરીથી લખો; તે ટેવ અહીં ચર્ચાયેલી કોઈપણ એક લોગ લાઇન કરતાં વધુ મૂલ્યવાન છે.