روٹڈ VPN کیپچر برانچ کا VLAN ٹیگ کیوں کبھی نہیں دکھاتا

ٹنل انٹرفیس پر لیے گئے کیپچر کبھی برانچ کا VLAN ID نہیں دکھائیں گے، اور یہ ٹول کی کمی نہیں بلکہ ڈیزائن کی خصوصیت ہے۔ روٹڈ TUN ٹنل IP پیکٹ لے کر جاتا ہے، اس لیے وہ ٹیگ شدہ Ethernet فریم جو انہیں برانچ لنک پر لے کر جاتا تھا اسی روٹر پر ختم ہوتا ہے جس نے انہیں روٹ کیا۔ اگر آپ کی پالیسی کا سوال سیگمنٹس کے بارے میں ہے، تو کیپچر شروع ہونے سے پہلے اسی سوال کے لیے سینسر کی پوزیشن منتخب کرنی ہوگی۔ جس VLAN فیلڈ کی آپ توقع کر رہے تھے اسے ایسے سیاق سے بدلنا ہوگا جس کا آپ دفاع کر سکیں۔

دیکھیں کہ ٹنل انٹرفیس دراصل کیا لے کر جاتا ہے

TUN میزبان کو IP پیکٹ پہنچاتا ہے؛ TAP Ethernet فریم پہنچاتا ہے۔ روٹڈ ڈیزائن پہلا استعمال کرتا ہے، یعنی ڈکرپشن کے بعد آنے والے پیکٹ میں لنک لیئر ہیڈر ہی نہیں ہوتا، اور اسی لیے پڑھنے کے لیے کوئی 802.1Q ٹیگ بھی نہیں ہوتا۔ راستے میں کچھ نہیں ہٹایا گیا، کیونکہ ٹیگ کبھی ٹنل میں داخل ہی نہیں ہوا۔ اندرونی پیکٹ اپنے IP ہیڈر سے شروع ہوتا ہے، اس لیے VLAN سے واقف قاعدہ جس ہر فیلڈ کی توقع کرتا ہے وہ محض غائب ہے۔

کیپچر پر بحث کرنے سے پہلے انٹرفیس کی قسم کی تصدیق کریں، کیونکہ اسی تعیناتی میں موجود TAP ڈیوائس مختلف رویہ اختیار کرے گی اور غلط نتیجے کی طرف لے جائے گی۔

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

پہلا کمانڈ ڈیوائس کی قسم اور اس کے جھنڈے چھاپتا ہے۔ دوسرا پہلے بیس پیکٹوں کے لنک لیئر ہیڈر چھاپتا ہے، اور TUN ڈیوائس پر آؤٹ پٹ Ethernet بلاک کے بغیر IP سے شروع ہوتا ہے، جو ایک ہی اسکرین میں پوری وضاحت ہے۔

TAP منتخب کرنے سے بھی ٹیگ واپس نہیں آتا۔ TAP ڈیوائس فریم پل کو بھیجتی ہے، اور ٹیگ کے ساتھ کیا ہوتا ہے یہ پل کی VLAN فلٹرنگ اور پورٹ کی ترتیب شدہ رکنیت پر منحصر ہے۔ یہ اپنے ناکامی کے طریقوں والا الگ ڈیزائن فیصلہ ہے۔

تین میں سے ایک جگہ کھڑے ہوں اور جو یہ دیکھ سکتا ہے اسے قبول کریں

برانچ کے Ethernet سیگمنٹ پر ٹیگ موجود ہے، لیکن سینسر صرف اسی سیگمنٹ کی مقامی ٹریفک دیکھتا ہے۔ بیرونی VPN نیٹ ورک پر ٹریفک محفوظ ہے، اس لیے مشاہد صرف سرے اور حجم جانتا ہے اور اندرونی پیکٹ کے بارے میں کچھ نہیں۔ ڈکرپشن کے بعد TUN راستے پر اندرونی IP پیکٹ اپنے پتوں اور پورٹس کے ساتھ دستیاب ہے، اور برانچ کے فریم کے بغیر۔ اس لیے ایک ہی بہاؤ کے ٹرنک پر کیپچر اور روٹڈ کیپچر دو مختلف گفتگوؤں کی طرح لگتے ہیں۔

وہ تین پوزیشنیں تین مختلف سوالوں کا جواب دیتی ہیں، اور ایک کیپچر بیک وقت تینوں نہیں ہو سکتا۔

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

جوڑی چلائیں اور موازنہ کریں۔ پہلا ٹیگ شدہ فریم اور ان کے VLAN ID دکھاتا ہے جہاں برانچ لنک میزبان کی طرف ٹرنک ہے؛ دوسرا روٹنگ کے بعد وہی گفتگو سادہ IP کے طور پر دکھاتا ہے۔ اگر پہلا کچھ بھی واپس نہ کرے، تو دیکھیں کہ میزبان پورٹ رسائی پورٹ ہے یا نہیں، کیونکہ تب سوئچ ٹیگ پہلے ہی ہٹا چکا ہوگا اور میزبان پر کوئی بھی کیپچر اسے کبھی نہیں دکھائے گا۔

گمشدہ ٹیگ کو ایسی میپنگ سے بدلیں جس کا آپ دفاع کر سکیں

اگر پالیسی سیگمنٹس کو IP پریفکس سے الگ کرتی ہے، تو وہ میپنگ اس کی حدود کے ساتھ لکھیں۔ اوورلیپنگ پتہ رینجیں، ماخذ ترجمہ اور مشترکہ گیٹ وے ہر ایک ایک پریفکس کو یہ شناخت کرنے کے لیے ناکافی بنا سکتا ہے کہ پیکٹ واقعی کہاں سے آیا۔

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

ip route get 10.20.30.40
ip -br addr show

پہلا کمانڈ بتاتا ہے کہ کرنل کسی منزل کے لیے کون سا انٹرفیس اور ماخذ استعمال کرے گا، جو سیگمنٹ سے وابستگی کا مقامی منظر ہے۔ دوسرا ہر انٹرفیس کے پتے فہرست کرتا ہے تاکہ آپ کی میپنگ کے پریفکس خاکے کے بجائے حقیقت کے سامنے جانچے جا سکیں۔

نتیجے پر بھروسہ کرنے سے پہلے واپسی راستہ اور پے لوڈ جانچیں

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

اندرونی IP پیکٹ کی بحالی اس کے اندر کے HTTPS سیشن کو بھی ڈکرپٹ نہیں کرتی۔ اگر پالیسی کا سوال بہاؤ کے بجائے مواد کے بارے میں ہے، تو سینسر کی پوزیشن دوبارہ بدلنی ہوگی، اور وہ فیصلہ اسی ڈیزائن دستاویز کا حصہ ہے۔

صرف VLAN فیلڈ کے ظاہر ہونے کے لیے غیر محدود ٹرنک کو سینسر تک بڑھانا اصل سوال کا جواب دیے بغیر نیٹ ورک کی حد کو وسیع کرتا ہے۔ پالیسی کو درکار معلومات کے لیے پوزیشن منتخب کریں، جو یہ نہیں دیکھ سکتا اسے درج کریں، اور سوال بدلنے پر انتخاب کا دوبارہ جائزہ لیں۔