একটি AWS Client VPN সেশনের পেছনে LAN: কী ফরোয়ার্ড হয়

ল্যাপটপ AWS Client VPN এন্ডপয়েন্টে সংযোগ করে, প্রাইভেট সাবনেটে পৌঁছায়, এবং সবকিছু সুস্থ দেখায়। একই LAN-এর ডেস্কটপ কিছুই পৌঁছাতে পারে না, যদিও Linux হোস্টেও একটি ব্রিজ ইন্টারফেস আছে এবং দুটি মেশিন একই তারে আছে। টানেলে কিছুই ভুল কনফিগার করা নেই; যে অংশটি অনুপস্থিত তা হলো রাউটিং, এবং ব্রিজটি একটি বিভ্রান্তিকর সূত্র।

একটি Client VPN সেশনকে LAN-এ সম্প্রসারণ করা হলো গেটওয়ে ভূমিকা। এটি কোনো ম্যানেজড সার্ভিসে টানা Ethernet সেগমেন্ট নয়।

হোস্ট কাজ করে, LAN করে না

Linux বক্সের টানেল ইন্টারফেসের ঠিকানা Client VPN ক্লায়েন্ট CIDR-এর ভিতরে, এবং এন্ডপয়েন্ট VPC রেঞ্জগুলোর জন্য রুট পুশ করেছে। ওই বক্সে করা অনুরোধ হলো স্থানীয়ভাবে উৎপন্ন ট্রাফিক: এটি একটি রুট বেছে নেয়, টানেল দিয়ে বের হয় এবং উত্তর পায়। সেই পথ কখনো ফরোয়ার্ডিং কোড, LAN ইন্টারফেস বা ট্রানজিট নিয়ন্ত্রণকারী কোনো ফায়ারওয়াল নিয়ম স্পর্শ করে না।

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

প্রতিটি ক্লায়েন্ট গেটওয়ে হতে পারে না

AWS জানায় যে তাদের Client VPN ডেস্কটপ অ্যাপ্লিকেশন IP ফরোয়ার্ডিং সমর্থন করে না, এবং অন্য ক্লায়েন্টরা করতে পারে। এই নিষেধাজ্ঞা কোনো কমান্ড টাইপ করার আগেই আর্কিটেকচার নির্ধারণ করে। যদি একমাত্র উপলব্ধ ক্লায়েন্ট অফিসিয়াল ডেস্কটপ অ্যাপ হয়, তবে LAN-এর জন্য ফরোয়ার্ড করা Linux গেটওয়ে এমন কনফিগারেশন নয় যা আপনি শেষ করতে পারবেন, এবং কোনো পরিমাণ মাস্করেডিং তা বদলাবে না।

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

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

LAN-কে টানেলে যুক্ত করুন এবং অনুবাদ করুন

সমর্থিত ক্লায়েন্ট থাকলে বাকিটা সাধারণ গেটওয়ে কাজ। LAN ডিভাইসগুলোর VPC রেঞ্জের জন্য Linux হোস্টের দিকে নির্দেশ করা রুট দরকার, এবং হোস্টের ফরোয়ার্ডিং সক্রিয় থাকা দরকার। যদি চান VPC ট্রাফিকটিকে সংযুক্ত ক্লায়েন্ট হিসেবে দেখুক, কোনো এলোমেলো LAN ঠিকানা হিসেবে নয়, তবে বেরোনোর পথে উৎস অনুবাদ করুন।

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

নিয়মটিকে উপরের মতো টানেল ইন্টারফেস এবং VPC রেঞ্জে সীমাবদ্ধ করুন, হোস্ট যা ফরোয়ার্ড করে সবকিছু মাস্করেড না করে। সংকীর্ণ নিয়ম নিয়ে যুক্তি করা সহজ, এবং এটি এমন ট্রাফিক নীরবে বদলায় না যা তার মূল উৎস ঠিকানা রাখার কথা ছিল।

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

উত্তরেরও একটি পথ দরকার

অনুরোধ VPC-তে পৌঁছানোর পর উত্তরকে একই অনুবাদ অবস্থার মধ্য দিয়ে ফিরে আসতে হবে এবং গেটওয়েতে LAN রুট খুঁজে পেতে হবে। এই অংশটি সাধারণত কাজ করে যখন মাস্করেড নিয়ম উপস্থিত থাকে, কারণ ম্যাপিংটি যে হোস্টে এটি করেছে সেখানেই থাকে। এটি ভাঙে যখন VPC পাশে এমন রুট থাকে যা উত্তর অন্যত্র পাঠায়, এবং সেজন্যই ক্লায়েন্ট CIDR রুট এবং এন্ডপয়েন্টে সাবনেট সংযুক্তি দুটোই গুরুত্বপূর্ণ।

শুধু ping নয়, কাউন্টার দেখুন। শূন্য প্যাকেটের মাস্করেড নিয়ম আপনাকে বলে অনুরোধ কখনো টানেল ইন্টারফেসে পৌঁছায়নি, যা LAN রুট বা ক্লায়েন্টের নিজের রাউটিং টেবিলের দিকে ইঙ্গিত করে। প্যাকেট আছে কিন্তু উত্তর নেই এমন নিয়ম VPC পাশ, অনুমোদন নিয়ম, বা এমন সিকিউরিটি গ্রুপের দিকে ইঙ্গিত করে যা অনূদিত উৎস গ্রহণ করে না। কিছু বদলানোর আগে দুই দিকই পড়ুন, কারণ কেবল এক দিকে বাড়তে থাকা গণনা ধীর পথ নয়, একমুখী পথ।

মনে রাখবেন এন্ডপয়েন্ট একটি ম্যানেজড সার্ভিস। সম্পাদনা করার জন্য কোনো সার্ভার কনফিগারেশন ফাইল নেই এবং যোগ করার কোনো client-config নির্দেশনা নেই, তাই কাস্টম ক্লায়েন্ট সাবনেট রুটসহ স্ব-পরিচালিত OpenVPN সার্ভারের জন্য লেখা নির্দেশনা প্রযোজ্য নয়। AWS-এ লিভারগুলো হলো সাবনেট সংযুক্তি, অনুমোদন নিয়ম এবং VPC রাউট টেবিল।

শেয়ার করা পরিচয় হলো সেই অংশ যার উত্তর নীতি দিতে হবে

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

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

যদি প্রয়োজন সত্যিই একটি সম্পূর্ণ সাইটকে VPC-তে সংযুক্ত করা হয়, তবে রিমোট-অ্যাক্সেস ক্লায়েন্ট সম্প্রসারণের আগে একটি সমর্থিত সাইট-টু-সাইট ডিজাইন তুলনা করুন। অর্থার্থ ভিন্ন, এবং VPC-কে LAN-এ সংযোগ শুরু করতে হলে NAT করা ক্লায়েন্ট সেশন সাইট লিংকের দুর্বল বিকল্প।

ক্লায়েন্ট, রুট, অনুবাদ এবং পরিচয়ের গল্প এই ক্রমে ঠিক করুন। প্রতিটি পরেরটিকে সীমাবদ্ধ করে, এবং ক্রমটি ব্যাখ্যা করে কেন হোস্ট কাজ করে অথচ LAN করে না।