NAT کرنے والے VPN گیٹ وے کے پیچھے FTP فہرستیں کیوں لٹکی رہتی ہیں
لاگ اِن اور PWD کامیاب ہوتے ہیں، جبکہ NAT صرف ہیڈر دوبارہ لکھے تو LIST اور RETR رک جاتے ہیں۔ دیکھیں کہ FTP معاون کہاں ہونا چاہیے اور غیر فعال موڈ کیسے درست کریں۔
لاگ اِن کام کرتا ہے، PWD کام کرتا ہے، اور پھر LIST لٹکا رہتا ہے جب تک کلائنٹ ہار نہ مانے یا کسی دوسرے ڈیٹا موڈ میں نہ جائے۔ یہی تقسیم نشانی ہے: پورٹ 21 تک کنٹرول کنکشن صحت مند ہے، جبکہ ڈیٹا کنکشن ایسے پتے یا پورٹ سے بن رہا ہے جہاں دوسرا سرا پہنچ نہیں سکتا۔ جو VPN گیٹ وے خود بھی NAT کرتا ہے، اس کے پیچھے عام مجرم وہ FTP کمانڈ ہے جس کے پے لوڈ میں 10.8.0.6 جیسا ٹنل پتہ درج ہوتا ہے۔ ہیڈر کی ترجمانی اس قدر کو کبھی نہیں چھوتی۔
آگے یہ ہے کہ وہ قدر کہاں سے آتی ہے، اور کون سا باکس اسے بدل سکتا ہے۔
ٹوٹتا پے لوڈ ہے، ٹنل نہیں
FTP ڈیٹا کے آخری نقطے کو کنٹرول اسٹریم کے اندر رکھتا ہے۔ فعال موڈ میں کلائنٹ اپنے پتے اور پورٹ کے ساتھ PORT بھیجتا ہے، اور سرور اسی جوڑی کو واپس کال کرتا ہے۔ غیر فعال موڈ میں سرور جوڑی کے ساتھ 227 کا جواب دیتا ہے، اور کلائنٹ اس کے بجائے اسی کو کال کرتا ہے۔
دونوں شکلیں ایک ہی قسم کا بیان رکھتی ہیں: اس پتے پر، اس پورٹ پر جڑو۔ جو آلہ صرف IP اور TCP ہیڈر دوبارہ لکھتا ہے وہ بیان کو ویسا ہی چھوڑ دیتا ہے، اس لیے ایک سرا ایسے پتے تک پہنچنے کی کوشش کرتا رہتا ہے جو صرف ٹنل کے دوسری طرف موجود ہے۔ کنٹرول کنکشن پہلے ہی صحت مند قرار دیے جانے کے بعد ڈیٹا کنکشن رک جاتا ہے۔
تین موڈ، تین پے لوڈ
نیچے دیا گیا جدول دکھاتا ہے کہ کس طرف کو کال کرنے کا کہا جا رہا ہے، اور صرف ہیڈر بدلنے والا NAT اس بارے میں کیا کر سکتا ہے۔
آخری کالم کو پہلے ناکام ہونے والی چیز کے طور پر پڑھیں۔ فعال موڈ میں نجی پتے پر کال سرور کرتا ہے، غیر فعال موڈ میں کلائنٹ، اور FTPS میں پے لوڈ خفیہ متن ہے اور درمیانی باکس کے پاس کام کرنے کے لیے اور بھی کم ہے۔
| Mode | Value in the control stream | Who dials whom | Header-only NAT leaves |
|---|---|---|---|
| Active (PORT) | client address and port | server dials the client | a server dialing an unreachable tunnel address |
| Passive (227) | server address and port | client dials the server | a client dialing an address it cannot route to |
| FTPS | the same values, inside TLS | as above | ciphertext, so no rewrite happens at all |
معاون کو وہیں رکھیں جہاں ترجمانی ہوتی ہے
لینکس پر پے لوڈ دوبارہ لکھنے کا کام nf_conntrack_ftp معاون کرتا ہے۔ یہ کنٹرول کنکشن پر نظر رکھتا ہے، طے شدہ پورٹ سیکھتا ہے، ڈیٹا بہاؤ کے لیے توقع بناتا ہے، اور NAT باکس پر پے لوڈ کے اندر کا پتہ اور پورٹ دوبارہ لکھتا ہے۔ یہ صرف اسی آلے پر مدد کرتا ہے جو کلائنٹ کے پتے کی ترجمانی کرتا ہے۔ اسے کلائنٹ پر یا صرف بہاؤ آگے بھیجنے والے راؤٹر پر لوڈ کرنے سے سیشن میں کچھ نہیں بدلتا۔
یہ تین کمانڈیں دکھاتی ہیں کہ ماڈیول موجود ہے یا نہیں، جڑا ہوا ہے یا نہیں، اور سیشن کھلا ہونے کے دوران توقع ہے یا نہیں:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpماڈیول لوڈ کرنا اسے جوڑنے کے برابر نہیں۔ 4.7 سے کرنل net.netfilter.nf_conntrack_helper=0 کے ساتھ آتے ہیں، اس لیے معاون واضح اصول کا انتظار کرتا ہے، مثلاً iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp۔ اگر منتقلی کی کوشش کے دوران توقعات کی فہرست خالی رہے، تو جڑائی جانچنی ہے، ماڈیول نہیں۔
غیر فعال موڈ: سرور کو بتائیں کہ کیا اعلان کرنا ہے
غیر فعال موڈ کو قطعی بنانا آسان ہے کیونکہ سرور کو بتایا جا سکتا ہے کہ 227 جواب میں کیا رکھنا ہے۔ vsftpd میں یہ pasv_address ہے، ساتھ pasv_min_port اور pasv_max_port; ProFTPD MasqueradeAddress اور PassivePorts استعمال کرتا ہے۔ یہ پہلے مقرر کریں، کیونکہ درست اعلان کردہ پتہ اس طرف کچھ بھی دوبارہ لکھنے کی ضرورت ہٹا دیتا ہے۔
پھر ٹھیک وہی پورٹ رینج گیٹ وے سے گزرنے دیں، مثلاً -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT، تاکہ اصول سرور کے اعلان سے میل کھائے۔
دونوں سیٹنگز کو متفق ہونا چاہیے۔ ایسے سرور کو 30000-30100 اعلان کرنے کا کہا جائے جبکہ گیٹ وے 40000-40100 کی اجازت دے، تو وہ کم ترین مددگار طریقے سے ناکام ہوتا ہے: کنٹرول گفتگو صحت مند دکھتی ہے اور ہر ڈیٹا کنکشن مر جاتا ہے۔ کوئی اور چیز ڈیبگ کرنے سے پہلے اعداد کا موازنہ کریں۔
ناکامی کی دو نشانیاں، اور FTPS کیا ہٹاتا ہے
LIST پر لٹکنا سیشن کے پہلے ڈیٹا کنکشن کی طرف اشارہ کرتا ہے، جہاں پتے کا دوبارہ لکھنا اور توقع دونوں کام کریں۔ کام کرنے والے LIST کے بعد RETR پر لٹکنا خود منتقلی کی طرف اشارہ کرتا ہے، یعنی غیر فعال رینج یا ٹنل کا MTU۔ وہ دوسری نشانی پے لوڈ کا مسئلہ نہیں، اور معاون کی سیٹنگز اسے درست نہیں کریں گی۔
TLS پر FTP وہ پے لوڈ ہٹا دیتا ہے جو معاون پڑھتا ہے۔ درمیانی باکس ایسی PORT یا PASV قدر دوبارہ نہیں لکھ سکتا جسے وہ ڈکرپٹ نہیں کر سکتا، اس لیے باقی اختیارات TLS ختم کرنے والا پراکسی، محدود رینج میں قابل رسائی پتہ اعلان کرنے والا سرور، یا کوئی اور منتقلی پروٹوکول ہیں۔
جانچوں کی مختصر ترتیب
علامت سے باہر کی طرف کام کریں۔ تصدیق کریں کہ PWD کامیاب ہوتے وقت LIST ناکام ہوتا ہے، PORT یا 227 پے لوڈ کے اندر کا پتہ پکڑیں، اور پوچھیں کہ کون سا آلہ اس پتے کی ترجمانی کرتا ہے۔ وہاں معاون جوڑیں، ایک منتقلی کے دوران توقعات کی فہرست دیکھیں، پھر سرور پر غیر فعال موڈ درست کریں اور گیٹ وے اصول میں رینج کی عکاسی کریں۔
ڈیٹا راستے کی ناکامی کو بڑی منتقلی کی ناکامی سے الگ رکھیں، کیونکہ وہ مختلف سیٹنگز کی طرف لے جاتی ہیں۔