LAN سروس کو VPN گیٹ وے کے اپنے پتے پر شائع کریں
کلائنٹ سے ڈیوائس تک اور واپس فارورڈ شدہ پورٹ کا سراغ لگائیں: منزل کی ترجمانی کا دائرہ متعین کریں، پھر فیصلہ کریں کہ جوابات روٹ ہوتے ہیں یا ترجمہ۔
گیٹ وے کے اپنے ٹنل پتوں میں سے کسی ایک پر 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 تک گئی یا نہیں اور ٹنل کی طرف جواب واپس آیا یا نہیں۔ اصول بدلنے کے بعد نیا کنکشن استعمال کریں، کیونکہ موجودہ حالت اپنی پہلے کی میپنگ رکھتی ہے اور پرانے طریقے سے ناکام ہوتی رہے گی۔ پھر پوری گفتگو کی تصدیق کریں: ڈیوائس کا پتہ، فارورڈنگ اجازت اور جواب کا راستہ سب ایک ہی بہاؤ بیان کرتے ہیں۔