ایک NIC یا دو؟ VPN سرور کے انٹرفیس ترتیب کا تعین

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

وہ تین شرطیں جو اس کا تعین کرتی ہیں

پہلی شرط منزل ہے۔ VPN ہوسٹ پر ہی موجود سروس تک صرف ٹنل انٹرفیس سے پہنچا جا سکتا ہے، جبکہ LAN پر موجود ہوسٹ کے لیے فارورڈنگ اور واپسی کا راستہ درکار ہے۔ دوسری شرط وہ واپسی کا راستہ ہے، کیونکہ LAN ڈیوائس کو معلوم ہونا چاہیے کہ کلائنٹ پول تک کیسے پہنچنا ہے، راستے سے یا سرور پر ترجمے سے۔

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

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

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

جب سروس VPN ہوسٹ پر چلتی ہے

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

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

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

جب منزل LAN پر ہو

یہیں سے یک ایڈاپٹر ڈیزائن کو مشکل ہونے کی شناخت ملتی ہے۔ سرور کو کلائنٹ کے پیکٹ LAN کی طرف فارورڈ کرنے ہوتے ہیں، اور LAN ڈیوائس کو جوابات کلائنٹ پول تک واپس بھیجنے ہوتے ہیں۔ یا تو آپ اس پول کو LAN پر راستے کے طور پر لے کر چلیں، یا سرور پر ماخذ پتہ ترجمہ کریں تاکہ جوابات خود سرور کو واپس آئیں۔

دونوں جوابات درست ہیں اور دونوں مختلف طریقوں سے ناکام ہوتے ہیں۔ واپسی کا راستہ اصل کلائنٹ پتہ منزل کو نظر آتا رہتا ہے، جو لاگ کے لیے اچھا اور LAN پتے فرض کرنے والے فائر وال قوانین کے لیے برا ہے۔ ترجمہ LAN کو سادہ رکھتا ہے اور منزل سے کلائنٹ کی شناخت چھپا دیتا ہے۔

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

غیر متناسب راستہ اس کی عام علامت ہے: کلائنٹ کی درخواست پہنچتی ہے، جواب کسی دوسرے روٹر سے نکلتا ہے، اور کنکشن دونوں سروں پر بغیر کسی خرابی کے وقت ختم ہو کر رک جاتا ہے۔ ٹنل کے بارے میں کوئی نتیجہ نکالنے سے پہلے دونوں طرف کیپچر کریں۔

alias دوسرا زون کیوں نہیں بناتا

اسی ایڈاپٹر پر دوسرا پتہ شامل کرنا، یا دوسرے پورٹ کی نقل کے لیے dummy انٹرفیس بنانا، بہت کم بدلتا ہے۔ پیکٹ اب بھی اسی جسمانی لنک، اسی سوئچ پورٹ اور عموماً اسی فائر وال چین سے باہر جاتے ہیں، اس لیے ان کے درمیان کوئی نئی حد نہیں بنتی۔ یہ ترتیب کی سہولت ہے، تقسیم نہیں۔ اسے زون کی حد سمجھنا ہی وہ طریقہ ہے جس سے تنہائی کا دعوی صرف کاغذ پر زندہ رہتا ہے۔

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

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

اپنی اجازت شدہ ٹریفک کے سامنے ترتیب جانچیں

وہ ٹریفک کلاسیں فہرست کریں جو سرور کو لے کر جانا ہے: کلائنٹ سے ہوسٹ، کلائنٹ سے LAN، ہوسٹ سے LAN، اور خفیہ شدہ بیرونی کنکشن۔ ہر کلاس کا ماخذ، منزل اور انٹرفیس ہوتا ہے، اور ترتیب کو چاروں ایک ساتھ پورے کرنے ہوتے ہیں۔ جو ڈیزائن ان میں سے تین سنبھالتا ہے، وہی عموماً ٹکٹ پیدا کرتا ہے۔

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

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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