UFW ٹنل اٹھتے ہی VPN کے DNS سرور کو چھوڑ دیتا ہے
UFW کی ڈیفالٹ انکار پالیسی ٹنل کے انٹرفیس کو بھی ڈھانپتی ہے۔ ٹریفک کو سمت کے مطابق ترتیب دیں، tun0 پر دھکیلی گئی resolver کی اجازت دیں، پھر باہر کا راستہ کھولیں۔
VPN جڑتے ہی نام حل ہونا بند ہو جاتے ہیں، جبکہ کسی عوامی پتے پر ping اب بھی جواب دیتا ہے اور فائر وال کی حالت میں غلط دکھنے والا کچھ نہیں دکھتا۔ پالیسی میں کچھ نہیں بدلا؛ بدلا یہ ہے کہ نیا انٹرفیس آیا، اور ڈیفالٹ انکار پہلے پیکٹ سے ہی اسے ڈھانپ لیتا ہے۔ UFW سمت اور انٹرفیس کے مطابق فیصلہ کرتا ہے، اس لیے وائرلیس لنک کے لیے لکھا گیا قاعدہ ٹنل سے نکلنے والی ٹریفک کے بارے میں کچھ نہیں کہتا۔ مرمت چند تنگ قواعد ہیں جو ایک خاص ترتیب میں لاگو کیے جاتے ہیں۔
علامت ٹنل اٹھنے کے بعد ہی ظاہر ہوتی ہے
ڈیفالٹ انکار کی پالیسی وہی کرتی ہے جو اسے کہا گیا: ہر وہ چیز جس کا کوئی مماثل قاعدہ نہ ہو، ہر موجود انٹرفیس پر رد کر دی جاتی ہے۔ قواعد لکھے جانے کے وقت ٹنل موجود نہیں تھا، اس لیے ان میں سے کوئی بھی اسے پکڑ نہیں سکتا، اور جو انکار ہمیشہ سے تھا وہ اب نام حل کرنے پر لاگو ہوتا ہے۔ کسی لفظی پتے پر براہ راست ٹریفک تب بھی کام کر سکتی ہے جب کوئی وسیع اجازت اسے ڈھانپ لے، اور اسی لیے عوامی resolver پر ping کامیاب ہوتا ہے جبکہ نام کی تلاش ناکام ہوتی ہے۔ خلا اس انٹرفیس کے لیے قاعدہ ہے جسے پالیسی نے کبھی نہیں دیکھا۔
یہ بھی بتاتا ہے کہ ناکامی صاف طور پر کیوں الٹ جاتی ہے: ٹنل نیچے کریں اور نام پھر حل ہونے لگتے ہیں، کیونکہ استفسار ایسے انٹرفیس پر واپس جاتا ہے جس کے پاس قواعد ہیں۔ جو پالیسی صرف ٹنل اٹھنے پر ناکام ہوتی ہے وہ DNS مسئلہ نہیں ہے، اور resolver کو ہی ٹیون کرنا یہاں سب سے زیادہ وقت ضائع کرتا ہے۔ resolver کی ترتیب پڑھنے سے پہلے انٹرفیسوں کی فہرست پڑھیں۔
تین سمتیں، تین مختلف قاعدہ مجموعے
ایک سیشن ایک سے زیادہ سمتوں میں قواعد کو چھوتا ہے، اور ٹنل ان میں سے تقریباً ہر ایک میں دوسرا انٹرفیس شامل کرتا ہے۔ ٹریفک کو پہلے سمت اور انٹرفیس کے مطابق ترتیب دینا باقی کو مشینی بنا دیتا ہے، کیونکہ نیچے کی ہر سطر کو اپنی جگہ پر اپنا قاعدہ چاہیے۔ مثالیں tun0 اور 10.8.0.0/24 کے تالاب کا استعمال کرتی ہیں، اس لیے نام اور حدود کلائنٹ کے اپنے آؤٹ پٹ سے رکھیں۔
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
دو سطریں اکثر الجھ جاتی ہیں کیونکہ دونوں ٹنل کا ذکر کرتی ہیں۔ resolver کا قاعدہ اس ٹریفک کی اجازت دیتا ہے جو کلائنٹ ٹنل میں بھیجتا ہے، جبکہ SSH کا قاعدہ اس ٹریفک کی اجازت دیتا ہے جو سرور وہاں سے حاصل کرتا ہے؛ وہ مختلف مشینوں پر رہتے ہیں اور الگ الگ ناکام ہوتے ہیں۔ سب سے زیادہ بھولی جانے والی سطر دوسری ہے، کیونکہ کلائنٹ ٹنل بنانے ہی نہیں سکتا جب تک سرور کے عوامی پتے پر اس کی ٹریفک کی اجازت نہ ملے۔ اوپر سے نیچے کام کریں اور ہر ناکامی کی ایک ممکنہ وجہ ہوتی ہے۔
دھکیلا گیا resolver اپنا قاعدہ مانگتا ہے
ٹنل DNS لے کر جاتا ہے یا نہیں، یہ اس پر منحصر ہے کہ سرور کیا بھیجتا ہے۔ جو سرور resolver کا آپشن دھکیلتا ہے وہ کلائنٹ کی ترتیب میں نجی پتہ نصب کرتا ہے، اور وہ پتہ صرف ٹنل سے ہی روٹ ہو سکتا ہے۔ اگر سرور کچھ نہ دھکیلے، تو کلائنٹ اپنا پہلے والا resolver رکھتا ہے اور نیچے کے قواعد کے پاس اجازت دینے کو کچھ نہیں ہوتا۔ کچھ بھی لکھنے سے پہلے دھکیلی گئی حالت اور موجودہ استفسار کا نتیجہ جانچیں:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedحالت کا آؤٹ پٹ استعمال ہو رہے resolver اور اس لنک کا نام بتاتا ہے جس سے وہ بندھا ہے، اور اس کے پیچھے راستے کی تلاش بتاتی ہے کہ کون سا انٹرفیس اس پتے تک استفسار لے جائے گا۔ جب resolver کسی دوسرے لنک پر بیٹھا ہو، مسئلہ فائر وال سے پہلے کا ہے اور کوئی قاعدہ مدد نہیں کرے گا۔ جب دونوں ٹنل پر متفق ہوں، دو قواعد چاہئیں، کیونکہ زیادہ تر استفسارات UDP لے جاتا ہے اور جواب کٹنے پر TCP سنبھال لیتا ہے۔ دونوں اقدار لکھ لیں، کیونکہ قواعد انہی کا نام لیں گے:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'اندر کے راستے سے پہلے باہر کا راستہ کھولیں
ٹنل بننے سے پہلے کلائنٹ کو سرور کے عوامی پتے تک پہنچنا ہوتا ہے، اس لیے اس کا قاعدہ طبعی لنک پر بیٹھتا ہے اور پہلے اپنی جگہ پر ہونا چاہیے۔ جو پالیسی resolver کی اجازت دیتی ہے مگر سرور بھول جاتی ہے، وہ کلائنٹ کو ٹنل بنانے سے بالکل قاصر چھوڑ دیتی ہے، اور یہ علامت عام طور پر kill switch پر ڈالی جاتی ہے۔ پھر ان خدمات کی اجازت دیں جو آپ واقعی ٹنل سے چاہتے تھے، ایک وقت میں ایک تنگ قاعدہ، پورا انٹرفیس کھولنے کے بجائے۔ تنگ قواعد ہی وہ وجہ ہیں کہ انکار اپنی جگہ پر رہ سکتا ہے۔
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'جانچ کے دوران ترتیب اہم ہے، کیونکہ ٹنل کو اٹھنے دینے والا پہلا قاعدہ ہی ہے۔ اسے شامل کریں، جڑیں، اور خدمت کا قاعدہ شامل کرنے سے پہلے یقینی بنائیں کہ ٹنل اٹھا ہوا ہے، کیونکہ دونوں ایک ساتھ کرنے کا مطلب ہے کہ ناکامی یہ نہیں بتاتی کہ کون سا آدھا غلط ہے۔ اوپر کے دستاویزی پتے کی جگہ وہ اینڈ پوائنٹ رکھیں جس کے لیے کلائنٹ ترتیب دیا گیا ہے۔
جان بوجھ کر کنکشن کاٹ کر کلائنٹ کا حصہ مکمل کریں۔ انکار کو اب بھی اس ٹریفک کو رد کرنا چاہیے جو آپ نے جان بوجھ کر خارج کیا، کیونکہ ٹنل اٹھنے پر جواب دینے والا resolver شک ہونے پر انکار کرنے والی پالیسی کا صرف آدھا حصہ ڈھانپتا ہے۔
جڑنے والا کلائنٹ ابھی منظور نہیں
سرور کو بھی اپنی سمت سوچنی ہوتی ہے، اور مصافحہ مکمل کرنے والا کلائنٹ سرور کے منظور کرنے تک سرور پر چلنے والی کسی چیز تک نہیں پہنچ سکتا۔ عوامی سننے والے کا قاعدہ صرف ٹنل کے وجود کی اجازت دیتا ہے؛ وہ ٹنل کی ٹریفک کو اندر نہیں آنے دیتا۔ سرور پر یہ دو قواعد اور ایک جانچ ہے کہ خدمت واقعی سن رہی ہے:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'قاعدے میں تالاب سرور کے مختص کردہ دائرے کے برابر ہونا چاہیے، اور ٹنل نمبر وہی ہونا چاہیے جو سرور نے بنایا، کیونکہ دوسرے انٹرفیس کا قاعدہ قاعدہ نہ ہونے سے الگ نہیں پہچانا جا سکتا۔ limit انتظامی پورٹ کے لیے جان بوجھ کر ہے، کیونکہ یہ دہرائے جانے والے کنکشن بلا حد قبول کرنے کے بجائے محدود کرتا ہے۔ سننے والے کی جانچ بند پورٹ اور پھینکے گئے پیکٹ میں فرق کرتی ہے، جو کلائنٹ کی طرف سے ایک جیسے دکھتے ہیں۔ نمبر والے قواعد بھی پوری تصویر نہیں: UFW کے before قواعد اور ہاتھ سے لکھی گئی کوئی بھی nftables سطر پہلے مماثل ہوتی ہے اور فہرست کی اجازت والا دکھنے والا پیکٹ بھی اب بھی رد کر سکتی ہے۔