عوامی VPN کنفیگ نے کام کرنا چھوڑ دیا؟ ناکامی کا مرحلہ پڑھیں
ڈاؤن لوڈ شدہ پروفائل ایک دن میں ایک ہوسٹ بیان کرتا ہے۔ دیکھیں کون سی دعویٰ ٹوٹی، دوسرے فریق کا پیش کردہ سرٹیفکیٹ جانچیں، اور تصدیق کو کبھی بند نہ کریں۔
پروفائل منگل کو کام کر رہا تھا، اور جمعہ کو کلائنٹ تیس سیکنڈ گھومتا ہے اور ہار مان لیتا ہے۔ آپ کی مشین پر کچھ نہیں بدلا۔ یہی اصل بات ہے: ڈاؤن لوڈ شدہ کنفیگریشن ایک لمحے میں ایک ہوسٹ بیان کرتی ہے، اور دوسرے سرے کے آپریٹر پر اس بیان کو سچ رکھنے کی کوئی ذمہ داری نہیں۔ لالچ یہ ہے کہ سیکیورٹی سیٹنگز بدلنی شروع کی جائیں جب تک سرنگ دوبارہ اوپر نہ آ جائے۔ یہی رجحان لوگوں کو سرٹیفکیٹ تصدیق بند کیے ہوئے پروفائل چلانے تک لے جاتا ہے، جو سرنگ بالکل نہ ہونے سے بھی بدتر ہے۔
فائل ایک لمحے کو بیان کرتی ہے، معاہدے کو نہیں
کنفیگریشن فائل دعووں کا مجموعہ ہے: یہ ہوسٹ نام اس پورٹ پر اس پروٹوکول کے ساتھ سنتا ہے، اس نام سے ملنے والا سرٹیفکیٹ پیش کرتا ہے، اور یہ اسناد قبول کرتا ہے۔ ان میں سے کوئی بھی سچ رہنا بند ہو جائے تو فائل پرانی ہو جاتی ہے اور اصلاح حد کے آپریٹر کی طرف کی ہے، آپ کی سیٹنگز کی نہیں۔
عوامی نوڈ فہرستیں اپنی فطرت سے یہ واضح کرتی ہیں۔ نوڈ رضاکار چلاتے ہیں، وہ آتے اور جاتے ہیں، پتے دوبارہ استعمال ہوتے ہیں، اور پورٹس ان کے پیچھے والے نیٹ ورک کی طرف سے بلاک کیے جاتے ہیں۔ فہرست ایک اسنیپ شاٹ ہے جو دوبارہ بنایا جاتا ہے، اور آپ کی ڈسک پر موجود نقل پرانے اسنیپ شاٹ کی تصویر ہے۔
تجارتی سروسز آہستہ بدلتی ہیں، مگر کبھی نہیں ایسا نہیں۔ سرٹیفکیٹ اتھارٹیز بدلتی ہیں، سننے والا مشترکہ پتے سے مخصوص پتے پر جاتا ہے، پرانا پروٹوکول ہٹا دیا جاتا ہے اور نئی سائفر فہرست آتی ہے۔ ان میں سے ہر ایک پوشیدہ ہے جب تک آپ کا کلائنٹ جڑنے کی کوشش نہ کرے اور فائل کی توقع سے مختلف جواب نہ پائے۔
کسی سیٹنگ کو چھونے سے پہلے ناکامی کا مرحلہ پڑھیں
خرابی کا پیغام بتاتا ہے کہ کون سی دعویٰ ٹوٹی، اور ہر دعوے کی اصلاح بالکل مختلف ہے۔ ہوسٹ نام کے حل نہ ہونے پر سائفرز بدلنا ایک سہ پہر ضائع کرتا ہے اور کسی کو کچھ نہیں سکھاتا۔
| What happens | The assertion that broke | Supported response |
|---|---|---|
| Name never resolves | The host still exists under that name | Get a current endpoint from the operator |
| TCP connect times out | The listener is on that port and reachable | Check the current published port, then the local network |
| TLS or key exchange fails | The peer presents the expected identity | Compare the certificate, not the cipher list |
| Authentication rejected | The account is still valid | Get credentials reissued or stop using the service |
dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/nullدرمیانی سطر بلاک شدہ راستے کو ٹوٹے ہاتھ ملانے سے الگ کرتی ہے، اور تیسری حقیقت میں پیش کردہ سرٹیفکیٹ کا جاری کنندہ اور تاریخِ اعتبار دکھاتی ہے۔ اگر وہ جاری کنندہ وہی نہیں جو پروفائل نے پن کیا تھا، سرٹیفکیٹ بدل گیا ہے، اور کلائنٹ کی طرف کا کوئی آپشن پرانی پن کو دوبارہ درست نہیں کرے گا۔
سرٹیفکیٹ اور شناخت کی تبدیلیاں خاموش ہوتی ہیں
اکثر ناکامیاں خود اعلان کرتی ہیں۔ شناخت کی تبدیلیاں نہیں، کیونکہ سرٹیفکیٹ کا نام پن کرنے والا کلائنٹ بالکل اچھے نئے سرٹیفکیٹ کو ایسے پیغام کے ساتھ رد کرے گا جسے بہت سے لوگ بگ سمجھتے ہیں۔ سرنگ درست ہے۔ پن پرانی ہے۔
کوئی نتیجہ نکالنے سے پہلے شناخت کے آپشن تلاش کریں:
grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -datesاگر پروفائل میں ایمبیڈ شدہ CA ہے اور آپریٹر نئی اتھارٹی پر منتقل ہو گیا ہے، تو پرانی فائل نئے سرور کی تصدیق نہیں کر سکتی۔ CA بلاک کو آپریٹر کے شائع کردہ بلاک سے بدلنا جائز اصلاح ہے۔ تصدیق کی ہدایت مٹانا نہیں، اور یہ وہی کلیدی دباؤ ہیں، نتیجہ بالکل مختلف۔
آپریٹر کی کسی تبدیلی کے بغیر بھی کلائنٹ اپ گریڈ وہی علامت پیدا کر سکتا ہے۔ جن آپشنز کو خاموشی سے برداشت کیا جاتا تھا وہ اب مسترد ہوتے ہیں، یا پرانا پروٹوکول ہٹا دیا جاتا ہے۔ یہ آپ کے سافٹ ویئر کی مطابقت کی حد ہے، اور سرور کو قصوروار ٹھہرانے سے پہلے اسی کلائنٹ پر دوسرا پروفائل آزمانا بہتر ہے۔
درست متبادل صرف آپریٹر ہی شائع کر سکتا ہے
جب نوڈ غائب ہو جاتا ہے، متبادل اسی ماخذ سے آنا چاہیے جس نے اصل شائع کیا تھا۔ براہ راست پیغام میں آنے والا پروفائل، کیونکہ وہ «وہی سرور نام استعمال کرتا ہے»، کسی نامعلوم فریق کی غیر تصدیق شدہ کنفیگریشن ہے، اور اسے درآمد کرنا اس فریق کو آپ کی روٹنگ پر کنٹرول دے دیتا ہے۔
جانچ سستی ہے۔ شائع شدہ مقام سے موجودہ فائل لائیں، اینڈ پوائنٹ اور پروٹوکول کا فہرست سے موازنہ کریں، اور فائل کے نام پر بھروسے کے بجائے CA مواد کے فنگر پرنٹ کی تصدیق کریں:
curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpnاگر دونوں ہیش صرف خالی جگہوں میں مختلف ہیں تو یہ فارمیٹنگ تبدیلی ہے۔ اگر وہ اینڈ پوائنٹس میں مختلف ہیں تو آپریٹر نے کچھ منتقل کیا ہے اور شائع شدہ فائل ہی اتھارٹی ہے۔ اگر شائع شدہ فائل آپ کے پاس والی سے پرانی ہے تو آپ غالباً کیش دیکھ رہے ہیں، اور پرانا جواب آپ کو غلط سمت بھیجے گا۔
پرانی اندراج کو ہٹائیں اور لکھیں کہ کیا ہوا
کام کرنے والا متبادل تصدیق ہونے کے بعد، پرانی پروفائل کو بیک اپ کے طور پر رکھنے کے بجائے حذف کریں۔ آدھا جڑنے والی پرانی اندراج ایک جال ہے: خلل کے دوران منتخب ہوگی، آہستہ ناکام ہوگی، اور ڈیبگ کرنے والا پہلے دس منٹ غلط فائل پر گزارے گا۔
کنفیگریشن سے باہر مختصر ریکارڈ رکھیں: تاریخ، پرانا اینڈ پوائنٹ، ناکامی کا مرحلہ اور اسے کس نے بدلا۔ عوامی نوڈ بدلتے ہیں، اور چھ ہفتے بعد وہی سوال کسی دوسرے شخص کے ساتھ آتا ہے۔ نوٹس فائل کی ایک سطر سیکنڈوں میں اس کا جواب دیتی ہے۔
اگر ایک نیٹ ورک سے ہر نوڈ اسی طرح ناکام ہوتا ہے اور دوسرے سے کوئی نہیں، تو پروفائل بدلنا بند کریں اور مقامی راستہ دیکھیں۔ کیپٹو پورٹل، فلٹر شدہ پورٹ رینج یا درمیان میں روکنے والا پراکسی غیر متعلقہ فراہم کنندگان میں یکساں غلطیاں پیدا کرے گا، اور یہی نمونہ واحد اشارہ ہے کہ مسئلہ کبھی فائل نہیں تھا۔