آپ کا VPN ہوسٹ کرنے سے پہلے VPS کو کیا اجازت دینی چاہیے

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

پروٹوکول کے لیے مطلوبہ انٹرفیس کی تصدیق کریں

OpenVPN TUN پر چلنے کے لیے کریکٹر ڈیوائس اور اس کے پیچھے کرنل ماڈیول درکار ہے؛ WireGuard کو اپنی کرنل معاونت یا موافق توقعات کے ساتھ یوزر اسپیس عمل درآمد چاہیے۔ منظم کنٹینر ایسا میزبان کرنل شیئر کر سکتے ہیں جو ڈیوائس کو کبھی ظاہر نہیں کرتا، اور کچھ پلیٹ فارمز کچھ بھی نصب ہونے کے باوجود ٹنل انٹرفیس بنانے کو مکمل طور پر ممنوع قرار دیتے ہیں۔

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

پہلی جوڑی پر انکار کا مطلب ہے کہ TUN دستیاب نہیں اور OpenVPN کا ڈیفالٹ موڈ شروع نہیں ہو سکتا؛ آخری سطر پر انکار کا مطلب ہے کہ WireGuard کا کرنل انٹرفیس موجود نہیں۔ کرنل کی TUN/TAP دستاویز اس ڈیوائس کی وضاحت کرتی ہے جسے پہلی جانچ آزماتی ہے۔ دونوں ناکامیوں میں سے کوئی بھی VPN پیکیج دوبارہ نصب کرنے سے درست نہیں ہوتی۔

یاد رکھیں کہ اندر آنے والے راستے کے دو مالک ہیں

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

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

واپسی کے راستے کا منصوبہ بنائیں، صرف نکلنے کا نہیں

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

IPv6 کے معاملے کا واضح فیصلہ کریں

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

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

اسے بیرونی کلائنٹ سے ثابت کریں

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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