کیسے معلوم کریں کہ FTP سرور دراصل کون سا پتہ ریکارڈ کرتا ہے

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

یہ مراحل ایک متعین وقتی دورانیے کے ساتھ مجاز تفتیش فرض کرتے ہیں، نہ کہ کسی اور کی منتقلیوں میں جھانکنا۔

1. طے کریں کہ آپ کس کنکشن کے بارے میں پوچھ رہے ہیں

FTP دو کنکشن استعمال کرتا ہے۔ کنٹرول کنکشن احکامات اور جوابات لے جاتا ہے، اور ڈیٹا کنکشن خود فائل لے جاتا ہے۔ لاگ اِن واقعہ پہلے سے تعلق رکھتا ہے، منتقلی کا واقعہ دوسرے سے، اس لیے لاگ میں ایک سیشن دو مختلف نیٹ ورک راستوں کے مشاہدے رکھ سکتا ہے۔ پتے کا خانہ کس واقعہ سے تعلق رکھتا ہے، اس سے نتائج نکالنے سے پہلے لکھ لیں۔

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

2. کنٹرول کنکشن کی پیروی کریں

کلائنٹ کو ڈیبگ آؤٹ پٹ کے ساتھ چلائیں، یا کنیکٹ ہوتے وقت کلائنٹ پر کیپچر لیں، اور وہ ہم منصب نوٹ کریں جس تک وہ واقعی پہنچتا ہے۔ اگر VPN چل رہا ہو اور کلائنٹ اس کے ذریعے روٹ ہو، تو سرور لیپ ٹاپ کے رسائی نیٹ ورک پتے کے بجائے VPN کے اخراج کا پتہ دیکھتا ہے۔

اگر کلائنٹ ٹنل کو نظرانداز کرے تو سرور رسائی کا پتہ دیکھتا ہے اور VPN انٹرفیس کا اپنا پتہ کبھی تار پر ظاہر نہیں ہوتا۔ یہی وجہ ہے کہ لیپ ٹاپ کا ٹنل پتہ عموماً تصویر میں سب سے کم کارآمد قدر ہوتا ہے: یہ صرف ٹنل کے اندر موجود ہوتا ہے۔ کلائنٹ جو ماخذ پیش کرتا ہے اسے کنفیگریشن اسکرین سے پڑھنے کے بجائے ss یا پیکٹ کیپچر سے تصدیق کریں۔

دو احکامات اس کا بیشتر حصہ ڈھانپ لیتے ہیں:

ss -tnp state established "( sport = :21 or dport = :21 )"
tcpdump -ni any tcp port 21

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

3. دیکھیں کہ ڈیٹا کنکشن مطابقت رکھتا ہے یا نہیں

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

لاگ اِن سے مختلف پتے سے ریکارڈ شدہ منتقلی خراب ریکارڈ نہیں بلکہ حقیقی مشاہدہ ہے، اور یہ عموماً راستے کے بارے میں کچھ بتاتی ہے۔

4. آپریٹر سے محدود ریکارڈ طلب کریں

سرور آپریٹر کو وقت کے زون کے ساتھ سیشن کا وقت، اکاؤنٹ، کارروائی اور منزل دیں۔ پوچھیں کہ پتے کا خانہ کس کنکشن نے پیدا کیا، اور کیا کوئی قابلِ اعتماد ثالث اس کا مطلب بدلتا ہے۔

ہر مصنوعات کے اصل کلائنٹ، کنٹرول ہم منصب اور ڈیٹا ہم منصب کو الگ الگ ریکارڈ کرنے کا فرض کرنے کے بجائے اس سرور کا اصل اسکیما پڑھیں، کیونکہ کچھ پورے سیشن کا خلاصہ ایک ہی سطر میں کر دیتے ہیں۔ پروٹوکول بھی واضح رکھیں: SFTP کسی دوسرے پورٹ پر FTP نہیں بلکہ SSH پر مبنی پروٹوکول ہے، اور FTPS FTP میں TLS شامل کرتا ہے، اس لیے لاگ میں خدمت کی شناخت اس پر منحصر ہے کہ آپ نے کون سا تعینات کیا۔

5. منسوب کرنے سے پہلے تصدیق کریں

ایک اخراجی پتہ بہت سے صارفین کی خدمت کر سکتا ہے، اور ایک اکاؤنٹ کئی مجاز ماخذوں سے استعمال ہو سکتا ہے، اس لیے ایک پتہ اور ایک صارف نام ایک ہی اکائی کی نشاندہی نہیں کرتے۔ لاگنگ سرور کی پالیسی ہے: VPN کنکشن کا پیش کردہ ماخذ بدلتا ہے، مگر اکاؤنٹ کا نام، فائل کا نام یا وصول کنندہ خدمت کی کارروائی مٹاتا نہیں۔ صرف وہی منسوب کریں جو ریکارڈ دکھاتا ہے اور باقی کو نامعلوم نشان زد کریں۔ اگر کسی اور کو سمجھانا ہو تو WinSCP کا FTP بیان دو کنکشن کے ماڈل کے لیے مختصر حوالہ ہے۔

دو عام صورتیں بتاتی ہیں کہ یہ کیوں اہم ہے۔ ایک دفتر ہر صارف کو ایک ہی اخراجی پتے سے باہر بھیج سکتا ہے، اس لیے سو افراد لاگ میں ایک ہی قدر پیدا کرتے ہیں۔ اُلٹا بھی اتنا ہی کثرت سے ہوتا ہے: ایک اکاؤنٹ اسی ہفتے گھریلو لائن اور دفتری لائن دونوں سے جڑتا ہے، اور دونوں اندراج ایک ہی شخص کو بیان کرتے ہیں۔