AWS Site-to-Site VPN માં MODP3072 ક્યાં આવે છે
MODP3072 એ IANA જૂથ 15 છે, પણ જૂથ એક તબક્કા સાથે જોડાયેલું છે. ટનલ સંપાદિત કરતાં પહેલાં જરૂરિયાતને Phase 1 કે Phase 2 ની DH યાદીઓ સાથે મેળવો.
કોઈ તમને એવી જરૂરિયાત મોકલે છે જેમાં IKEv2, ESP અને MODP3072 લખેલા હોય છે, અને કન્સોલમાં એ નામનું કોઈ ફીલ્ડ નથી. ભૂલ એ છે કે એવું ફીલ્ડ શોધવા જવું. IKEv2 એ વાટાઘાટનું સંસ્કરણ છે, ESP એ પ્રોટોકોલ છે જે તમારો સુરક્ષિત ટ્રાફિક વહન કરે છે, અને MODP3072 એ કી-એક્સચેન્જ જૂથ છે, એટલે કે IANA જૂથ 15. એ ત્રણ હકીકતો ત્રણ અલગ જગ્યાએ રહે છે, અને જૂથ બે વાર દેખાય છે.
એ વાક્ય એક જ સેટિંગ નથી
કંઈપણ સ્પર્શ કરતાં પહેલાં જરૂરિયાતને વિકલ્પ યાદીઓમાં ફેરવો. નીચેનું કોષ્ટક આખું ક્રોસવોક છે.
| Agreed requirement | AWS option to review | Still a separate decision |
|---|---|---|
| IKEv2 | Allowed IKE versions | Encryption, integrity, key-exchange choices |
| MODP3072 for the IKE exchange | Phase 1 DH groups, group 15 | Phase 2 key-exchange and PFS policy |
| MODP3072 for the protected-traffic exchange | Phase 2 DH groups, group 15 | The initial IKE exchange group |
| A named encryption algorithm | That phase's encryption list | Integrity and DH-group agreement |
MODP3072 એ જૂથ 15 છે, અને AWS હાલમાં Phase 1 અને Phase 2 બંનેની DH જૂથ યાદીઓમાં 15 સ્વીકારે છે. બંને જગ્યાએ તેને સ્વીકારવું એ બંને જગ્યાએ તેની જરૂરિયાત રાખવા જેટલું નથી, અને તેનો અર્થ ચોક્કસપણે એ નથી કે તમારા ભાગીદારનો મતલબ બંને હતો.
Phase 1 અને Phase 2 અલગ અલગ વસ્તુઓ પર વાટાઘાટ કરે છે
Phase 1 IKE સુરક્ષા સંગઠન બનાવે છે: બે ગેટવે કેવી રીતે પ્રમાણિત થાય છે, કી પર સંમત થાય છે અને પોતાની વાતચીત સુરક્ષિત રાખે છે. Phase 2 એ CHILD SA બનાવે છે જે તમારો વાસ્તવિક ટ્રાફિક વહન કરે છે, અને તેનું કી-એક્સચેન્જ વારસાગતને બદલે નવું હોઈ શકે છે.
એ જ વિભાજનને કારણે ભાગીદાર perfect forward secrecy ની વાત કરે ત્યારે તે મહત્ત્વનું બને છે. PFS એ Phase 2 નું લક્ષણ છે, અને Phase 1 યાદીમાંનું જૂથ તે પૂરું પાડતું નથી. દરેક જરૂરિયાત કયા એક્સચેન્જ પર લાગુ પડે છે, સાથે એન્ક્રિપ્શન મોડ, શું અખંડિતતા AEAD સાઇફર આપે છે, અને બંને બાજુની કી-રિન્યુઅલ અપેક્ષાઓ પૂછો.
AES શબ્દમાંથી કે એક DH નંબરમાંથી સંપૂર્ણ સ્વીકાર્ય સેટ તારવો નહીં. બે વાતચીતના બે અડધા ભાગમાંથી બનેલી નીતિ એ જ રીત છે જેમાં ટનલ એવું કંઈક સૂચવે છે જેને કોઈ ટીમે સ્વીકાર્યું નથી.
મંજૂર યાદી એ વાટાઘાટનું પરિણામ નથી
વિકલ્પ યાદીઓ વર્ણવે છે કે દરેક પક્ષ કઈ વસ્તુ સ્વીકારવા તૈયાર છે. તેઓ જણાવતી નથી કે શું પસંદ કરવામાં આવ્યું. નવા કનેક્શન માટે ખરેખર પસંદ થયેલા IKE અને CHILD-SA પ્રસ્તાવો વાંચો, પછી ખાતરી કરો કે જરૂરિયાત ફક્ત મંજૂર નહીં પણ પૂરી થઈ છે. યાદીમાં રહેલો મજબૂત વિકલ્પ ફક્ત એ સાબિત કરે છે કે તે ઉપલબ્ધ હતો.
રિન્યુઅલ પર પણ નજર રાખો. પ્રથમ IKEv2 CHILD SA અને પછીનું PFS ધરાવતું CHILD એક્સચેન્જ જુદી જુદી સુસંગતતાની શરતો દર્શાવી શકે છે, કારણ કે બીજું એક્સચેન્જ PFS જૂથ સાથે તાજી કી સામગ્રી બનાવે છે. જો તમારી સ્વીકૃતિ કસોટી ટનલની ફક્ત પ્રથમ મિનિટ આવરે છે, તો તેણે તમારા ભાગીદારને મહત્ત્વનો ભાગ કસ્યો નથી.
AWS ટનલ-વિકલ્પ સંદર્ભ Phase 1 અને Phase 2 અલગ રીતે સૂચવે છે, અને આગળની જરૂરિયાત આવે તે પહેલાં આ માળખું આત્મસાત કરવા જેવું છે.
ખરેખર જે ટનલ કહેવી છે તે બદલો
Site-to-Site VPN કનેક્શનમાં બે ટનલ હોય છે, જેમની પોતાની વિકલ્પો અને પોતાની સ્થિતિ હોય છે. કંઈપણ સમીક્ષા કે સંપાદન કરતાં પહેલાં AWS ટનલનું બહારનું સરનામું ગ્રાહક-ગેટવે પીઅર સાથે મેળવો, અને એ ન માનો કે એક સેવ બંનેને અપડેટ કરે છે.
મંજૂર થયેલા ફેરફાર માટે ગ્રાહક-ગેટવે બાજુને એ જ નીતિ માટે તૈયાર કરવી પડે છે અને પસંદ કરેલી ટનલ જે વિક્ષેપ લેશે તેના માટે સમયગાળો જોઈએ છે. જે તબક્કો તમે બદલી રહ્યા છો તેમાં પીઅર જૂથ 15 માટે તૈયાર ન હોય, તો ટનલ ફક્ત ઉપર આવવાનું બંધ કરી દેશે, અને કન્સોલ તમને નહીં કહે કે કઈ બાજુએ નકાર્યું.
સંમત નીતિને તબક્કો, પ્રોટોકોલ સંસ્કરણ, એન્ક્રિપ્શન, અખંડિતતા અને DH જૂથ તરીકે નોંધો, પછી જે એક્સચેન્જને તે સુરક્ષિત કરવાની હોય ત્યાં તેની પુષ્ટિ કરો. રાઉટિંગ, ટ્રાફિક સિલેક્ટર અને એપ્લિકેશન પરવાનગીઓ અલગ રહે છે; આ મેપિંગ સંપૂર્ણ ગેટવે રૂપરેખા નથી, અને વૈવિધ્ય માટે વધારાના અલ્ગોરિધમ્સ સક્ષમ કરવાની ભલામણ પણ નથી.