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 গ্রুপ হিসেবে লিখে রাখুন, তারপর যে এক্সচেঞ্জগুলোকে এটি সুরক্ষিত করার কথা সেখানেই তা নিশ্চিত করুন। রাউটিং, ট্রাফিক সিলেক্টর ও অ্যাপ্লিকেশন অনুমতি আলাদা থাকে; এই ম্যাপিং সম্পূর্ণ গেটওয়ে কনফিগারেশন নয়, এবং বৈচিত্র্যের জন্য অতিরিক্ত অ্যালগরিদম চালু করার সুপারিশও নয়।