Windows پر WireGuard سرور کے عوامی IP تک SSH ناکام ہوتا ہے

وہ ٹنلیں جو اس وقت اٹھتی ہیں جب سرور کے عوامی پتے تک SSH کام کرنا بند کر دیتا ہے، سرور کی جانب سے کنکشن مسترد ہونے جیسی لگتی ہیں۔ Windows پر زیادہ ممکنہ سبب مقامی ہے: مکمل ٹنل کا /0 والا AllowedIPs محدود کرنے والے فائر وال قواعد فعال کر دیتا ہے جو ٹنل کی اپنی ترسیل اور بہت کم اور کچھ کی اجازت دیتے ہیں۔ اس پتے تک پہنچنے والے خفیہ کردہ پیکٹ اس بارے میں کچھ نہیں کہتے کہ اسی پتے تک کوئی الگ TCP کنکشن باہر جا سکتا ہے یا نہیں۔

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

روٹنگ کی اجازت اور فائر وال کی اجازت مختلف ہیں

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

اسی لیے اینڈ پوائنٹ تک traceroute کامیاب ہو سکتا ہے جبکہ SSH کی کوشش ناکام ہو جاتی ہے۔ پہلے کو وہ سروس اٹھاتی ہے جس کے پاس استثنا ہے، دوسرے کو نہیں۔

Windows پر /0 کیا کرتا ہے

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

وہ قواعد kill switch کے فقرے کے پیچھے کا طریقہ کار ہیں۔ وہ اس نام والے چیک باکس سے نہیں بلکہ ترتیب کی شکل سے فعال ہوتے ہیں۔

استثنائیں تحفظ کا ماڈل بدل دیتی ہیں

/0 کو دو نصف طے شدہ سابقوں سے بدلنا محدود معنی کے بغیر وسیع روٹنگ برقرار رکھنے کا دستاویزی طریقہ ہے، اور یہ مختصر ہجے نہیں بلکہ مختلف تحفظ ماڈل ہے۔ اجازت یافتہ سابقوں سے اینڈ پوائنٹ کا پتہ نکالنا دوسرا عام حل ہے، جو فہرست کو طویل کرتا ہے اور یہ بھی بدلتا ہے کہ کون سے قواعد فعال ہوتے ہیں۔ دونوں میں سے کوئی بھی مقامی اثر والی مقامی ترمیم نہیں ہے۔ ہر ایک مشین پر ہر بہاؤ کے لیے حد کو حرکت دیتا ہے، صرف اس کنکشن کے لیے نہیں جو آپ ٹھیک کر رہے تھے۔

جہاں براہ راست عوامی SSH واقعی ضروری ہو، پروفائل کا مالک بیرونی روٹ اور اس کی فائر وال اجازت دونوں ڈیزائن کرے، اور یہ طے کرے کہ ٹنل گرنے پر غیر متعلقہ ٹریفک کا کیا ہوگا۔ IPv4 اور IPv6 کا الگ الگ جائزہ لینا بھی اس میں شامل ہے، کیونکہ قواعد خاندان کے لحاظ سے بیان ہوتے ہیں۔ ایک منتظمی نشست بچانے کے لیے شامل کردہ وسیع بائی پاس عام طور پر اس نشست سے زیادہ آشکار کرتا ہے۔

آپ نے جو منتظمی راستہ چنا اسے آزمائیں

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

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

اندرونی پتے تک کامیاب SSH ثابت کرتا ہے کہ ٹنل منتظمی ٹریفک لے جاتی ہے اور سرور کی اپنی فائر وال اسے پیروں کی حد سے قبول کرتی ہے۔ دونوں اہداف پر ناکامی Windows روٹنگ کا نہیں بلکہ سرور کی جانب یا چابی کا مسئلہ ہے۔ اگر اندرونی پتہ کام کرے اور بیرونی نہ کرے، مقامی فائر وال رویہ وہی کر رہا ہے جس کے لیے اسے بنایا گیا تھا۔ پروفائل میں ترمیم سے پہلے تینوں نتائج اسی ترتیب سے پڑھیں۔

منتظمی راستہ، استعمال شدہ پتہ اور ٹنل بند ہونے پر رویہ ریکارڈ کریں۔ پانچ منٹ بچانے کے لیے بائی پاس کو وسیع کرنے سے اگلے شخص کو روکنے والی وہی نوٹ ہے۔