ESP બરાબર ડિક્રિપ્ટ કરે છે અને અંદરનું પેકેટ તો ક્યાંય જતું નથી

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

લેબલ જ્યારે ખોટું બોલે ત્યારે શું દેખાય

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

વધતું રિસીવ કાઉન્ટર ખરેખર સારા સમાચાર છે: પેકેટ આવે છે અને પ્રમાણિત થાય છે. પરંતુ તે પુરાવો નથી કે અંદરનું પેકેટ ક્રિપ્ટો સ્તરની ઉપરની કોઈ વસ્તુ માટે અર્થપૂર્ણ હતું.

પ્રકાર ટ્રેલરમાં રહે છે

સામાન્ય IPsec ટનલ મોડમાં, ESP-સુરક્ષિત પેલોડમાં સંપૂર્ણ અંદરનું IP પેકેટ હોય છે. ટ્રેલરનું આગળના હેડરનું ક્ષેત્ર નક્કી કરે છે કે એ પેલોડ શું છે, અને તે TCP પોર્ટ નથી, બહારના હેડરમાં પ્રોટોકોલ નંબર નથી, અને શરૂઆતના SPI તથા ક્રમ-નંબર ક્ષેત્રનો ભાગ પણ નથી. RFC 4303 વિભાગ 2.6 તેને પેલોડ-પ્રકાર ક્ષેત્ર તરીકે વ્યાખ્યાયિત કરે છે, જે ચોક્કસ કામ માટે ચોક્કસ નામ છે.

તમને મળતા મૂલ્યો નાના છે અને યાદ રાખવા લાયક છે: IPv4 એ 4 (0x04) છે અને IPv6 એ 41 (0x29) છે.

એ નંબરો સ્થાનિક પરંપરામાંથી નહીં, IANAના પ્રોટોકોલ નંબર ફાળવણીમાંથી આવે છે. જે પ્રેષક IPv4 જાહેર કરે છે પણ IPv6 પેકેટ લપેટે છે, તેણે ફોર્મેટની અસંગતિ ઊભી કરી છે, અને પોતાના લેબલની વિરુદ્ધ જતા બાઇટ્સને કોઈ ફાયરવોલ નિયમ સુધારતો નથી.

સામાન્ય શંકાસ્પદોથી તેને કેવી રીતે અલગ પાડવું

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

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

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

સમારકામ જે નથી

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

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

પ્રવાહ ચકાસો, કાઉન્ટર નહીં

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

બંને પરિણામ ટિકિટમાં નોંધો. કાઉન્ટરની હિલચાલ સાથે કામ કરતો પ્રવાહ એ સમારકામ છે; ફક્ત કાઉન્ટરની હિલચાલ એ તો બરાબર એ જ છે જે તમારી પાસે શરૂ કરતા પહેલાં હતું.