strongSwan থেকে AWS Site-to-Site: কেন Child SA কিছুই নির্বাচন করে না

কনসোল স্ট্যাটাস আপ দেখাচ্ছে, strongSwan একটি প্রতিষ্ঠিত IKE অ্যাসোসিয়েশন রিপোর্ট করছে, তবুও প্যাকেট পৌঁছাচ্ছে না। এরপর তুলনা করতে হবে প্রি-শেয়ার্ড কী নয়, বরং যে দুটি প্রিফিক্স প্রতিটি পক্ষ মনে করে টানেল সেগুলো রক্ষা করছে। নিচের চেকগুলো ক্রমানুসারে দেখুন, কারণ প্রথম দুটি নির্ধারণ করে টানেল আদৌ আপনার ট্রাফিক বহন করতে পারবে কি না।

AWS-এর নামগুলো strongSwan-এর ভাষায় অনুবাদ করুন

AWS কাস্টমার সাইড থেকে সংযোগটি বর্ণনা করে: কাস্টমার গেটওয়ে ঠিকানা ও লোকাল CIDR আপনার, আর রিমোট CIDR হলো VPC-র। strongSwan দুই প্রান্তকে left ও right বলে, আপনার প্রিফিক্স থাকে leftsubnet-এ এবং VPC-র প্রিফিক্স থাকে rightsubnet-এ। একটি জোড়া উল্টে দিলে এমন টানেল তৈরি হয় যা ভুল ট্রাফিক নিয়ে নেগোশিয়েট করে ও নির্বাচন করে।

AWS যে কনফিগারেশন তৈরি করে তা ডাউনলোড করুন এবং টানেল ঠিকানা ও প্রিফিক্সসহ ঠিক ওই সংযোগের রেফারেন্স হিসেবে ধরে নিন। তৈরি করার সময় CIDR-এর দুটি ঘরই খালি রাখলে সার্ভিসটি প্রতিটি পাশে 0.0.0.0/0 ডিফল্ট ব্যবহার করে। সংকীর্ণ প্রিফিক্স দিয়ে কনফিগার করা রাউটার তখন কখনোই এর সঙ্গে মিলবে না, তাই হয় ঘরগুলো পূরণ করুন, নয়তো সচেতনভাবে সিলেক্টর প্রশস্ত করুন।

এখানে অমিলটি রাউটিং ব্যর্থতার মতো দেখায়, কিন্তু তা নয়।

AWS আসলে যে ঠিকানা দেখে তা পিন করুন

NAT-এর পেছনের রাউটার এমন ইন্টারফেস থেকে IKE পাঠাতে পারে যা অপর পক্ষ কখনো জানেনি। AWS-এ রেকর্ড করা গেটওয়ে ঠিকানাটিকেই AWS তারের উপর দেখে, এবং রাউটারকে তার ডিফল্ট রুট অনুসরণ না করে একই লোকাল ঠিকানায় পিন করতে হবে।

conn %default
    local_addrs = 203.0.113.10

strongSwan-এ local_addrs IKE-র জন্য সোর্স ঠিকানা নির্বাচন করে, আর পুরনো OpenSwan কনফিগারেশন একই ধারণাকে left নামে লেখে। এটিকে পাবলিক ঠিকানা থাকা ইন্টারফেসে নির্দেশ করুন, তারপর NAT ডিভাইসেই যাচাই করুন যে UDP 500 এবং 4500 ওই হোস্টে পৌঁছায়, কারণ আগের রাউটার থেকে পড়ে থাকা নিয়ম সেগুলো নীরবে ফেলে দেয়। সঠিক সিলেক্টর জোড়া ভুল সোর্স ঠিকানার সঙ্গে তবুও ব্যর্থ হয়, আর লগ প্রস্তাবটিকে দোষ দেবে। এই ভুল নির্দেশনার কারণেই সোর্স ঠিকানার আলাদা যাচাই দরকার।

ফরওয়ার্ডিং নিয়মটি ধরে নেওয়ার বদলে নিশ্চিত করুন, কারণ আগের রাউটারের জন্য সঠিক ছিল এমন নিয়ম প্রায়ই পড়ে থাকে।

