FTP سرور کی راہ میں VPN کا تحفظ کہاں ختم ہوتا ہے
VPN صرف اپنے گیٹ وے تک کا راستہ ڈھکتا ہے، اس کے آگے کا حصہ نہیں۔ سادہ FTP، FTPS اور SFTP کو الگ پہچانیں، پھر ڈیٹا چینل اور دوسرے فریق کی شناخت کی تصدیق کریں۔
VPN ایک راستے کی حفاظت کرتا ہے، اور ہر راستے کا ایک انجام ہوتا ہے۔ جب ٹنل کسی کمپنی کے گیٹ وے پر ختم ہوتا ہے، تو فائل کی منتقلی وہیں سے اپنے پروٹوکول کی فراہم کردہ حفاظت کے تحت جاری رہتی ہے۔ یہی فرق طے کرتا ہے کہ منتقلی شروع سے آخر تک محفوظ ہے یا صرف گیٹ وے تک۔ Connected اشارہ دونوں میں سے کسی کے بارے میں کچھ نہیں بتاتا۔
دو مقامات، دو باقی راستے
ایسا لیپ ٹاپ لیں جو کمپنی کے VPN سے جڑتا ہے اور پھر الگ اندرونی سرور کی طرف FTP سیشن کھولتا ہے۔ ٹنل گیٹ وے پر رک جاتا ہے، اور گیٹ وے سے اس سرور تک کا حصہ اس سے باہر رہتا ہے۔
سادہ FTP صرف اس لیے خفیہ کاری نہیں پاتا کہ اس کے پیکٹ ٹنل سے آئے ہیں۔ اس باقی حصے پر احکام، اسناد اور فائل کا مواد ٹھیک اسی طرح سفر کرتے ہیں جیسے پروٹوکول متعین کرتا ہے، یعنی کھلے طور پر۔ یہ اہم ہے یا نہیں، یہ ٹوپولوجی اور اس پر منحصر ہے کہ اس حصے کی اور کون حفاظت کرتا ہے، اور پتے کو نجی کہنا سوال کا جواب نہیں دیتا۔ یہی استدلال الٹی سمت میں بھی لاگو ہوتا ہے جب سرور کسی کلاؤڈ نیٹ ورک میں ہو جہاں گیٹ وے ایک اور چھلانگ سے پہنچتا ہے۔
VPN کا آخری نقطہ اور FTP سروس ایک ہی مشین پر رکھیں، پھر فکر کرنے کے لیے کوئی اگلا حصہ نہیں رہتا۔ یہ الگ مقام ہے، یہ ثبوت نہیں کہ میزبان کے عمل، فائلیں اور اسناد محفوظ ہیں۔
سادہ FTP، FTPS اور SFTP تین فیصلے ہیں
سادہ FTP پاس ورڈ سمیت کچھ بھی خفیہ نہیں کرتا۔ FTPS، FTP میں TLS شامل کرتا ہے، اس لیے کنٹرول چینل اور بات چیت ہونے پر ڈیٹا چینل محفوظ رہتے ہیں۔ SFTP، SSH کے اندر لے جایا جانے والا الگ پروٹوکول ہے، اور یہ FTPS کی دوسری ہجے نہیں ہے۔
سرور کو یہ انتخاب سپورٹ کرنا چاہیے، کیونکہ کلائنٹ ایسا سامع نہیں بنا سکتا جو موجود نہ ہو۔ SFTP چننے سے صرف FTP چلانے والی سروس SSH آخری نقطہ نہیں بن جاتی، اور بک مارک کا نام بدلنا یا پورٹ بدلنا اس بارے میں کچھ ثابت نہیں کرتا کہ کس پر اتفاق ہوا۔ کلائنٹ کے ساتھ ساتھ سرور کی طرف سے بھی پروٹوکول کی تصدیق کریں۔ فائل مینیجر میں تالا سیشن کے بارے میں دعوی ہے، اس کے پیچھے کے سامع کے بارے میں نہیں۔
| Protocol | Usual port | What it protects | Identity check |
|---|---|---|---|
| FTP | 21 | Nothing on the wire | None beyond the login |
| FTPS | 21 or 990 | Control channel, data channel when required | TLS server certificate |
| SFTP | 22 | The whole session inside SSH | SSH host key |
جب منتقلی اہم ہو تو آخری کالم پڑھیں، کیونکہ وہیں غیر متوقع شناخت کی تبدیلی نظر آتی ہے۔
ڈیٹا کنکشن دوسرا کنکشن ہے
FTP پہلے کنٹرول کنکشن کھولتا ہے اور پھر فہرستوں اور منتقلیوں کے لیے الگ ڈیٹا کنکشن۔ محفوظ لاگ ان ان بعد کے کنکشنوں کے بارے میں کچھ نہیں کہتا، جب تک تعیناتی ان کے لیے بھی حفاظت کا مطالبہ نہ کرے۔
FTPS میں کلائنٹ کسی مخصوص حکم کے ذریعے محفوظ ڈیٹا چینل مانگتا ہے، اور سرور کی پالیسی کھلے متبادل کو مسترد کر سکتی ہے۔ یہ ماننے کی بجائے کہ کلائنٹ کی طے شدہ قدر کافی ہے، تصدیق کریں کہ پالیسی اس کا مطالبہ کرتی ہے۔ غیر فعال موڈ ایک اور پیچیدگی شامل کرتا ہے، کیونکہ سرور ڈیٹا کنکشن کے لیے پتہ اور پورٹ کا اعلان کرتا ہے۔ جو فائر وال یا NAT آلہ اس اعلان کو دوبارہ لکھتا یا روکتا ہے، وہ ایسا سیشن بناتا ہے جو تصدیق سے گزر کر پہلی فہرست پر اٹک جاتا ہے۔
curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'دوسرا حکم دکھاتا ہے کہ کسی بھی فائل کو چھونے سے پہلے سرور کنٹرول چینل پر کیا پیش کرتا ہے۔ تیسرا دکھاتا ہے کہ ڈیٹا کنکشن کبھی قائم ہوا یا نہیں، جو تصدیق کی ناکامی اور غیر فعال موڈ کی ناکامی کے درمیان فرق ہے۔
شناخت کی جانچیں ٹنل سے بچ نکلتی ہیں
FTPS کلائنٹ TLS سرور کی شناخت کی تصدیق کرتا ہے، اور SFTP کلائنٹ SSH میزبان کلید کی تصدیق کرتا ہے۔ دونوں جانچیں فائل منتقلی پروٹوکول کی ہیں، اور VPN ان میں سے کوئی نہیں کرتا۔
یہ علیحدگی اہم ہے جب درمیان میں کوئی سیشن کا معائنہ کرنا چاہے۔ نیٹ ورک آلے کو احکام پڑھنے کی اجازت دینے کے لیے TLS بند کرنا حفاظتی ماڈل کو مکمل کرنے کی بجائے بدل دیتا ہے، اور ٹنل اٹھنے کی وجہ سے غیر واضح میزبان کلید قبول کرنے پر بھی یہی بات لاگو ہوتی ہے۔ مطلوبہ اعتماد کی ترتیب رکھیں اور درست مواد آپریٹر سے حاصل کریں۔ جو ٹنل تصدیق کرتا ہے وہ اپنے دور کے سرے پر موجود سرور کے بارے میں کچھ نہیں کہتا۔
ان پروٹوکولز کے لیے نجی کلید اور سرٹیفکیٹ کا مواد VPN اسناد سے الگ، ایک اور تیسرا راز ہے۔
لکھیں کہ آپ نے واقعی کیا تصدیق کیا
ایسی بے ضرر فائل چنیں جسے ہٹانے کی آپ کو اجازت ہے، اور کوشش کے بارے میں چار حقائق لکھیں: کون سا پروٹوکول چلا، دوسرے فریق کی کون سی شناخت جانچی گئی، کون سا راستہ مطلوب تھا، اور منتقلی مکمل ہوئی یا نہیں۔
lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]ڈائریکٹری فہرست، ٹنل میں لاگ ان اور مکمل شدہ منتقلی تین الگ مشاہدے ہیں، اور صرف آخری بتاتا ہے کہ راستہ فائلوں کے لیے کام کرتا ہے۔ اگر ڈیزائن باقی چھلانگ پر رازداری کے لیے صرف VPN پر بھروسہ کرتا ہے، تو اسے اسی فیصلے کے طور پر لکھیں جو وہ ہے۔ چھلانگ اور اس کے اعتماد کے مفروضے کا نام لینے والا قبولیت نوٹ منسلک کلائنٹ کے اسکرین شاٹ سے زیادہ قیمتی ہے۔