রাউটেড VPN ক্লায়েন্ট সার্ভারে পৌঁছায় কিন্তু LAN হোস্টে পৌঁছায় না

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

অনুরোধ নয়, উত্তর অনুসরণ করুন

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

ক্লায়েন্টে লক্ষণটি নীরব সময়সীমা: কোনো প্রত্যাখ্যান নেই, কোনো রিসেট নেই, শুধু কিছুই না। শেয়ার ব্রাউজ আটকে যায়, পিং কোনো উত্তর নেই বলে জানায়, আর সার্ভার লগ সুস্থ দেখায় কারণ সার্ভার তার কাজ করেছে।

হোস্টরা যেখানে তাকায় সেখানে ফিরতি রুট রাখুন

প্রতিটি LAN হোস্ট তার ডিফল্ট গেটওয়ের সঙ্গে পরামর্শ করে, তাই গেটওয়েই হলো সেই একমাত্র ডিভাইস যা জানা দরকার টানেল পুল কোথায় আছে। সেখানে একটি স্ট্যাটিক রুট যোগ করুন, তাহলে প্রতিটি হোস্ট স্পর্শ না করেই সঠিক পথ পেয়ে যাবে।

গেটওয়ে যদি DHCP অপশন হিসেবে নিজের ঠিকানা বিতরণ করে, তাহলে সেইভাবেই রুট বিতরণ করুন যাতে নতুন মেশিন স্বয়ংক্রিয়ভাবে এটি নেয়। নইলে রুটটি একটি কনফিগারেশন ফাইলে থাকে এবং পরের পুনর্নির্মাণে হারিয়ে যায়।

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

কেন সোর্স NAT সমস্যাটি সারিয়ে তোলে বলে মনে হয়

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

এই বিনিময়টি কখনো সঠিক, যেমন যখন কোনো বিক্রেতার অ্যাপ্লায়েন্সকে স্ট্যাটিক রুট দেওয়া যায় না। নিয়মটি বর্তমান পুলের চেয়ে প্রশস্ত করবেন না, কারণ /24-এর জন্য লেখা নিয়মটি সেদিনই মেলা বন্ধ করে দেয় যেদিন পুলটি /16-এ পুনঃসংখ্যায়িত হয়, আর প্রথম সংকেত হলো নতুন ক্লায়েন্টের একটি দল যারা সংযোগ করে কিন্তু কিছুতে পৌঁছায় না।

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

ক্লাউড পথের জন্য তিনটি সেটিং দরকার

VPC-তে একই ফাঁক অন্য আকারে ফিরে আসে, কারণ সাবনেটে ক্লায়েন্ট রেঞ্জের জন্য আদৌ কোনো রুট নেই। রুট টেবিলে টানেল পুলের জন্য একটি এন্ট্রি দরকার যা ইনস্ট্যান্সের নেটওয়ার্ক ইন্টারফেস লক্ষ্য করে, আর ইন্টারফেসে সোর্স ও ডেস্টিনেশন চেকিং বন্ধ করতে হবে যাতে প্ল্যাটফর্ম এমন প্যাকেট গ্রহণ করে যার সোর্স তার নিজের ঠিকানা নয়। সিকিউরিটি গ্রুপ ও নেটওয়ার্ক ACL-কেও দুই দিকেই পুলটি অনুমোদন করতে হবে।

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

এই ক্রমে পরীক্ষাগুলো চালান

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

সোর্স ও ডেস্টিনেশন চেক ইলাস্টিক নেটওয়ার্ক ইন্টারফেস নির্দেশিকায় নথিভুক্ত করা হয়েছে। এটি সেই ইন্টারফেসে সেট করুন যা সত্যিই টানেল ট্রাফিক বহন করে, একই ইনস্ট্যান্সে যুক্ত অসম্পর্কিত অ্যাডাপ্টারে নয়।