ফেজ 1 এবং ফেজ 2 আলাদাভাবে দেখুন

AWS IKE ও ESP অপশনগুলো আলাদা তালিকা হিসেবে দেখায়। উভয় পক্ষ যে IKE স্যুট গ্রহণ করে তা ESP প্রস্তাব সম্পর্কে কিছুই বলে না, কারণ দুটি তালিকা স্বতন্ত্র। তৈরি কনফিগারেশন থেকে দুটোই পড়ুন এবং একবারে একটি করে তুলনা করুন।

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

সিনট্যাক্স এক ইমপ্লিমেন্টেশন থেকে অন্যত্র চলে না। OpenSwan-এ কাজ করা একটি জোড়া, যেমন phase2alg=aes_gcm সঙ্গে ike=aes256-sha1;modp1024, strongSwan-এর esp= ও ike= রূপে অনুবাদ করতে হয়, আর অ্যালগরিদমের নামগুলো আলাদা। GCM এনক্রিপ্ট করার সঙ্গে সঙ্গে প্রমাণীকরণ করে, তাই এর আলাদা ইন্টিগ্রিটি ট্রান্সফর্ম দরকার হয় না, SHA-এর সঙ্গে জোড়া CBC স্যুটের বিপরীতে। এক ডেমন থেকে আরেকটিতে অনুবাদ ছাড়া পেস্ট করা phase 2 লাইন সিলেক্টর অমিলের মতো শোনানো প্রত্যাখ্যান তৈরি করে।

টানেল ইন্ডিকেটর নয়, চাইল্ড অ্যাসোসিয়েশন যাচাই করুন

সংযোগ লোড হয় কিন্তু কোনো চাইল্ড অ্যাসোসিয়েশন না উঠলে হয় প্রস্তাব বা সিলেক্টরগুলো প্রত্যাখ্যাত হয়েছে। চাইল্ড উঠলেও যদি তার সিলেক্টর আপনার প্রিফিক্স বাদ দেয়, প্যাকেটগুলো টানেলে পৌঁছানোর আগেই ফিল্টার হয়। কনসোলের ইন্ডিকেটর কেবল IKE স্তর দেখায়, তাই দুটির মধ্যে কোনটি ঘটেছে তা বলতে পারে না।

ipsec statusall

চাইল্ড সিকিউরিটি অ্যাসোসিয়েশন খুঁজুন এবং তার পাশে ছাপা ট্রাফিক সিলেক্টরগুলো পড়ুন, তারপর তৈরি কনফিগারেশনের প্রিফিক্সের সঙ্গে তুলনা করুন।

লোকাল প্রিফিক্সের ভেতরের হোস্ট থেকে VPC প্রিফিক্সের ভেতরের হোস্টে পরীক্ষা করুন এবং ফিরতি পথসহ AWS পাশের যেকোনো সিকিউরিটি গ্রুপ বা নেটওয়ার্ক ACL যাচাই করুন। সঠিক সিলেক্টর প্যাকেটকে পরে ফেলে দেওয়া থেকে রক্ষা করে না।

সিলেক্টর মিলে যাওয়ার পরেও ব্যর্থ হলে

উভয় পাশে রুট টানেলের দিকে যাচ্ছে কি না নিশ্চিত করুন, তারপর নিশ্চিত করুন NAT ডিভাইসটি পলিসি যা প্রত্যাশা করে না এমনভাবে ট্রাফিক পুনর্লিখন করছে না। পলিসি-ভিত্তিক টানেল প্যাকেট ঠিকানার সঙ্গে মেলে, তাই পলিসি সিদ্ধান্তের পরে প্রয়োগ করা ট্রান্সলেশন ফলাফল বদলে দেয়।

আরেকটি প্রস্তাব বদলানোর আগে প্রতিটি পাশে একটি ইন ও একটি আউট প্যাকেট লগ করুন।

টিকিটে সিলেক্টরগুলো, ফেজ 1 ও ফেজ 2 প্রস্তাব এবং সোর্স ঠিকানা লিখে রাখুন। এই চারটি মান ফোন কল ছাড়াই বেশিরভাগ site-to-site ব্যর্থতা ব্যাখ্যা করে।