IPsec પ્રસ્તાવમાં શું જાય છે? IKE અને ESP ક્ષેત્રો
પ્રસ્તાવ એ એક સંપૂર્ણ ઑફર છે, એલ્ગોરિધમની થેલી નહીં. જુઓ કયા ક્ષેત્રો IKE સાથે સંબંધિત છે અને કયા ESP સાથે, અને કેમ એક જ અસંગતિ આખો સમૂહ નકારી કાઢે છે.
IKE શરૂ થાય છે, બંને પીઅર AES ઘોષિત કરે છે, અને ટનલ હજી પણ NO_PROPOSAL_CHOSEN સાથે નિષ્ફળ જાય છે. લોગ પ્રસ્તાવનું નામ આપે છે પણ જે ક્ષેત્ર મેળ ખાધું નહીં તે નહીં. પ્રસ્તાવ એ એક સંપૂર્ણ ઑફર છે, અને એક અસંગત ક્ષેત્ર આખા સંયોજનને અમાન્ય કરે છે, ફક્ત એ લાઇનને નહીં. તેને સ્વતંત્ર એલ્ગોરિધમ પસંદગીઓની થેલી તરીકે વાંચવું એ જ સામાન્ય કારણ છે કે અસંગતિ અદૃશ્ય રહે છે.
અલગ પ્રસ્તાવ-યાદીઓ સાથે બે વાટાઘાટો
IKEv2 બે સુરક્ષા સંગઠનો બનાવે છે. પ્રથમ IKE SA છે, જે નિયંત્રણ વિનિમયને પોતે સુરક્ષિત રાખે છે, અને બીજું CHILD SA છે, જે તમારો ટ્રાફિક ESP દ્વારા વહન કરે છે. દરેકની પોતાની પ્રસ્તાવ-યાદી છે, અને પીઅર એકને સ્વીકારી શકે છે અને બીજાને નકારી શકે છે.
એ વિભાજન એક સામાન્ય મૂંઝવણ સમજાવે છે: કાર્યક્ષમ IKE SA ફક્ત એ સાબિત કરે છે કે નિયંત્રણ-ચેનલના એલ્ગોરિધમ મેળ ખાધા. જો CHILD પ્રસ્તાવ નિષ્ફળ જાય, તો ટનલ એક પણ પેકેટ વહન કરતું નથી, જોકે પ્રથમ તબક્કો પૂર્ણ થયો છે અને લોગ ઉપર સ્વસ્થ દેખાય છે.
દરેક યાદીમાં ક્રમ પણ મહત્વનો છે. પ્રતિસાદકર્તા આરંભકર્તાની ક્રમબદ્ધ ઑફરોમાંથી પસંદ કરે છે, તેથી વિશાળ રીતે સુસંગત એન્ટ્રીને સાંકડી એન્ટ્રી ઉપર ખસેડવાથી કયો સેટ સ્થાપિત થશે તે બદલાય છે, જ્યારે કોઈ એલ્ગોરિધમનું નામ બદલાતું નથી. ડિફૉલ્ટ પર આધાર રાખવાને બદલે એ ક્રમને રૂપરેખાંકનમાં પિન કરો. સ્થિર ક્રમ સાઇટો વચ્ચે લોગ સરખામણીને પણ અર્થપૂર્ણ બનાવે છે.
કયા ક્ષેત્રો કયા પ્રસ્તાવના છે
ક્ષેત્રોનો સમૂહ નાનો છે, પણ બે વાટાઘાટોમાં તે સમાન નથી. કોષ્ટક પંક્તિ પંક્તિ વાંચો, કારણ કે એક સ્તંભનું ક્ષેત્ર બીજામાં ગેરહાજર હોઈ શકે. વાક્યરચના અમલીકરણ પ્રમાણે બદલાય છે; strongSwan નું પ્રસ્તાવ-દસ્તાવેજીકરણ એક નક્કર સંદર્ભ છે.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
એન્ક્રિપ્શન ક્ષેત્ર સાઇફરનું અને મોટાભાગની વાક્યરચનાઓમાં તેની કી-લંબાઈનું નામ આપે છે. અખંડિતતા ક્ષેત્ર સાઇફરટેક્સ્ટને પ્રમાણિત કરવા વપરાતા હેશનું નામ આપે છે, અને PRF તે ફંક્શનનું નામ આપે છે જે IKE SA માટે કી-સામગ્રી મેળવે છે. DH જૂથ નવી સહિયારી ગુપ્ત સામગ્રી સ્થાપે છે, તેથી જ તે બંને બાજુ દેખાય છે પણ જુદા હેતુઓ માટે.
વિસ્તૃત ક્રમ-સંખ્યાઓ ફક્ત ડેટા-માર્ગ સાથે સંબંધિત છે. તે ક્રમ-અવકાશને પહોળો કરે છે અને CHILD પ્રસ્તાવના ભાગ રૂપે વાટાઘાટ થાય છે, તેથી ત્યાંની અસંગતિ CHILD ઑફરને નકારે છે જ્યારે IKE SA અસ્પૃષ્ટ રહે છે.
એક સંપૂર્ણ ઑફર કેવી રીતે પસંદ થાય છે
દરેક પ્રસ્તાવ એક સમૂહ છે, અને પ્રતિસાદકર્તા એવો સમૂહ શોધે છે જેમાં દરેક જરૂરી ક્ષેત્ર સ્વીકાર્ય હોય. બે યાદીઓમાં બંનેમાં AES અને SHA-256 હોઈ શકે અને તો પણ કોઈ સુસંગત એન્ટ્રી ન હોય, કારણ કે કી-લંબાઈ, PRF અથવા DH જૂથ જુદા હોય છે. સરખામણી દરેક પ્રસ્તાવ પ્રમાણે થાય છે, દરેક એલ્ગોરિધમ પ્રમાણે નહીં.
જ્યારે કંઈ મેળ ખાતું નથી, ત્યારે પ્રતિસાદકર્તા નિષ્ફળ ગયેલા SA પ્રકાર સાથે NO_PROPOSAL_CHOSEN મોકલે છે. રૂપરેખાંકન સંપાદિત કરતા પહેલાં વાંચો કે સૂચના કઈ પ્રસ્તાવ-યાદીને લગતી છે; IKE પ્રસ્તાવ નકારાયો હોય ત્યારે ESP એલ્ગોરિધમ બદલવાથી ડિબગિંગ ચક્ર વેડફાય છે.
પ્રોફાઇલ ગોઠવતી વખતે પસંદગી-વર્તન જાણવું યોગ્ય છે. કેટલાક અમલીકરણો આરંભકર્તાનો ક્રમ પસંદ કરે છે, અન્ય સ્થાનિક નીતિ પ્રમાણે ફરી ગોઠવે છે, તેથી બે વેન્ડરો વચ્ચે કામ કરતો સેટ અદૃશ્ય થઈ શકે છે જ્યારે તમે ઉલટાવો કે કઈ બાજુ જોડાણ શરૂ કરે છે.
AEAD ક્ષેત્ર ઉમેરવાને બદલે દૂર કરે છે
AES-GCM અને ChaCha20-Poly1305 એક જ ક્રિયામાં પ્રમાણીકરણ અને એન્ક્રિપ્શન કરે છે. તેમાંથી કોઈપણ ESP માટે પસંદ થાય ત્યારે અખંડિતતા એલ્ગોરિધમ અલગથી વાટાઘાટ થતું નથી, કારણ કે AEAD રચના તેને પહેલેથી આવરી લે છે. તેથી AES-GCM ને SHA-256 સાથે જોડતો પ્રસ્તાવ શ્રેષ્ઠ સ્થિતિમાં વધારાનો છે અને સૌથી ખરાબ સ્થિતિમાં નકારાયેલો.
PRF IKE બાજુ પર હજી અલગ છે, કારણ કે તે પેલોડની સુરક્ષાને બદલે નિયંત્રણ ચેનલ માટે કી મેળવે છે. એટલે જ IKE પ્રસ્તાવ કાયદેસર રીતે AEAD સાઇફરને PRF અને DH જૂથ સાથે જોડી શકે છે, જ્યારે અનુરૂપ ESP પ્રસ્તાવ ફક્ત AEAD સાઇફર અને વૈકલ્પિક PFS જૂથની યાદી આપે છે.
કી-લંબાઈ એન્ક્રિપ્શન ટોકનનો ભાગ છે, તેથી AES-128-GCM અને AES-256-GCM જુદી ઑફરો છે. 256-bit કી ધારી લેતી માર્ગદર્શિકામાંથી નકલ કરેલી પ્રોફાઇલ 128-bit માટે રૂપરેખાંકિત એન્ડપોઇન્ટ સાથે મેળ ખાશે નહીં, જોકે બંને લાઇન AES-GCM કહે છે. બે પીઅર સાઇફર કુટુંબ પર સહમત થઈ શકે છે અને તો પણ ડેશ પછીની સંખ્યાને કારણે એકબીજાને નકારી શકે છે.
સ્થાપિત SA વાંચો, રૂપરેખાંકન નહીં
રૂપરેખાંકિત પ્રસ્તાવ-યાદી એ ઑફર છે; સ્થાપિત SA એ પરિણામ છે. strongSwan અને Linux કર્નલ પર બંને દૃશ્યો ઉપલબ્ધ છે:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas દરેક SA માટે વાટાઘાટ થયેલા એલ્ગોરિધમ છાપે છે, જેમાં CHILD AEAD વાપરે છે કે નહીં તે પણ સામેલ છે. ip xfrm state કર્નલે ખરેખર શું સ્થાપિત કર્યું તે બતાવે છે, અને કી-નવીકરણ તમે દસ્તાવેજીકૃત કરેલા કરતાં જુદા સમૂહ પર પાછું ન ગયું તેની પુષ્ટિ કરવાની જગ્યા એ જ છે.
સુધારા પછી એ આઉટપુટને રૂપરેખાંકનની બાજુમાં સાચવો. જ્યારે ક્લાઇન્ટ અપડેટ તેના ડિફૉલ્ટ બદલે છે, ત્યારે નોંધાયેલ સમૂહ તમને સરખામણી માટે આધારરેખા આપે છે, અને સરખામણી તપાસ શરૂઆતથી શરૂ કરવાને બદલે ખસેડાયેલ ક્ષેત્ર તરફ ઇશારો કરે છે.