روٹر پر بندش سوئچ جو FORWARD، OUTPUT اور IPv6 کا احاطہ کرتا ہے
صرف FORWARD میں بندش سوئچ روٹر کو آزادانہ رسنے دیتا ہے، اور صرف IPv4 قواعد IPv6 کو کھلا چھوڑ دیتے ہیں۔ زنجیریں ترتیب دیں اور سرنگ بند حالت میں جانچیں۔
آپ روٹر میں لاگ ان کرتے ہیں، کسی فورم کی پوسٹ سے بندش سوئچ کے قواعد کا مجموعہ چسپاں کرتے ہیں، اور جس لمحے سرنگ گرتی ہے LAN براؤز کرنا چھوڑ دیتا ہے۔ دو دن بعد بھی روٹر عام WAN کے ذریعے اپنا متحرک DNS ریکارڈ اپ ڈیٹ کرتا رہتا ہے، اور مہمان لیپ ٹاپ اب بھی IPv6 سائٹوں تک پہنچتا ہے۔ دونوں رویے معمول کے ہیں، کیونکہ چسپاں کیے گئے قواعد ایک زنجیر اور ایک پتہ خاندان کا احاطہ کرتے تھے، اور ان میں سے کوئی بھی پورا روٹر نہیں ہے۔ پیکٹوں کے راستوں کو ترتیب سے دیکھنا بالکل وہی دکھاتا ہے جو چھوٹ گیا۔
روٹر سے شروع کریں، لیپ ٹاپ سے نہیں
روٹر کی سطح کی پالیسی ایک چھوٹے دفتر کے لیے پرکشش ہے کیونکہ اس کے پیچھے ہر آلہ وہی رویہ ورثے میں پاتا ہے اور کوئی بھی کلائنٹ پر سوئچ آن کرنا نہیں بھول سکتا۔ یہ آپ کو ہر فرم ویئر اپ ڈیٹ کے بعد جانچنے کے لیے ایک ہی جگہ بھی دیتی ہے۔ جو چیز یہ نہیں دیتی وہ خود روٹر کی ٹریفک یا دوسرے پتہ خاندان کی خودکار کوریج ہے، اور یہی وہ دو خلا ہیں جن کے پیچھے زیادہ تر ناکام تعیناتیاں ہیں۔
کچھ بھی بدلنے سے پہلے کاغذ پر تین حقائق لکھیں: WAN انٹرفیس کا نام، LAN پل کا نام، اور VPN کے آخری نقطے کا پتہ اور پورٹ۔ تینوں قواعد میں درکار ہوں گے، اور انٹرفیس کے ناموں کا اندازہ لگانا سب سے عام وجہ ہے کہ درست دکھنے والا قواعد کا مجموعہ کچھ نہیں کرتا۔
وہ تین راستے دیکھیں جن سے ایک پیکٹ گزر سکتا ہے
لیپ ٹاپ سے انٹرنیٹ کی طرف ٹریفک آگے بھیجی جاتی ہے، لہٰذا یہ FORWARD زنجیر سے گزرتی ہے۔ جو ٹریفک خود روٹر پیدا کرتا ہے، جیسے DNS کی منتقلی، NTP استفسارات، DDNS اپ ڈیٹس اور VPN کا کنٹرول چینل، وہ OUTPUT سے گزرتی ہے۔ روٹر کی طرف بھیجی گئی انتظامی ٹریفک INPUT سے آتی ہے۔
اس لیے صرف FORWARD میں بنایا گیا بندش سوئچ کلائنٹس کی حفاظت کرتا ہے اور کسی اور چیز کی نہیں۔ جدول دکھاتا ہے کہ ابتدائی منظر کا اخراج کیوں قابلِ پیش گوئی ہے، نہ کہ کوئی معمہ۔
| Packet path | Example | Chain that sees it |
|---|---|---|
| LAN client to WAN or tunnel | Browser request | FORWARD |
| Router-originated | DDNS update, NTP | OUTPUT |
| Addressed to the router | SSH from the LAN | INPUT |
زیادہ تر ڈیزائنوں میں آپ کو INPUT پر بندش سوئچ کی ضرورت نہیں، لیکن سرنگ بند ہونے کے دوران انتظامی رسائی کو کام کرتا رکھنا ضروری ہے۔ ورنہ VPN کی پہلی ناکامی پر آپ کنسول کیبل لے کر دفتر جائیں گے۔
قواعد ایسے ترتیب دیں کہ سرنگ پھر بھی اوپر آ سکے
کارآمد بندش سوئچ اجازتوں کی فہرست ہے جو رد پر ختم ہوتی ہے، اور ترتیب ہی اسے بندش سوئچ بناتی ہے، اینٹ نہیں۔ پہلے loopback، VPN کے آخری نقطے، قائم شدہ بہاؤں کے جوابات اور سرنگ کے انٹرفیس کی اجازت دیں؛ باقی کو آخر میں رد کریں۔
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECTاس مرحلے پر آخری نقطہ ایک پتہ ہونا چاہیے، میزبان کا نام نہیں۔ جیسے ہی حتمی رد DNS کو روکتا ہے، وہ قاعدہ جو فراہم کنندہ کے میزبان کا نام لیتا ہے مزید حل نہیں ہو سکتا، اور سرنگ دوبارہ شروع ہونے کے بعد کبھی دوبارہ نہیں اٹھتی. اگر فراہم کنندہ آخری نقطے بدلتا ہے تو پالیسی کے اطلاق سے پہلے نام حل کریں اور اس قاعدے کو اسی اسکرپٹ سے تازہ کریں۔
کلائنٹ ٹریفک کے لیے اسی شکل کو FORWARD میں دہرائیں، اور رد کے اوپر ایک واضح انتظامی قاعدہ رکھیں۔ اس انتظامی قاعدے کو تنگ مگر قابلِ رسائی رکھیں، اور پہلا SSH سیشن بند کرنے سے پہلے دوسرا سیشن کھول کر اس کی تصدیق کریں۔ بندش سوئچ کی تبدیلی کے دوران خود کو باہر بند کرنا اتنا عام ہے کہ اس کی منصوبہ بندی کی جائے۔ WireGuard چلانے والے روٹر پر ہم منصب کے allowed-ips طے کرتے ہیں کہ کیا سرنگ میں داخل ہوتا ہے، جبکہ یہ قواعد طے کرتے ہیں کہ اس کے بغیر کیا باہر جا سکتا ہے۔
IPv6 کو اپنا دروازہ چاہیے
اوپر سب کچھ IPv4 ہے۔ اگر آپ کے LAN میں IPv6 کام کر رہا ہے اور سرنگ صرف IPv4 لے جاتی ہے، تو ہر احاطہ شدہ آلے کے پاس انٹرنیٹ کا براہ راست راستہ اب بھی ہے جو آپ کے نئے قواعد کبھی نہیں دیکھتے۔ دو اسٹیک والا لیپ ٹاپ اسے بخوشی ترجیح دے گا، اور بندش سوئچ صرف اس شخص کو خراب لگے گا جو IPv4 سے جانچ رہا ہو۔
ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPTیہاں بھی ترتیب اہم ہے: loopback کی اجازت WAN کے رد سے پہلے آنی چاہیے، ورنہ روٹر پر مقامی خدمات عجیب طریقوں سے ناکام ہونے لگتی ہیں۔ اگر نیٹ ورک IPv6 بالکل استعمال نہیں کرتا تو اسے WAN اور LAN پر بند کرنا آسان ہے اور بھولنے کے لیے کچھ نہیں بچتا۔
کچھ VPN کلائنٹ صرف IPv4 کے لیے ڈیفالٹ راستہ نصب کرتے ہیں اور موجودہ IPv6 ڈیفالٹ راستہ اچھوتا چھوڑ دیتے ہیں۔ سرنگ جڑنے کے بعد روٹنگ جدول دیکھیں، بجائے یہ فرض کرنے کے کہ کلائنٹ نے نمٹا لیا۔
سرنگ بند حالت میں یہ ثابت کریں
سرنگ کو روٹر سے روکیں اور تین جگہوں سے اس ترتیب سے جانچیں:
# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | headراستے کی تلاش بتاتی ہے کہ پیکٹ کہاں جائے گا، اور کاؤنٹر بتاتے ہیں کہ آپ کے قواعد کبھی ملے یا نہیں۔ ناکام جانچ کے بعد صفر پیکٹ والا قاعدہ کچھ نہیں بچاتا، اور عام وجہ انٹرفیس کا ایسا نام ہے جو آپ کے لکھے ہوئے سے مختلف ہو۔ روٹر کی پیدا کردہ ٹریفک کو واضح طور پر جانچیں، کیونکہ LAN کی طرف سے جانچ OUTPUT کو نہیں چلا سکتی۔
ناکامی کا انداز اس سے پہلے طے کریں کہ اس کی ضرورت پڑے۔ fail-closed کلائنٹس کو آف لائن رکھتا ہے جب تک سرنگ واپس نہ آئے؛ fail-open عام WAN رسائی بحال کرتا ہے اور اس ٹریفک کا مقصد ضائع کر دیتا ہے جس کی آپ کو فکر تھی۔ زیادہ میٹرک والا VPN پول کی طرف blackhole راستہ fail-closed ڈیزائنوں کے لیے ایک مفید دوسری تہہ ہے، کیونکہ یہ سرنگ کا راستہ غائب ہونے پر زندہ رہتا ہے، بجائے ڈیفالٹ پر گرنے کے۔
ترتیب کو صرف اسی وقت قبول کریں جب LAN کا کلائنٹ، روٹر کی پیدا کردہ درخواست اور IPv6 درخواست سب سرنگ بند حالت میں ناکام ہوں، اور سرنگ اوپر آنے پر تینوں دوبارہ کام کریں۔