VPN منسلک ہونے پر میل جمع کرنا ناکام ہوتا ہے: مرحلہ تلاش کریں

وہ میل جو ساری صبح چلتا رہا، ٹنل کے اوپر آتے ہی رک جاتا ہے، اور پہلا ردِعمل پاس ورڈ دوبارہ لکھنا ہوتا ہے۔ یہ ردِعمل زیادہ مفید سوال چھوڑ دیتا ہے: کیا کلائنٹ سرور تک پہنچا بھی، اور کیا اس حد تک گیا کہ اسناد پیش کر سکے؟ وقت کی حد، سرٹیفکیٹ کی خرابی اور رد کی جوابی شکل تین مختلف ناکامیاں ہیں، اور صرف تیسری کا تعلق اکاؤنٹ سے ہے۔ مراحل کو ترتیب سے دیکھیں، پھر VPN الزام لگانے کا نشانہ نہیں بلکہ جانچنے کے قابل متغیر بن جاتا ہے۔

مرحلہ 1: اسناد کو چھونے سے پہلے ناکامی کی درجہ بندی کریں

وہ خرابی پڑھیں جو ایپلیکیشن نے واقعی پیدا کی، پھر اسے تین ٹوکریوں میں سے ایک میں رکھیں۔ وقت کی حد یا کنکشن ری سیٹ کا مطلب ہے کہ TCP راستہ ناکام ہوا؛ TLS یا سرٹیفکیٹ کی خرابی کا مطلب ہے کہ راستہ چلا اور ہاتھ ملانا نہ ہوا؛ کوڈ کے ساتھ SMTP جواب کا مطلب ہے کہ میل سرور نے جواب دیا اور فیصلہ کیا۔ ہر ٹوکری مختلف ذمہ دار کی طرف اشارہ کرتی ہے۔

ٹوکریوں کو الگ کرنا اس لیے مفید ہے کہ اصلاحات ایک دوسرے کی متضاد ہیں۔ جب سرور بھیجنے والے کو مسترد کرے تو وقت کی حد بڑھانے سے کوئی فائدہ نہیں، اور جب راستہ بند ہو تو پاس ورڈ بدلنے سے کچھ نہیں ہوتا۔ جواب کا کوڈ فہرست میں سب سے قیمتی ثبوت ہے، کیونکہ یہ ثابت کرتا ہے کہ پوری نقل و حمل کی زنجیر چلی اور مسئلہ پالیسی یا شناخت کا ہے۔ دوبارہ کوشش سے پہلے درست متن محفوظ کریں، کسی بھی توسیع شدہ حالت کوڈ سمیت۔

اگر آپ VPN سے باہر ناکامی دوبارہ پیدا نہیں کر سکتے تو یہیں رکیں۔ ایک مشین پر ایک ایپلیکیشن میں نظر آنے والا مسئلہ ابھی نیٹ ورک کا مسئلہ نہیں ہے۔

مرحلہ 2: اختتامی نقطہ اور TLS موڈ کی تصدیق کریں

پیغام جمع کرنا اپنی الگ خدمت ہے، سرور سے سرور تک ریلے کے مترادف نہیں۔ جمع کرانے کے لیے فراہم کنندہ کی دستاویزات سے ہوسٹ نام، پورٹ اور TLS موڈ کی تصدیق کریں، کیونکہ کسی دوسرے میل سیٹ اپ سے مستعار لیا گیا مانوس پورٹ ثبوت نہیں ہے۔ پورٹ 587 سادہ متن کی سلام اور پھر STARTTLS کی توقع کرتا ہے، جبکہ پورٹ 465 پہلے بائٹ ہی سے TLS کی توقع کرتا ہے۔

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

دونوں میں سے غلط جانچ چلانا وہی غلطی ہے جو کلائنٹ دوسرے موڈ کے لیے ترتیب دیے جانے پر کرتا ہے۔ اگر مضمر-TLS جانچ 587 پر رک جائے، یا STARTTLS جانچ 465 پر ناکام ہو، تو پورٹ اور موڈ مطابقت نہیں رکھتے۔ سرٹیفکیٹ کی تصدیق بند کرنے کے بجائے کلائنٹ میں موڈ درست کریں، کیونکہ یہ ترتیب کی خرابی کو غیر تصدیق شدہ کنکشن میں بدل دیتا ہے۔ یہ تقسیم معیاری ہونے کے لیے کافی پرانی ہے: پورٹ 465 پر مضمر TLS وہی ترتیب ہے جو RFC 8314 میں بیان کی گئی ہے۔

یہاں سرٹیفکیٹ کی خرابی رکاوٹ نہیں، معلومات ہے۔ یہ وہ شناخت بتاتی ہے جو سرور نے پیش کی اور وہ شناخت جو کلائنٹ نے توقع کی، اور دونوں کنکشن کمزور کیے بغیر درست کی جا سکتی ہیں۔

مرحلہ 3: اکاؤنٹ بدلے بغیر راستوں کا موازنہ کریں

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

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

مکمل ٹنل وہ ماخذ پتہ بدل دیتا ہے جو فراہم کنندہ دیکھتا ہے، اور کچھ فراہم کنندگان ناواقف ماخذ کے ساتھ ناواقف پاس ورڈ سے زیادہ سختی کرتے ہیں۔ یہ ان کی طرف کا پالیسی فیصلہ ہے، اور یہ گرے لسٹ، رفتار کی حد یا بلاک ہو سکتا ہے۔ ایک فراہم کنندہ سے سب پر عمومی حکم نہ لگائیں، اور یہ مفروضہ نہ رکھیں کہ غائب NAT اصول ہر ناکامی کی وضاحت کرتا ہے۔ curl کا ریکارڈ دکھاتا ہے کہ کون سا مرحلہ ناکام ہوا، چاہے ایپلیکیشن کا اپنا لاگ نہ دکھائے۔

اگر ٹنل کو انٹرنیٹ ٹریفک لے جانا ہے، تو اس کی روٹنگ اور اس کی اخراج پالیسی دونوں کو یہ منزل اجازت دینی چاہیے۔ جو ٹنل صرف نجی راستے لے جاتی ہے وہ میل کنکشن کو مقامی راستے پر چھوڑ دیتی ہے، جو ایک الگ موازنہ ہے۔

مرحلہ 4: ایک بے ضرر پیغام بھیجیں اور جواب درج کریں

ناکام ہونے والا مرحلہ درست کریں، پھر ویب میل صفحے کے بجائے اسی ایپلیکیشن سے ایک بے ضرر پیغام جمع کرائیں۔ آپ ایپلیکیشن کا اپنا بھیجنے کا راستہ جانچ رہے ہیں، اس کی محفوظ ترتیبات اور TLS موڈ سمیت۔ ویب میل سیشن اس بارے میں کچھ ثابت نہیں کرتا۔

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

چیک لسٹ تب مکمل ہوتی ہے جب آپ ناکام مرحلہ، کلائنٹ کا استعمال کردہ پورٹ اور TLS موڈ، پیغام کا طے کردہ راستہ اور سرور کا واپس کیا گیا جواب نام لے سکیں۔ یہ چار حقائق ایک مبہم آؤٹ بکس مسئلے کو ایسی تبدیلی میں بدل دیتے ہیں جس کا کوئی جائزہ لے سکے۔