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

প্রতিটি যাচাই আপনি যে প্রকৃত এন্ডপয়েন্ট, ক্লায়েন্ট ও ঠিকানা-পরিবার ব্যবহারের পরিকল্পনা করছেন তার বিরুদ্ধে চালান, শ্রেণির বিরুদ্ধে নয়। ম্যানেজড VPN পণ্য তারা যেসব OpenVPN ও IPsec বিল্ডিং ব্লকের মতো দেখায় তার থেকে আলাদা।

প্রথমে, কে সংযোগ খোলে

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

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

দ্বিতীয়ত, AWS কী প্রমাণীকরণ করে

Client VPN-এ AWS কনফিগার করা ক্লায়েন্ট বা ব্যবহারকারী পরিচয় প্রমাণীকরণ করে: সার্টিফিকেট, ডিরেক্টরি বা ফেডারেটেড পরিচয়, সেটআপ অনুসারে। Site-to-Site VPN-এ AWS গেটওয়ে পিয়ার পরিচয় প্রমাণীকরণ করে। এই পার্থক্য সৌন্দর্যের নয়। একটি মডেল ব্যবহারকারী যোগ করে ও তাদের ক্রেডেনশিয়াল বাতিল করে স্কেল করে; অন্যটি একটি গেটওয়ের পিছনে যা বসে আছে তা বিশ্বাস করে স্কেল করে।

গেটওয়ে প্রমাণীকরণ তার পিছনের প্রতিটি কর্মচারী বা অ্যাপ্লিকেশন প্রমাণীকরণ করে না, তাই টানেল নিজেই বিশ্বস্ত হলেও অ্যাপ্লিকেশন পরিচয় ও রিসোর্স-স্তরের অ্যাক্সেস চালু রাখুন। যে শাখার রাউটার বৈধ পিয়ার পরিচয় ধরে রাখে, তাকে স্বয়ংক্রিয়ভাবে সেই ভবনের প্রতিটি ডেস্ক অনুমোদিত বলে পড়া উচিত নয়।

তৃতীয়ত, সংযোগ কীভাবে যুক্ত হয়

Client VPN VPC সাবনেট অ্যাসোসিয়েশন বা সমর্থিত সরাসরি Transit Gateway সংযুক্তির মাধ্যমে যুক্ত হয়। Site-to-Site VPN একটি AWS VPN টার্গেটে যুক্ত হয়, সাধারণত একটি ভার্চুয়াল প্রাইভেট গেটওয়ে বা Transit Gateway। Client VPN আর্কিটেকচার গাইড Transit Gateway বিকল্পটি নথিভুক্ত করে, এবং এর অস্তিত্ব একটি ল্যাপটপ সেশনকে শাখা গেটওয়ে বানায় না বা উপরে বর্ণিত ক্লায়েন্ট প্রমাণীকরণ ও অনুমোদন সরায় না।

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

চতুর্থত, এর সঙ্গে কোন রাউটিং ও নীতি আসে

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

কোন দিকেই শ্রেণি থেকে অসমর্থিত আচরণ অনুমান করবেন না। দূরবর্তী-অ্যাক্সেস VPN সর্বজনীনভাবে ফেরত ট্রাফিক বহনে বা গেটওয়ে ব্যবস্থা সমর্থনে অক্ষম নয়, এবং IPsec স্বয়ংক্রিয়ভাবে NAT দ্বারা অবরুদ্ধ হয় না — AWS NAT ট্রাভার্সাল ও কাস্টমার-গেটওয়ে প্রয়োজনীয়তা নথিভুক্ত করে, এবং সমর্থিত গেটওয়ে কনফিগারেশনই আসল সীমাবদ্ধতা। ক্লায়েন্টের দিকে শুরু হওয়া সংযোগ দাবি করার বা একটি সেশনের পিছনে LAN ফরওয়ার্ড করার আগে আপনার এন্ডপয়েন্টের নিষেধাজ্ঞাগুলো যাচাই করুন। একই সতর্কতা ঠিকানা-পরিবারের ক্ষেত্রেও: IPv4-এ কাজ করা এন্ডপয়েন্ট IPv6 পথ বোঝায় না, তাই আপনার ক্লায়েন্ট বা গেটওয়ে আসলে যে পরিবার নিয়ে আলোচনা করবে তা নিশ্চিত করুন।

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

যেখানে দুই ডিজাইন মেলে

সেবাগুলো পরস্পর-বহিষ্কার নয়, এবং সাধারণ উৎপাদন কাঠামো দুটোই ব্যবহার করে: কর্মীরা Client VPN-এ, শাখা নেটওয়ার্ক Site-to-Site-এ, যে গন্তব্যগুলোকে কথা বলতে হবে তাদের মধ্যে স্পষ্ট রুট ও অ্যাক্সেস নীতি নিয়ে। সারণিটি চারটি যাচাইয়ের সারসংক্ষেপ, সেগুলো চালানোর বিকল্প নয়।

QuestionAWS Client VPNAWS Site-to-Site VPN
Who establishes it?A client on a remote deviceA customer gateway device or appliance
What is authenticated?The client or user identityThe gateway peer identity
How does it attach?VPC subnet association or Transit GatewayVirtual private gateway or Transit Gateway
What carries the path?An OpenVPN-based client tunnelIPsec tunnels to AWS endpoints

একটি জিনিস কোন পণ্যই প্রতিস্থাপন করে না: এমন অ্যাপ্লিকেশনে TLS যার এনক্রিপশন প্রয়োজনীয়তা VPN এন্ডপয়েন্টের বাইরেও বিস্তৃত। যদি আপনার সম্মতি-পরিধি অ্যাপ্লিকেশনেই শেষ হয়, টানেল পরিবহন আর সার্টিফিকেটই তখনো নিয়ন্ত্রণ।

ডিজাইন পর্যালোচনার আগে চারটি উত্তর লিখে রাখুন, প্রতিটি এক লাইনে। যখন দুটি পরস্পরবিরোধী হয় — ধরুন, ব্যবহারকারী-প্রমাণীকৃত ক্লায়েন্ট ডিজাইনের সঙ্গে শাখা-মাপের রাউটিং প্রয়োজন — সেই বিরোধই হলো প্রাপ্তি, এবং কাটওভারের সময়ের চেয়ে এখনই তা দেখা সস্তা।

সম্পর্কিত নিবন্ধ