OpenVPN سے منسلک ہیں لیکن ping یا SMB اشتراک نہیں؟ تین دروازے جانچیں

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

ہر دروازہ مختلف علامت کے ساتھ ناکام ہوتا ہے، اور صرف پہلا ہی VPN سرور پر ہے۔

فارورڈنگ FORWARD زنجیر پر ایک پالیسی ہے

OpenVPN سننے والے کی قبولیت INPUT پر ہوتی ہے، اسی لیے ٹنل جڑ سکتی ہے جبکہ LAN کی طرف جانے والا ہر پیکٹ خارج کر دیا جاتا ہے۔ وہ ٹریفک جو tun0 پر آتا ہے اور LAN انٹرفیس سے باہر جاتا ہے، FORWARD سے گزرتا ہے، اور وہاں ڈیفالٹ DROP پالیسی والا ہوسٹ اسے خاموشی سے خارج کر دیتا ہے۔ کسی اور چیز کو چھونے سے پہلے sysctl اور زنجیر دونوں جانچیں: sysctl net.ipv4.ip_forward اور iptables -L FORWARD -v -n۔

جس سمت کا آپ ارادہ رکھتے ہیں اور اس سے متعلق جوابات کی اجازت دیں، مثلاً ٹنل انٹرفیس سے LAN انٹرفیس تک accept قاعدہ اور established نیز related ٹریفک کے لیے stateful قاعدہ۔ اگر LAN کسی دوسرے راؤٹر کے پیچھے ہے تو اس راؤٹر کو کلائنٹ پول کی طرف واپسی راستہ یا VPN سرور پر source NAT درکار ہے۔ مزید قواعد شامل کرنے سے پہلے ایک ping سے اس راستے کی تصدیق کریں، کیونکہ جس قاعدے تک پہنچا نہ جا سکے وہ کبھی کاؤنٹر میں ظاہر نہیں ہوتا۔

SMB کو ایک سے زیادہ پورٹ درکار ہیں

فائل اشتراک ایک ہی TCP 445 گفتگو نہیں ہے۔ دریافت UDP 137 اور 138 استعمال کرتی ہے، پرانے NetBIOS سیشن TCP 139 استعمال کرتے ہیں، اور جدید SMB سیشن TCP 445 استعمال کرتے ہیں۔ صرف 445 کھولنے والا قاعدہ وہ پریشان کن صورت بناتا ہے جس میں میپ شدہ ڈرائیو کام کرتی ہے اور نیٹ ورک براؤزنگ نہیں، یا اس کے برعکس۔

ٹنل کے ذریعے بڑی منتقلیاں بھی MSS مسائل سے ٹکراتی ہیں جو ٹوٹے اشتراک جیسی لگتی ہیں۔ وہ SYN جو LAN کے پورے سیگمنٹ کا حجم اعلان کرتا ہے ٹنل کے چھوٹے MTU کی وجہ سے خارج ہو جاتا ہے، اور مصافحے کے بعد کنکشن لٹک جاتا ہے۔ فارورڈنگ راستے پر MSS محدود کرنا، iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu، اس قسم کی رکاوٹ کو دور کرتا ہے۔ ڈائریکٹری فہرست کے بجائے چند میگابائٹ کی کاپی سے جانچیں، کیونکہ بڑی منتقلیاں نہ گزرنے پر بھی چھوٹے جوابات گزر جاتے ہیں۔

ٹنل اڈاپٹر نئے نیٹ ورک پروفائل کے طور پر آتا ہے

Windows ہر اڈاپٹر کو نیٹ ورک پروفائل میں درجہ بند کرتا ہے، اور نیا ٹنل اڈاپٹر عام طور پر Public میں پڑتا ہے، جہاں فائل اور پرنٹر اشتراک کے قواعد بلاک ہوتے ہیں۔ یہ فائل سرور پر ہوسٹ فائر وال کا فیصلہ ہے، VPN سرور پر راؤٹنگ کا مسئلہ نہیں۔ پالیسی کی اجازت کی تصدیق کے بعد جان بوجھ کر زمرہ بدلیں Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private سے، کیونکہ زمرہ یہ بھی بدلتا ہے کہ کون سے اندرونی قواعد لاگو ہوں گے۔

وہی پروفائل بتاتا ہے کہ TCP 445 کامیاب ہونے پر ping کیوں ناکام ہوتی ہے: Public میں ایکو درخواستیں ڈیفالٹ طور پر خارج ہوتی ہیں۔

نام خود بخود راؤٹ شدہ ٹنل کو عبور نہیں کرتے

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

اگر تعیناتی اب بھی WINS پر منحصر ہے تو نشریاتی ٹریفک آنے کی امید کے بجائے کلائنٹ پر اسے ترتیب دیں۔ پہلے پتے سے جانچیں تاکہ نام کی ناکامی فائر وال کی ناکامی نہ سمجھی جائے۔

ایک وقت میں ایک پرت جانچیں اور پہلی ناکامی پڑھیں

اوپر کی طرف بڑھیں: ٹنل گیٹ وے کو ping کریں، پتے سے LAN ہوسٹ کو ping کریں، پھر Test-NetConnection -ComputerName 10.8.0.5 -Port 445 سے سروس کی پورٹ کھولیں، اور اس کے بعد ہی اشتراک پر تصدیق کریں۔ پہلا ناکام قدم ہی وہ پرت ہے جسے درست کرنا ہے، اور اس کے بعد کا ہر قدم شور ہے جب تک وہ گزر نہ جائے۔ جو ping جواب دیتا ہے جبکہ پورٹ بند رہتی ہے وہ فائل سرور کی اپنی فائر وال کی طرف اشارہ کرتا ہے، جبکہ خاموش ping کے باوجود کھلنے والی پورٹ ICMP فلٹرنگ کی طرف اشارہ کرتی ہے۔ کچھ بھی بدلنے سے پہلے پہلا ناکام قدم لکھ لیں، کیونکہ دوسری تبدیلی پہلی کا نتیجہ چھپا دیتی ہے۔

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

اپنے نوٹس میں اشتراک کا اکاؤنٹ VPN لاگ ان سے الگ رکھیں، کیونکہ کامیاب ٹنل فائل اجازتوں کے بارے میں کچھ نہیں بتاتی۔ گمشدہ قاعدے سے بچنے کے لیے SMB کو انٹرنیٹ پر کھولنا حل نہیں ہے۔