EC2 কেন আপনার AWS Client VPN ল্যাপটপে পৌঁছাতে পারে না
Client VPN IPv4 ক্লায়েন্ট উৎসগুলোকে endpoint-এর ইন্টারফেসে রূপান্তর করে। তাই উত্তরটি কাজ করে, কিন্তু EC2 থেকে নতুন সংযোগ কাজ করে না।
AWS Client VPN দিয়ে সংযুক্ত ল্যাপটপ কোনো সমস্যা ছাড়াই EC2-তে চলা একটি অ্যাপ্লিকেশনে পৌঁছায়। এরপর আপনি উল্টোটা চেষ্টা করেন — EC2 থেকে ক্লায়েন্টকে দেওয়া ঠিকানায় — এবং সংযোগটি আটকে যায় বা প্রত্যাখ্যাত হয়। এই অসমতা খুব কমই কোনো অনুপস্থিত সিকিউরিটি গ্রুপ নিয়ম। VPC সাবনেটের সঙ্গে যুক্ত Client VPN endpoint-এ AWS IPv4 ক্লায়েন্ট উৎসগুলোকে endpoint-এর নেটওয়ার্ক ইন্টারফেসে রূপান্তর করে, তাই আপনার ল্যাপটপের প্রতিনিধিত্বকারী কোনো ইনবাউন্ড VPC ঠিকানা থাকে না।
ক্যাপচার যা দেখায় তা দিয়ে শুরু করুন
ক্লায়েন্ট সংযুক্ত হওয়ার সময় EC2 হোস্টে ক্যাপচার নিন এবং অ্যাপ্লিকেশনটি আসলে যে সোর্স ঠিকানা দেখে তা পড়ুন। যদি তা ক্লায়েন্ট পুলের কোনো ঠিকানা না হয়ে VPC-পাশের endpoint ইন্টারফেস হয়, তবে একটি নিয়মও বদলানোর আগেই রূপান্তর নিশ্চিত হয়েছে।
ক্লায়েন্ট পুল একটি বরাদ্দ পরিসর, রিটার্ন রুটযুক্ত সাবনেট নয়। এই পার্থক্যেই এসব তদন্তের বেশিরভাগ ভুল পথে যায়।
যে রূপান্তর অসমতাটি ব্যাখ্যা করে
তিনটি ফ্লো একে অন্যের সঙ্গে গুলিয়ে ফেলা হয়, এবং তাদের মধ্যে কেবল একটি-ই মানুষ পরীক্ষা করে।
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN কম্পোনেন্টের বিবরণ স্পষ্ট করে বলে যে IPv4 ক্লায়েন্ট উৎসগুলো endpoint ইন্টারফেসে রূপান্তরিত হয়, আর এটাই দেখাতে যথেষ্ট কেন মাঝের সারির মেলানোর মতো কিছু নেই।
নতুন সংযোগের জন্য দরকার একটি রুট, একটি অ্যাড্রেস রিজলিউশন ধাপ এবং একটি অনুমোদন সিদ্ধান্ত। অন্যের সেশনের রূপান্তর অবস্থা এই তিনটির কোনোটিই দেয় না।
কেন একটি উত্তর নতুন সংযোগ নয়
TCP উত্তর বিদ্যমান এন্ট্রির সঙ্গে মিলিয়ে দেখা হয়, তাই কোনো ইনবাউন্ড নিয়ম ছাড়াই ফেরার পথ কাজ করে। EC2 হোস্ট থেকে আসা নতুন SYN-এর মেলানোর মতো এন্ট্রি নেই, তাই এটি এমন গন্তব্যের দিকে সাধারণ আউটবাউন্ড প্রচেষ্টায় পরিণত হয় যা VPC জানে না কীভাবে পৌঁছাতে হয়।
এজন্যই এটিকে কেবল এক দিকে যাওয়া ট্রাফিক হিসেবে বর্ণনা করা বিভ্রান্তিকর। এই সেশনগুলোতে ফেরত ট্রাফিক নিরন্তর প্রবাহিত হয়। পথহীন অংশটি হলো সূচনা।
যে সেশন কাজ করার কথা তা এখনও কী নষ্ট করে
সিকিউরিটি গ্রুপ, নেটওয়ার্ক ACL এবং ল্যাপটপের নিজের ফায়ারওয়াল — যেসব সংযোগ সফল হওয়ার কথা তাদের জন্য সবই গুরুত্বপূর্ণ। ব্যর্থ ping সবচেয়ে কম বলে, কারণ ICMP নীতি প্রায়ই আপনার প্রাসঙ্গিক TCP নীতির থেকে আলাদা।
এই নিয়মগুলো রূপান্তরিত সোর্সের ভিত্তিতে লিখুন, ক্লায়েন্ট ঠিকানার ভিত্তিতে নয়। যে ঠিকানাটি কখনও নেটওয়ার্কে দেখা যায় না তার সঙ্গে বাঁধা নিয়মই এই ডিজাইনে সবচেয়ে সাধারণ নিজের করা ক্ষতি।
কখন VPC সত্যিই কথোপকথন শুরু করবে
কোনো সার্ভিসকে যদি ওয়ার্কস্টেশনকে জানাতে হয়, দিকটি উল্টে দিন এবং ক্লায়েন্টকে একটি স্থায়ী আউটবাউন্ড চ্যানেল ধরে রাখতে দিন যার উত্তর সার্ভিস দেয়। যদি সম্পূর্ণ দূরবর্তী নেটওয়ার্ক VPC থেকে পৌঁছানোর মতো হতে হয়, Client VPN ইতিমধ্যে তা করে ধরে নেওয়ার বদলে এমন আর্কিটেকচার বেছে নিন যা তার প্রিফিক্স ও অ্যাক্সেস নীতি প্রকাশ করে। ক্লায়েন্ট-থেকে-ক্লায়েন্ট অ্যাক্সেস তৃতীয়, আরও সংকীর্ণ কেস, যার নিজস্ব রুট ও অনুমোদন অবজেক্ট আছে। এর কোনোটিই বিদ্যমান endpoint-এ শুধু একটি চেকবক্স নয়।
IPv4 ব্যাখ্যার পরিধিও সৎ রাখুন। বর্তমান AWS ডকুমেন্টেশন IPv6-কে আলাদা করে, যেখানে এই রূপান্তর প্রযোজ্য নয়, এবং অন্য সংযুক্তি মডেলগুলোও যা ভিন্নভাবে রুট করে।
তিনটি লেবেলযুক্ত ধাপে পরীক্ষা করুন: ক্লায়েন্ট একটি অনুমোদিত সেশন খোলে, VPC সার্ভিস সেই সেশনের উত্তর দেয়, এবং একটি VPC হোস্ট ক্লায়েন্টের দিকে নতুন সেশন খোলে। প্রথম দুটি সফল হয়ে তৃতীয়টি ব্যর্থ হওয়াই এই ডিজাইনের প্রত্যাশিত রূপ, ফায়ারওয়াল নিয়ম দিয়ে তাড়া করার মতো ত্রুটি নয়।