میں نے ufw فعال کیا اور اب SSH کنیکٹ نہیں ہوتا۔ کیا میں نے سرور کھو دیا؟

نہیں۔ سرور خوب چل رہا ہے — آپ نے بس اندر سے دروازہ بلاک کر دیا۔ آپ کا ڈیٹا اچھوتا ہے۔ اپنے control panel میں web console کھولیں (یہ آپ کو SSH کے بغیر log in کرتا ہے) اور `sudo ufw disable` چلائیں، اور آپ واپس۔ کوئی reinstall درکار نہیں۔

ufw فعال کرنے نے میرا SSH کیوں مار دیا؟

ufw ڈیفالٹ تمام incoming ٹریفک روکنے پر ہوتا ہے، اور اگر آپ نے پہلے اپنا SSH port allow کیے بغیر اسے فعال کیا، تو آپ کا اپنا سیشن کٹ جاتا ہے۔ یہ سب سے عام خود-کردہ لاک آؤٹ ہے۔ ہمیشہ `ufw enable` سے پہلے `ufw allow `۔

اگر میں سرے سے SSH نہ کر سکوں تو ufw کیسے ٹھیک کروں؟

اپنے panel میں out-of-band web console (serial console) استعمال کریں — یہ SSH پر نہیں جاتی یا network stack بھی نہیں چاہتی، تو ایک firewall rule اسے بلاک نہیں کر سکتا۔ وہاں log in کریں، پھر `sudo ufw disable` (تیز ترین) یا مخصوص rule ٹھیک کرنے کو `sudo ufw allow `۔

ایک NAT VPS پر، میں ufw میں کون سا port allow کروں؟

22 allow کریں، external port نہیں۔ ایک NAT پلان پر آپ 20266 جیسے ایک high port پر کنیکٹ ہوتے، لیکن وہ VM کے اندر port 22 پر forward ہوتا ہے۔ ufw VM کے اندر چلتا اور صرف 22 دیکھتا ہے۔ 20266 allow کرنا کچھ نہیں کرتا؛ 22 allow کریں۔

کیا `ufw reset`، `ufw disable` سے محفوظ تر ہے؟

`disable` بس firewall آف کرتا اور آپ کے rules رکھتا ہے — واپس آنے کا تیز ترین طریقہ۔ `reset` ہر rule ڈیفالٹس پر مٹا دیتا ہے۔ recover کرنے کو `disable` استعمال کریں، پھر احتیاط سے rules دوبارہ جوڑیں۔ `reset` صرف تب اگر ruleset ایک گڑبڑ ہو جسے آپ ختم چاہتے ہیں۔

ufw سے اپنے VPS سے لاک آؤٹ؟ ایک reinstall کے بغیر واپس اندر آئیں

اپنا سرور چلانے میں کسی بھی نئے کے لیے ایک رسمِ گزر ہے: آپ ایک firewall سیٹ کرنے کا فیصلہ کرتے، چند ufw کمانڈز ٹائپ کرتے، enable دباتے ہیں — اور آپ کا terminal خاموش ہو جاتا ہے۔ SSH چلا گیا۔ آپ نے کچھ کریش نہیں کیا، آپ hack نہیں ہوئے۔ آپ نے بس دروازہ خود کو باہر کیے لاک کر دیا۔

یہ اچھے sysadmins کے ساتھ بھی ہوتا ہے۔ یہ پچھلے ہفتے ہمارے ایک گاہک کے ساتھ ہوا، اسی لیے میں یہ لکھ رہا ہوں۔ اچھی خبر: یہ ایک منٹ سے کم میں مکمل قابلِ بحالی ہے، اور آپ کو reinstall کرنے یا ایک بھی فائل کھونے کی ضرورت نہیں۔ یہ رہا کیسے۔

ایک firewall دیوار کے پیچھے مہر بند ایک VPS، واپسی کے راستے کے طور پر ایک چمکتی console window

دراصل کیا غلط ہوا

ufw (Uncomplicated Firewall) ڈیفالٹ تمام incoming روکو پر ہوتا ہے۔ جس لمحے آپ ufw enable چلاتے ہیں، جو کچھ بھی آپ نے واضح طور پر allow نہیں کیا وہ گرا دیا جاتا ہے — بشمول وہ SSH سیشن جس میں آپ بیٹھے ہیں۔ اگر آپ پہلے اپنا SSH port ufw allow کرنا بھول گئے، تو آپ نے rule کے مؤثر ہوتے ہی اپنا کنکشن کاٹ دیا۔

یہ کلاسک ورژن ہے۔ دو اور ذائقے ہیں جو لوگوں کو پکڑتے ہیں:

آپ نے غلط port allow کیا۔ Typo، یا آپ نے سروس port (مثلاً 8080) allow کیا اور 22 بھول گئے۔
آپ نے 22 allow کیا لیکن پھر فہرست میں اوپر ایک deny rule سیٹ کیا جو اسے چھپا دیتا ہے۔ ufw ترتیب-حساس ہے۔

کسی بھی طرح سرور خود ٹھیک ہے — چل رہا، ڈسک سالم، آپ کی ایپ پھر بھی دیوار کے پیچھے گنگنا رہی۔ یہ خالص ایک network-رسائی مسئلہ ہے۔ بالکل اسی لیے حل آسان ہے۔

غلط اقدام: reinstall کرنا

