VPN নেমস্পেসের ভেতরের অ্যাপটি LAN থেকে পৌঁছানো যায় না
একটি নেটওয়ার্ক নেমস্পেস একটি প্রোগ্রামকে তার নিজের টানেল ও নিজের লুপব্যাক দেয়। হোস্টের বদলে শুধু তার পোর্টটি socat হপ বা veth জোড়া দিয়ে প্রকাশ করুন।
আপনার সার্ভিস মেশিনে কাজ করছে, টানেল চালু আছে, তবু আপনার ডেস্কের ব্রাউজার এখনও উত্তর না পেয়ে সময় শেষ করে ফেলে। স্বাভাবিক অর্থে কিছুই ভাঙেনি: অ্যাপ্লিকেশনটি একটি নেটওয়ার্ক নেমস্পেসের ভেতরে শুনছে, আর সেই স্ট্যাকটি LAN-এর কাছে অদৃশ্য। এর লুপব্যাক নেমস্পেসেরই, তাই অন্য মেশিনের ক্লায়েন্টের কাছে এমন কোনো ঠিকানা নেই যা পোর্টে পৌঁছায়। একটি ইচ্ছাকৃত হপ, বা একটি veth জোড়া, হোস্টের বাকি অংশ না সরিয়েই এটি ঠিক করে।
কেন LAN ঠিকানায় কিছু উত্তর দেয় না
নেমস্পেস হলো একটি সম্পূর্ণ নেটওয়ার্ক স্ট্যাক: ইন্টারফেস, রুট, ফায়ারওয়াল নিয়ম আর একটি ব্যক্তিগত লুপব্যাক। ip netns exec-এর মাধ্যমে চালু করা প্রক্রিয়া কেবল সেই স্ট্যাকটাই দেখে, তাই যে ঠিকানায় এটি বাঁধে তা কেবল নেমস্পেসের ভেতরেই সমাধান হয়। হোস্টের নিজের 127.0.0.1 সম্পূর্ণ আলাদা একটি লুপব্যাক।
তাই হোস্টে curl ব্যর্থ হয়, অথচ নেমস্পেসের ভেতরে একই কমান্ড সফল হয়। অ্যাপ্লিকেশনটি সুস্থ আছে; ঠিকানাটি কেবল হোস্টের স্ট্যাকে নেই।
socat হপ দিয়ে একটি পোর্ট প্রকাশ করুন
socat ব্যবহারকারী-স্পেসে দুই স্ট্যাককে সেতু করে, আর একটি TCP পোর্ট পার হতে হলে এটাই যথেষ্ট। হোস্টের দিকটি LAN-এ শোনে এবং প্রতিটি গৃহীত সংযোগের জন্য নেমস্পেসের ভেতরে একটি দ্বিতীয় socat চালু করে, যা অ্যাপের লুপব্যাকে সংযোগ করে। ভেতরের প্রক্রিয়াটি ঠিক স্থানীয় ক্লায়েন্টের মতোই অ্যাপ্লিকেশনে পৌঁছায়। নেমস্পেসের রাউটিংয়ে কিছুই বদলায় না, তাই অ্যাপটি টানেলকেই তার একমাত্র নির্গমন পথ হিসেবে ব্যবহার করে চলে।
socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork
বাইরের প্রক্রিয়াটির root বা নেমস্পেসে ঢোকার সক্ষমতা দরকার। VPN পড়ে গেলে অ্যাপটি তার পথ হারায় এবং প্রকাশিত পোর্টটি বন্ধ হয়ে ব্যর্থ হয়, আর জেল থেকে আপনি ঠিক এই আচরণই চান।
একাধিক পোর্ট পার হলে veth জোড়া ব্যবহার করুন
কয়েকটি পোর্ট বা প্রোটোকল পার হতে হলে, বা অন্য হোস্টগুলোকে সংযোগ শুরু করতে হলে veth জোড়াই সঠিক উত্তর। এক প্রান্ত হোস্টে থাকে, অন্য প্রান্ত নেমস্পেসে যায়, আর একটি ছোট /30 দুই পক্ষকেই স্থির ঠিকানা দেয়। তারপর একটি হোস্ট রুট জোড়ার ওপর দিয়ে নেমস্পেসের ঠিকানা পাঠায়।
ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up
জেল ভাঙার ইচ্ছা না থাকলে হোস্টের মধ্য দিয়ে কোনো ডিফল্ট রুট যোগ করবেন না। টানেলই নির্গমন পথ থাকা উচিত, তাই জোড়ার ওপর দিয়ে কেবল প্রকাশিত সার্ভিস ঠিকানাই পৌঁছানো যায়। নেমস্পেসকে তার নিজের রিজলভার ফাইলও দিন, কারণ ip netns exec /etc/netns/vpn/resolv.conf পড়ে, আর এটি ছাড়া জেলের ভেতরে নাম সমাধান ফাঁকা থাকে।
হোস্ট নয়, অন্য মেশিন থেকে পরীক্ষা করুন
পরীক্ষাটি দ্বিতীয় মেশিন থেকে চালান, কারণ হোস্ট স্থানীয় শ্রবণকারীর কাছে এমন পথে পৌঁছাতে পারে যা LAN সম্পর্কে কিছুই বলে না। প্রথমে দেখুন অ্যাপটি নেমস্পেসের ভেতরে আসলে কীসে বাঁধা হয়েছে, তারপর বাইরে থেকে প্রকাশিত ঠিকানায় সংযোগ করুন। সেখানে প্রতিটি ঠিকানায় বাঁধলেও জেল প্রশস্ত হয় না, কারণ wildcard এখনও নেমস্পেসেরই এবং LAN তা দেখতে পায় না।
ip netns exec vpn ss -lntp
হোস্টের সংযোগ কাজ করলে আর LAN-এর সংযোগ না করলে, অনুপস্থিত অংশটি হলো হপ বা রুট, বাঁধার ঠিকানা নয়। চলমান tun ডিভাইস সরিয়ে আনার বদলে নেমস্পেসের ভেতরেই OpenVPN চালু করুন, কারণ ইন্টারফেস সরালে তা বন্ধ হয়ে যায় এবং এমন রুট মুছে যেতে পারে যা পরে বাইরে থেকে সারানো যাবে না। পুনরুদ্ধারের কমান্ডগুলো জেলের ভেতরে নয়, কনসোলে রাখুন।