VGW না TGW? AWS Site-to-Site IPsec টানেল কোথায় শেষ হয়

মানুষ জিজ্ঞেস করে AWS Site-to-Site VPN কোথায় প্যাকেট সুরক্ষা করা বন্ধ করে এবং একটিই উত্তর আশা করে: গেটওয়েতে। সেই উত্তরের কাজে লাগার মতো সংস্করণটি বলে দেয় কোন গেটওয়ে, কারণ ভার্চুয়াল প্রাইভেট গেটওয়ে আর ট্রানজিট গেটওয়ে ভিন্ন অ্যাটাচমেন্ট অবজেক্টসহ ভিন্ন ব্যবস্থা, আর যে পর্যালোচক ভুলটি ধরে নেন তিনি বাকি মূল্যায়নটি এমন একটি ডায়াগ্রামের ওপর গড়ে তোলেন যা নেই। নিচের তিনটি যাচাই ক্রমে করুন। প্রতিটি হয় সীমানা নিশ্চিত করে, নয়তো বলে যে আগের উত্তরটি অন্য কোনো রিসোর্স সম্পর্কে ছিল।

কিছু মূল্যায়নের আগে তিনটি প্রান্তবিন্দুর নাম দিন

এই পথের এনক্রিপশন পর্যালোচনার জন্য তিনটি নামকরণ করা জিনিস দরকার: কাস্টমার গেটওয়ে, IPsec সমাপ্তকারী AWS VPN টার্গেট, এবং অভ্যন্তরীণ প্যাকেট গ্রহণকারী অ্যাপ্লিকেশন প্রান্তবিন্দু। একটিও কনসোল পৃষ্ঠা খোলার আগে সেগুলো তাদের রিসোর্স আইডেন্টিফায়ারসহ লিখে রাখুন, কারণ এই বিন্দুর পরে সবকিছুই ওই তিনটির একটির সম্পর্কে বিবৃতি।

কাস্টমার গেটওয়ে আপনার এবং এর কনফিগারেশন আপনার কাছে দৃশ্যমান। AWS টার্গেট একটি ম্যানেজড রিসোর্স, আর ভুলটি হলো এটি ধরে নেওয়া: একটি VPN সংযোগ ভার্চুয়াল প্রাইভেট গেটওয়েতে বা সরাসরি ট্রানজিট গেটওয়েতে অ্যাটাচ হতে পারে, এবং কোনোটিই অন্যটিকে বোঝায় না। তৃতীয় প্রান্তবিন্দুটি মানুষ এড়িয়ে যায়, আর অ্যাপ্লিকেশন ডেটা নিয়ে প্রকৃত প্রশ্নের উত্তর দেয় কেবল সেটিই।

যাচাই 1: কোন গেটওয়ে আসলে টানেল শেষ করে

দুই ব্যবস্থাই সমর্থিত এবং Site-to-Site VPN আর্কিটেকচার নির্দেশিকা পাশাপাশি তাদের বর্ণনা করে, তাই এক বছরের পুরোনো হতে পারে এমন ডায়াগ্রামের বদলে API-কে জিজ্ঞেস করুন। একটি সংযোগের ওপর শুধু-পাঠযোগ্য কোয়েরি VPN টার্গেট ফিল্ডগুলো ফেরত দেয়:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

পার্থক্যসূচকটি TransitGatewayId, VpnGatewayId নয়। যে সংযোগে TransitGatewayId খালি সেটি একটি স্বতন্ত্র ভার্চুয়াল প্রাইভেট গেটওয়েতে শেষ হয়, আর যে সংযোগে ওই ফিল্ড সেট করা আছে সেটি শেষ হয় ট্রানজিট গেটওয়ে VPN অ্যাটাচমেন্টে, এবং সেক্ষেত্রে VpnGatewayId এখনও ভরা থাকতে পারে, কারণ এটি অ্যাটাচমেন্টের ব্যাকিং গেটওয়ে নির্দেশ করতে পারে। আগে TGW ফিল্ড পড়ুন, তারপর ফিল্ডের নামের বদলে অ্যাটাচমেন্ট তালিকা থেকে অ্যাটাচমেন্টের ধরন নিশ্চিত করুন, কারণ ওই ট্রানজিট গেটওয়ের একটি VPC অ্যাটাচমেন্ট VPN অ্যাটাচমেন্ট নয়। সংযুক্ত VPC-তে গন্তব্য ইনস্ট্যান্স খুঁজে পাওয়া কোন VPN অ্যাটাচমেন্ট প্যাকেটটি বহন করেছে সে সম্পর্কে কিছুই বলে না।

সেখানে থাকাকালীন টানেলগুলোও দেখুন। সংযোগটি অপ্রয়োজনীয়তার জন্য দুটি IPsec টানেল বহন করে, আর যে সংযোগের দ্বিতীয় টানেল কখনো ওঠেনি সেটি প্রাপ্যতার জন্য একটি প্রকৃত অনুসন্ধান, যদিও এটি এনক্রিপশন সীমানা সম্পর্কে কিছুই বদলায় না:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

যাচাই 2: অভ্যন্তরীণ প্যাকেট এখনও কী বহন করে

