IKEv2 ફ્રેગમેન્ટેશનને સર્ટિફિકેટ ચેઇનની સમસ્યાથી અલગ પાડવું

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

બે ફ્રેગમેન્ટેશન પદ્ધતિઓ, એક લક્ષણ

IKEv2 પાસે પોતાનું ફ્રેગમેન્ટેશન એક્સ્ટેન્શન છે, જે RFC 7383 માં વ્યાખ્યાયિત છે અને સુરક્ષિત IKE સંદેશાઓને નાના IKE સંદેશાઓમાં વિભાજિત કરે છે. બંને પક્ષો તે ક્ષમતા પર વાટાઘાટ કરે છે, અને સંદેશ IP સ્તર દ્વારા નહીં, IKE અમલીકરણ દ્વારા ફરી જોડાય છે.

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

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

નિષ્ફળ ગયેલો વિનિમય વાંચો

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

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

માર્ગ બદલો, સર્ટિફિકેટ નહીં

એ જ ક્લાયન્ટ, એ જ સર્ટિફિકેટ અને એ જ રૂપરેખાંકન બીજા નેટવર્કથી પરીક્ષણ કરો. મોબાઇલ હોટસ્પોટ સામાન્ય રીતે સૌથી સસ્તો બીજો માર્ગ છે, અને તે ઓફિસ લિંકથી ખરેખર અલગ છે, ફક્ત નામથી નહીં.

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

કંઈપણ સંપાદિત કરતા પહેલાં વિનિમય માપો

ચેઇનનું માપ અને માર્ગનું માપ મેળવો. બંને સંખ્યાઓ હેન્ડશેક શું મોકલી શકે તે મર્યાદિત કરે છે, અને બંને માપવા સસ્તા છે:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

પ્રથમ બે સર્ટિફિકેટની સંખ્યા અને ફાઇલનું માપ આપે છે, જે પ્રમાણીકરણ સંદેશ કેટલો મોટો હશે તેનો વાજબી સંકેત છે. ping પરીક્ષણ જણાવે છે કે તે માપનો ડેટાગ્રામ માર્ગ પર ટકી રહે છે કે નહીં, અને ઇન્ટરફેસ કાઉન્ટર દર્શાવે છે કે તમારા છેડે ફ્રેગમેન્ટ કાઢી નાખવામાં આવ્યા છે કે નહીં. Windows પર સમાન પરીક્ષણ do-not-fragment ધ્વજ અને સ્પષ્ટ પેલોડ માપ સાથેનું ping છે.

સફળ ન થાય ત્યાં સુધી પરીક્ષણ નીચેની દિશામાં પુનરાવર્તિત કરો. જે સૌથી મોટું માપ પસાર થાય તે તે માર્ગ માટેનું કાર્યકારી બજેટ છે, અને તે કોઈપણ પ્રકાશિત ડિફૉલ્ટ કરતાં વધુ ઉપયોગી છે.

ખરેખર તૂટેલું સ્તર સુધારો

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

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

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