کل سوئچ صرف IPv4 کو بلاک کرتا ہے: IPv6 پھر بھی کیوں باہر جاتا ہے

ٹنل گرتی ہے، کل سوئچ بتاتا ہے کہ اس نے کام کیا، اور ڈاؤن لوڈ جاری رہتا ہے۔ IPv4 قواعد میں کچھ بھی ٹوٹا نہیں۔ ایپ صرف ایسے راستے پر چلی گئی جس کے لیے وہ قواعد کبھی نہیں لکھے گئے۔

ڈوئل اسٹیک ڈیوائسز کے باہر جانے کے دو آزاد راستے ہوتے ہیں۔ ان میں سے ایک پر بلاک آدھا بلاک ہے۔

دو قواعد کے مجموعے، دو ڈیفالٹ

Linux پر، iptables اور ip6tables الگ پالیسیوں والی الگ جدولیں ہیں۔ IPv4 جدول کی INPUT اور OUTPUT چینز کو DROP پر رکھنے سے IPv6 جدول میں کچھ نہیں بدلتا، جہاں ڈیفالٹ عام طور پر ACCEPT ہوتا ہے۔ یہی تقسیم nftables میں بھی ہے، جہاں آپ ایک خاندان کا جائزہ لے سکتے ہیں اور جان سکتے ہیں کہ ان میں سے صرف ایک آپ کے قواعد اٹھائے ہوئے ہے۔ یہ عدم توازن عام ہے، اور سارا مسئلہ یہی ہے۔

اسی لیے کل سوئچ مکمل لگ سکتا ہے اور جزوی طور پر برتاؤ کر سکتا ہے۔ IPv4 قواعد لکھنے والی اسکرپٹ چلی، کاؤنٹر بڑھ رہے ہیں، لاگ لائن ظاہر ہوتی ہے، اور IPv6 پیکٹ فزیکل انٹرفیس سے بالکل اچھوت باہر جاتا ہے۔

پڑھیں کہ آپ کا کلائنٹ واقعی کیا انسٹال کرتا ہے، نہ کہ مارکیٹنگ صفحہ کیا وعدہ کرتا ہے۔ کچھ کلائنٹ IPv6 کو ٹنل میں روٹ کرتے ہیں، کچھ اسے جان بوجھ کر بلاک کرتے ہیں، اور کچھ اسے ویسے ہی چھوڑ دیتے ہیں جبکہ پلیٹ فارم سطحی لاک ڈاؤن کوئی اور قاعدہ نافذ کرتا ہے۔ یہاں قابل اعتماد واحد ذریعہ وینڈر کی دستاویزات ہیں۔

انٹرفیس کنفیگریشن آپ کو کیا بتاتی ہے

wg-quick کا مینوئل صفحہ اپنی مثال کنفیگریشن میں IPv6 قواعد شامل کرتا ہے، اور وجہ بالکل یہی خلا ہے۔ مثال سجاوٹ نہیں ہے۔ یہ اس لیے موجود ہے کیونکہ صرف IPv4 قواعد دوسرے خاندان کو کھلا چھوڑ دیتے۔

مثال کا آدھا کاپی کرنے سے پالیسی کا آدھا بنتا ہے۔ یہ اس لیک کا سب سے عام ماخذ ہے۔ ایک بلاگ پوسٹ نے لمبائی کی خاطر مثال کو چھوٹا کیا۔ پھر چھوٹا شدہ ورژن وہ ٹیمپلیٹ بن گیا جو سب نے دوبارہ استعمال کیا۔

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

اگر دوسرا کمانڈ اجازت دینے والی پالیسی چھاپتا ہے جبکہ پہلا DROP چھاپتا ہے، تو آپ نے کلائنٹ کو چھوئے بغیر جواب ڈھونڈ لیا۔ یہی عدم توازن بگ ہے۔

ایک تلاش پوری کہانی کیوں نہیں ہے

ایک نام A ریکارڈ اور AAAA ریکارڈ دونوں واپس کر سکتا ہے، اور تمام ایپس ایک ہی طرح نہیں چنتیں۔ نیٹ ورک IPv6 پیش کرے تو براؤزر اسے ترجیح دے سکتا ہے اور ناکامی پر پیچھے ہٹ سکتا ہے، جبکہ پس منظر سنک یا اپڈیٹر اپنا حل کنندہ اور اپنی ترجیح استعمال کرتا ہے۔ اس لیے IPv4 پر ایک کامیاب ٹیسٹ ایک راستہ ثابت کرتا ہے، پالیسی نہیں۔

نیٹ ورک تبدیلیاں بھی جواب بدلتی ہیں۔ دوسرے Wi-Fi نیٹ ورک میں شامل ہونا، نیند سے جاگنا یا موبائل پر جانا ڈیوائس کو نیا IPv6 سابقہ دے سکتا ہے، اور دفتر کے LAN پر کافی لگنے والی پالیسی اسے ڈھانپ نہ سکے۔

ٹنل بند ہونے کی حالت کی جانچ کریں

منسلک ہونے کے دوران جانچ بتاتی ہے کہ ٹنل کام کرتی ہے۔ دلچسپ جانچ دستیاب نہ ہونے کی حالت ہے، کیونکہ تب ہی کل سوئچ کو ٹکنا چاہیے۔ ٹنل کو جان بوجھ کر روکیں، پھر جس ایپ کی آپ حفاظت کر رہے ہیں اس سے اہم منزلیں آزمائیں۔

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

دونوں خاندانوں کو بند ہو کر ناکام ہونا چاہیے۔ اگر IPv4 درخواست کا وقت ختم ہو جائے اور IPv6 درخواست اسٹیٹس کوڈ واپس کرے، تو پالیسی نامکمل ہے، اور ٹنل کو کتنی بھی بار دوبارہ جانچنے سے یہ نہیں بدلے گا۔

اس جانچ میں دستاویزی استثنائیں بھی رکھیں۔ مقامی نیٹ ورک کی دریافت، DHCP کی تجدید یا VPN اینڈ پوائنٹ تک بوٹ اسٹریپ راستہ قابل رسائی رہنے کی ضرورت ہو سکتی ہے، اور وہ استثنائیں پالیسی میں نام رکھ کر بیان ہونی چاہئیں، کسی رکاوٹ کے دوران دریافت ہونے کے بجائے۔ ٹنل واپس نہ آ سکنے کی وجہ سے ناکام ہونے والا لیک ٹیسٹ سیکیورٹی دریافت نہیں ہے، یہ کنیکٹیویٹی دریافت ہے۔