AH કે ESP? પેકેટે શું સુરક્ષિત કરવું છે તેના પરથી નિર્ણય લો

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

AH શું આવરે છે જે ESP નથી આવરતું

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

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

NAT પસંદગીને મર્યાદામાં ફેરવે છે

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

જો હોય, તો AH બહાર પડે છે અને વાત ESP તથા તેની અલ્ગોરિધમ પસંદગી પર જાય છે. આ પસંદગી નહીં પણ મર્યાદા છે, તેથી તેનું સ્થાન નિર્ણયના અંતે નહીં પણ શરૂઆતમાં છે.

મોડ પ્રશ્નને ગુણે છે

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

સંયુક્ત મોડના ESP અલ્ગોરિધમ પછી બીજા પ્રોટોકોલ વગર અખંડિતતા નક્કી કરે છે. AES-GCM અને ChaCha20-Poly1305 એક જ રચનામાં પ્રમાણીકરણ અને એન્ક્રિપ્શન કરે છે, તેથી ઉપર AH ઉમેરવાથી કંઈ મળતું નથી પણ બીજું હેડર અને બીજી વાટાઘાટ ખર્ચ થાય છે. સ્થાપત્ય AH અને ESP સાથે મંજૂર કરે છે, અને વ્યવહારુ પ્રશ્ન છે તમારું ગેટવે અને આવૃત્તિ આ સંયોજનને ટેકો આપે છે કે નહીં અને પછી કોઈ તેની સંભાળ રાખી શકશે કે નહીં.

ફક્ત-AH માટે પ્રામાણિક વિકલ્પ

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

પ્રસ્તાવમાં ESP જોવું એ પણ એન્ક્રિપ્શનનો પુરાવો નથી. એન્ક્રિપ્શન અલ્ગોરિધમ વાંચો: NULL નોંધનો અર્થ ફક્ત અખંડિતતા, અને સંયુક્ત-મોડ નોંધનો અર્થ બંને.

ત્રણ પ્રશ્નોમાં નિર્ણય લો

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

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

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