پہلی جبلت اکثر "بس سرور reset کرو اور نئے سرے سے شروع کرو" ہوتی ہے۔ نہ کریں — اس کے لیے نہیں۔ ایک reinstall ایک کام کرتا SSH واپس پانے کو سب کچھ مٹا دیتا ہے، جب SSH کو بلاک کرتی چیز ایک firewall کمانڈ ہے جسے آپ دس سیکنڈ میں undo کر سکتے ہیں۔ آپ گھر کو جلا دیں گے کیونکہ آپ نے سامنے کا دروازہ لاک کیا۔

Reinstall درست فیصلہ ہے جب آپ ایک صاف سلیٹ چاہتے ہیں۔ ایک ufw لاک آؤٹ کے لیے، یہ حد سے زیادہ ہے۔

درست اقدام: web console

ہر VPS جو اپنے نمک کے لائق ہے آپ کو ایک out-of-band console دیتا ہے — مشین میں ایک راستہ جو SSH پر یا network stack پر بھی سوار نہیں ہوتا۔ EQVPS پر یہ آپ کے سرور کے صفحے پر Console بٹن ہے۔ یہ ایک serial console ہے: صرف-متن، سیدھا VM سے جڑا اُس طرح جیسے ایک monitor اور keyboard۔ ایک firewall rule کا اس پر کوئی اختیار نہیں، کیونکہ یہ network ٹریفک نہیں۔

اسے کلک کریں، اپنے root credentials سے log in کریں (یا اگر آپ کے پاس نہ ہو تو panel میں پاس ورڈ reveal کریں)، اور آپ باکس پر ہیں — firewall ہو یا نہ ہو۔

اب نقصان undo کریں۔ تیز ترین راستہ:

sudo ufw disable

یہ firewall آف کرتا اور آپ کے rules رکھتا ہے، تو آپ غلطی ٹھیک کرنے کے بعد اسے بعد میں دوبارہ فعال کر سکتے ہیں۔ SSH سیدھا واپس آتا ہے۔

اگر آپ firewall کو مکمل چھوڑنا نہ چاہیں، تو بس وہ port کھولیں جو آپ نے مِس کیا:

sudo ufw allow 22
sudo ufw status numbered

status numbered منظر ایک نظر کے لائق ہے — یہ rule ترتیب دکھاتا ہے، جہاں "میں نے 22 allow کیا لیکن یہ پھر بھی بلاک کرتا ہے" صورتیں چھپتی ہیں۔ اگر ایک deny آپ کے allow کے اوپر بیٹھا ہو، تو اسے sudo ufw delete <number> سے مٹائیں۔

NAT پیچ جو زیادہ تر گائیڈز مِس کرتی ہیں

اگر آپ ایک NAT پلان پر ہیں، تو یہاں ایک جال ہے۔ آپ ایک high port پر SSH کرتے ہیں — 20266 جیسا کچھ — تو فطری جبلت ufw allow 20266 ہے۔ یہ کچھ نہیں کرتا۔

NAT پر، وہ external port VM کے اندر port 22 پر forward ہوتا ہے۔ ufw VM کے اندر چلتا اور صرف کبھی 22 دیکھتا ہے۔ تو وہ rule جو آپ کو دراصل چاہیے:

sudo ufw allow 22

20266 allow کریں اور آپ ایک اب بھی-ٹوٹے کنکشن کو گھورتے سوچیں گے کیوں۔ 22 allow کریں اور آپ اندر۔ کسی بھی سروس کے لیے وہی خیال: وہ port allow کریں جس پر process باکس کے اندر سنتا ہے، وہ forwarded والا نہیں جس پر آپ باہر سے کنیکٹ ہوتے ہیں۔

اسے دوبارہ کبھی کیسے نہ کریں

حل ایک منٹ لیتا ہے، لیکن اس کی ضرورت نہ ہونا اچھا تر ہے۔ دو عادات:

enable کرنے سے پہلے اپنا SSH port allow کریں۔ اس ترتیب میں، ہمیشہ:

sudo ufw allow 22
sudo ufw enable

اسے الٹا کریں اور آپ واپس console میں۔

firewall rules بدلتے وقت ایک دوسرا سیشن کھلا رکھیں۔ دو بار log in کریں۔ ایک window میں اپنے بدلاؤ کریں؛ اگر SSH مرے، تو دوسری window اسے ٹھیک کرنے کو ابھی زندہ ہے۔ پرانا trick، ہر بار آپ کو بچاتا ہے۔

اور اگر آپ ایک تازہ باکس سیٹ کر رہے ہیں، تو ہماری new-VPS security checklist ufw کو درست ترتیب میں کور کرتی ہے، SSH keys اور مٹھی بھر دیگر چیزوں کے ساتھ جو پہلے دس منٹ میں دراصل اہم ہیں۔

مختصر بات

ایک ufw لاک آؤٹ خوفناک لگتا اور تقریباً کچھ نہیں ہے۔ سرور کبھی نہیں گیا؛ آپ کو بس ایک ایسا دروازہ چاہیے جسے ایک firewall بند نہیں کر سکتا — web console — اور ایک کمانڈ۔ ufw disable اور console اپنی پچھلی جیب میں رکھیں، اگلی بار enable کرنے سے پہلے اپنا port allow کریں، اور آپ اس پر دوبارہ کبھی پسینہ نہیں بہائیں گے۔