IPsec শেষ হলে AWS ডিক্যাপসুলেটেড প্যাকেটটি যে রুটের সঙ্গে মিলেছে সেই রুটে পাঠায়। সেই বিন্দু থেকে ট্রাফিক সাধারণ VPC ট্রাফিক, এবং VPN-এর সুরক্ষা শেষ হয়েছে। এটি সেবার কোনো ফাঁক নয়; সীমানার অর্থই এটাই, আর চেকলিস্টের বিষয়টি হলো এটি স্পষ্টভাবে বলা, "VPN এনক্রিপ্টেড" কথাটিকে "ডেটা এন্ড-টু-এন্ড এনক্রিপ্টেড"-এর জায়গায় দাঁড়াতে না দেওয়া।

এখন ভেতরে কী ছিল তা দেখুন। অভ্যন্তরীণ প্যাকেট যদি প্লেইনটেক্সট অ্যাপ্লিকেশন প্রোটোকল হয়, তবে অন্য কিছু এটি এনক্রিপ্ট না করা পর্যন্ত নিচের দিকে কিছুই গোপনীয়তা যোগ করে না। অভ্যন্তরীণ প্যাকেট যদি ইতিমধ্যে একটি TLS সেশন বহন করে, তবে বাইরের IPsec অপসারণ সেই সেশনের জন্য কিছুই বদলায় না: সেটি নিজের প্রান্তবিন্দু পর্যন্ত সুরক্ষিত থাকে, সেই প্রান্তবিন্দু যেখানেই হোক।

সাধারণ অতিরিক্ত সংশোধন হলো এই সিদ্ধান্তে আসা যে গেটওয়ের পেছনের সবকিছু উন্মুক্ত। তা নয়। সেবা পরিবহন, স্টোরেজ এনক্রিপশন এবং অ্যাপ্লিকেশন TLS আলাদা শর্তসহ আলাদা প্রক্রিয়া, আর প্রতিটিকে তার নিজস্ব শর্তে মূল্যায়ন করতে হয়, VPN-এর আকৃতি থেকে অনুমান করতে নয়। ACCEPT দেখানো একটি ফ্লো লগ এন্ট্রি প্রমাণ করে রাউটিং কাজ করেছে এবং গোপনীয়তা সম্পর্কে কিছুই বলে না, আর এই চেকলিস্ট ঠিক সেই ভুলটিই প্রতিরোধ করতে চায়।

যাচাই 3: গেটওয়ের পেছনে TLS শেষ করে কী

ঠিকানার নয়, লিসেনারের পিছু নিন। লোড ব্যালেন্সার বা প্রক্সি যদি TLS শেষ করে, আপনার ক্লায়েন্টের ধরে রাখা সংযোগ সেখানেই শেষ হয়, আর প্রক্সি ব্যাকএন্ডে দ্বিতীয় সংযোগ খোলে যা প্লেইনটেক্সট হতে পারে বা ভিন্ন ট্রাস্ট চেইনের TLS হতে পারে। একটি প্রাইভেট IP ঠিকানা আর মিলে যাওয়া রুট সেই দ্বিতীয় সংযোগ সম্পর্কে প্রমাণ নয়।

আপনার সত্যিই যত্নের প্রান্তবিন্দুটি VPC-র ভেতর থেকে পরীক্ষা করুন, অ্যাপ্লিকেশন যে নাম ব্যবহার করে সেই নামে, একবার রিজলভ করা কোনো IP দিয়ে নয়:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

অনুরোধ যে প্রতিটি হপ পেরোয় তার জন্য এটি পুনরাবৃত্তি করুন। উত্তর যদি ক্লায়েন্টমুখী নাম আর ব্যাকএন্ড নামের মধ্যে আলাদা হয়, তবে আপনি ঠিক সেই সেগমেন্টটি পেয়েছেন যা VPN কখনো ঢাকেনি, এবং সেটিই লিখে রাখার মতো অনুসন্ধান।

ফলাফল রায় হিসেবে নয়, সেগমেন্ট হিসেবে লিখুন

এই চেকলিস্টের ফল হলো প্রতিটি সেগমেন্টে একটি সারি করে একটি ছোট টেবিল: কাস্টমার গেটওয়ে থেকে AWS VPN টার্গেট, গেটওয়ে থেকে ওয়ার্কলোড, ওয়ার্কলোড থেকে ডেটা স্টোর, এবং মাঝে যেকোনো প্রক্সি হপ। প্রতিটি সারি বলে এটি কী সুরক্ষা দেয় এবং সেই সুরক্ষা কীসের ওপর নির্ভর করে। প্রক্রিয়া ও প্রান্তবিন্দু ছাড়া "এনক্রিপ্টেড" কোনো সারি নয়।

তারপর মূল প্রয়োজনটি যে ভাষায় চাওয়া হয়েছিল সেই ভাষাতেই তার উত্তর দিন। প্রয়োজন যদি হয় ওয়ার্কলোড এটি পাওয়ার আগ পর্যন্ত ডেটা গোপনীয় থাকে, তবে VPN কেবল প্রথম সেগমেন্টটিই পূরণ করে, আর বাকি সারিগুলোর জন্য অ্যাপ্লিকেশন পরিবহন, সেবা TLS বা স্টোরেজ এনক্রিপশন আলাদাভাবে কনফিগার ও যাচাই করতে হবে।

সংযোগ আইডেন্টিফায়ার, টানেলের অবস্থা এবং সার্টিফিকেট সাবজেক্ট রেকর্ডে রাখুন। ছয় মাস পর কেউ ডিজাইনে ফিরে এলে এই তিনটি নিদর্শন কয়েক মিনিটেই সীমানার প্রশ্নের উত্তর দেয়, ডায়াগ্রাম থেকে তর্ক আবার শুরু করার বদলে।