VPN গেটওয়ের নিজস্ব ঠিকানায় LAN সেবা প্রকাশ করুন

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

ক্লায়েন্টের দৃষ্টিভঙ্গি থেকে শুরু করুন

এই উদাহরণের ক্লায়েন্ট VPN পুল 10.62.0.0/24-এ থাকে এবং 8080 পোর্টে 10.62.0.1-এ সংযোগ করে। ওই ঠিকানাটি গেটওয়ের নিজের, তাই প্যাকেটটি অন্য কোনো পিয়ারের কাছে নয়, গেটওয়ের কার্নেলে পৌঁছায়। গেটওয়ের পেছনে LAN হলো 172.21.4.0/24। গেটওয়ে 172.21.4.10 ধরে রাখে, আর যে ডিভাইসটি আসলে HTTP পরিবেশন করে সেটি 172.21.4.40।

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

গন্তব্য অনুবাদ সচেতনভাবে সীমিত করুন

সংকীর্ণ সংস্করণটি একটি পোর্ট উপস্থাপন করে এবং কেবল গন্তব্য পুনঃলিখন করে। প্যাকেটটি তার প্রোটোকল ও উৎস ধরে রাখে, আর এটাই বাকি পথটিকে আকর্ষণীয় করে তোলে।

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

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

ফরওয়ার্ডিং সীমানা একমত হতে দিন

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

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

ডিভাইসটিকে কোনোভাবে উত্তর দিতে হবে

অনুবাদের পরে ডিভাইসটি 10.62.0.0/24-এ একটি উৎস দেখে। তার উত্তর তার ডিফল্ট গেটওয়েতে যায়, যেটি LAN রাউটার, VPN গেটওয়ে নয়, যদি না কিছু তাকে অন্যভাবে বলে। দুটি ব্যবস্থা এটি ঠিক করে, এবং তারা সমতুল্য নয়। ডিভাইসে বা LAN রাউটারে একটি রুট 10.62.0.0/24-কে 172.21.4.10-এ পাঠায় এবং ক্লায়েন্ট উৎস সংরক্ষণ করে। সীমিত উৎস অনুবাদ এর বদলে ক্লায়েন্টকে গেটওয়ের LAN ঠিকানার পিছনে লুকায়।

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

সেবাটির কী দরকার তা দেখে বেছে নিন। প্রতি-ক্লায়েন্ট নীতি ও অর্থবহ লগ রুট করা রূপটি চায়; যে ডিভাইসকে রুট দেওয়া যায় না, বা যে সেবাকে অবশ্যই একটি LAN ঠিকানা দেখতে হয়, সেটি অনূদিত রূপের দিকে ইশারা করে। একটি উত্তর কাজ করাতে গ্লোবাল masquerade নিয়মের দিকে হাত বাড়াবেন না। এটি প্রতিটি ক্লায়েন্টকে প্রতিটি গন্তব্য থেকে লুকায় এবং উৎস ঠিকানার উপর নির্ভর করা নীতিগুলো নিঃশব্দে ভেঙে দেয়।

গেটওয়ে থেকেই পরীক্ষা করবেন না

গেটওয়েতে 10.62.0.1-এর দিকে তৈরি একটি অনুরোধ OUTPUT চেইন দিয়ে বেরোয়, আগত PREROUTING দিয়ে নয়। এর ব্যর্থতা বা সাফল্য ক্লায়েন্টমুখী নিয়ম সম্পর্কে কিছুই বলে না, আর এভাবেই মানুষ মনে করে একটি কাজ করা নিয়ম নষ্ট।

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

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