VPN منسلک ہے مگر مخلوط مواد اب بھی مسدود ہے: کیا درست کرنا ہے
مسدود URL کو اس بنیاد پر ترتیب دیں کہ اسے کس نے بنایا، حوالہ درست کریں یا اسے میزبان کے مالک کو سونپیں، پھر براؤزر کنسول سے اصلاح کی تصدیق کریں۔
آدھا صفحہ رینڈر ہوتا ہے، ایک اسٹائل شیٹ نیٹ ورک پینل میں خاکستری رہتی ہے، اور VPN کلائنٹ اب بھی صحت مند ٹنل کی اطلاع دیتا ہے۔ تینوں مشاہدے بیک وقت درست ہیں، کیونکہ براؤزر نے صفحے کی بنائی ہوئی درخواست کا فیصلہ کیا اور ٹنل کا اس فیصلے میں کوئی ووٹ نہ تھا۔ معاملہ بند کرنے والی چیز فیصلہ ہے نہ کہ کوئی سیٹنگ: حوالہ درست کریں، اسے میزبان کے مالک تک بڑھائیں، یا انحصار چھوڑ دیں۔ ان میں سے ہر آپشن کا ایک سستا امتحان ہے، اور غلط چننا ایک سپورٹ چکر ضائع کرتا ہے۔
ٹنل ذیلی وسیلہ کیوں نہیں ڈھانپ سکتا
مخلوط مواد کا آغاز ایک HTTPS دستاویز سے ہوتا ہے جو سادہ HTTP پر ذیلی وسیلہ طلب کرتی ہے۔ ہر URL کا فیصلہ اس کی اپنی اسکیم پر ہوتا ہے، اس لیے والدین دستاویز کا تحفظ کبھی بچہ درخواست تک نہیں پھیلتا۔ براؤزر کے نیچے شامل کردہ خفیہ کاری وہ بدلتی ہے جو تار پر گزرتا ہے، نہ کہ وہ http:// جو مارک اپ نے طلب کیا۔
موجودہ براؤزر ان درخواستوں کو دو گروہوں میں تقسیم کرتے ہیں اور مختلف طریقے سے برتاؤ کرتے ہیں۔ اسکرپٹس، اسٹائل شیٹس، iframe اور fetch، XMLHttpRequest یا WebSocket کے ذریعے کالز فوراً مسترد ہو جاتی ہیں، بغیر کسی پیشگی اپ گریڈ کوشش کے۔ تصاویر، آڈیو اور ویڈیو https:// میں دوبارہ لکھی جاتی ہیں اور پھر طلب کی جاتی ہیں، اور لوڈنگ اس وقت ترک ہو جاتی ہے جب وہ محفوظ حصول ناکام ہو۔ ایسے ذیلی وسیلہ کا URL جس کا میزبان خالی IP پتہ ہو اپ گریڈ سے مستثنیٰ ہے، اس لیے IP میزبان پر HTTP تصویر خاموشی سے درست ہونے کے بجائے مسدود رہتی ہے۔ یہ تقسیم، بشمول اس استثنا کے جو اپ گریڈ ہو سکنے والے جانب ہے، درج ذیل میں دستاویزی ہے: Mozilla کی مخلوط مواد کی رہنما میں۔ Chrome محفوظ صفحے سے شروع ہونے والی غیر محفوظ ڈاؤن لوڈز پر بھی ایسی ہی نفی لاگو کرتا ہے، اسی لیے PDF لنک مر سکتا ہے جبکہ ارد گرد کا صفحہ سلامت دکھتا ہے۔
پس خاکستری سطر اس بات کا ثبوت ہے کہ کنٹرول کام کر رہا ہے، نہ کہ ٹنل نے سادہ متن خارج کیا۔ سطر کو ایک حوالے کی طرف اشارہ کرنے والی دریافت سمجھیں، پورے صفحے کی نہیں۔
طے کریں کہ غیر محفوظ حوالہ کس کا ہے
کچھ بھی بدلنے سے پہلے مسئلہ زدہ URL کو اس جگہ کے مطابق ترتیب دیں جہاں وہ پیدا ہوتا ہے۔ یہی جواب طے کرتا ہے کہ آپ آج اصلاح جاری کر سکتے ہیں، کوئی فراہم کنندہ ایک جاری کرے گا، یا انحصار کو صفحہ چھوڑنا ہو گا۔ اسے نیٹ ورک پینل کے Initiator کالم میں پڑھیں، کیونکہ اسکرین پر مارک اپ اکثر رن ٹائم میں جوڑا جاتا ہے۔
| URL کہاں سے آتا ہے | اسے کون درست کر سکتا ہے | پہلا قدم |
|---|---|---|
| آپ کے تعینات کردہ ٹیمپلیٹ یا جز میں سخت کوڈ شدہ | آپ | اسے https:// شکل سے بدلیں اور پھر کیش صاف کریں |
| ٹیگ مینیجر یا وینڈر بنڈل کی طرف سے شامل کردہ | فراہم کنندہ، آپ کے ٹکٹ کے ساتھ | درست URL، درخواست کی قسم اور کنسول لائن بھیجیں |
| صرف پورٹ 80 پر TLS سننے والے کے بغیر پیش کیا جاتا ہے | میزبان کا مالک | TLS طلب کریں، اپنی کنٹرول کی کوئی چیز اس کے آگے رکھیں، یا اسے چھوڑ دیں |
جب میزبان پہلے ہی 443 پر جواب دے رہا ہو اور صرف حوالہ http کہے، تو اصلاح مقامی ہے: حوالہ بدلیں، صفحے کا کیش صاف کریں اور تصدیق کریں کہ سطر https ہو گئی ہے۔ ایسا میزبان جو صرف پورٹ 80 پر سنتا ہو ترمیم سے موافق نہیں بنایا جا سکتا، اس لیے وسیلہ منتقل ہو جاتا ہے، اس کے آگے آپ کی کنٹرول کی چیز رکھ دی جاتی ہے، یا وہ غائب ہو جاتا ہے۔ ٹیگ مینیجر کا شامل کردہ URL تب بھی ظاہر ہوتا رہتا ہے جب آپ کا اپنا ٹیمپلیٹ صاف ہو، اور وہ معاملہ ایسے ٹکٹ سے تعلق رکھتا ہے جس کے ساتھ درست URL اور کنسول لائن منسلک ہوں۔ عملے کو غیر محفوظ مواد کی اجازت دینے کا کہنا ان میں سے کوئی آپشن نہیں، کیونکہ یہ اس براؤزر پروفائل کی ہر وزٹ کی جانے والی سائٹ کے لیے جانچ بند کر دیتا ہے۔
براؤزر سیٹنگ کی بجائے حوالہ درست کریں
ناکام بہاؤ کو نیٹ ورک لاگ محفوظ رکھتے ہوئے دوبارہ لوڈ کریں اور پینل کو اس میزبان کے مطابق فلٹر کریں جس پر شک ہے۔ کنسول URL اور ہدایت کا نام لیتا ہے، جو طے کرتا ہے کہ درخواست مسترد ہوئی یا اپ گریڈ، ٹیمپلیٹ چھونے سے پہلے۔
curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.jsدو معاون کنٹرول جاننے کے قابل ہیں اور کوئی بھی اصلاح کا متبادل نہیں۔ Content-Security-Policy ہیڈر جس میں upgrade-insecure-requests براؤزر کو صفحہ چھوڑنے سے پہلے http ذیلی وسائل کے URL دوبارہ لکھنے پر مجبور کرتا ہے، جو ان پرانے حوالوں کو پکڑتا ہے جو آپ نے ابھی نہیں ڈھونڈے۔ دوبارہ لکھی گئی درخواست تب بھی ناکام ہوتی ہے جب ہدف میزبان HTTPS پیش نہ کرے، اس لیے ہیڈر صرف یہ بدلتا ہے کہ براؤزر کون سا URL آزماتا ہے۔ HSTS ہر میزبان کے لیے لاگو ہوتا ہے، یعنی آپ کے اپنے ڈومین کی پالیسی ایسے فریق ثالث CDN کے لیے کچھ نہیں کرتی جس نے کبھی یہ ہیڈر نہیں بھیجا۔ ٹیمپلیٹ میں تبدیلی کے بعد صفحے کا کیش صاف کریں اور رینڈر شدہ HTML میں پرانا میزبان نام تلاش کریں، کیونکہ وہی URL کسی جز، ترجمہ کی سٹرنگ یا ڈیٹا بیس فیلڈ کے ذریعے بھی آ سکتا ہے۔
ری ڈائریکٹ بھی ٹریک کریں، کیونکہ https:// سے شروع ہونے والا سلسلہ http:// مقام پر اتر سکتا ہے اور براؤزر آخری چھلانگ کا فیصلہ کرتا ہے۔ دوسری کمانڈ کی -L شکل اوپر والی وہ مؤثر URL آپ کے لیے پرنٹ کرتی ہے۔ اگر آخری چھلانگ خالص http ہو، تو حوالہ اب بھی غلط ہے چاہے آپ کا ترمیم کردہ لنک ٹھیک لگتا ہو۔
صفحے کی تصدیق کنسول اور نیٹ ورک پینل سے کریں
کیش بند کر کے دوبارہ لوڈ کریں اور بہاؤ دوبارہ چلیں، بشمول وہ بٹن جو طلب پر مواد لوڈ کرتے ہیں۔ صفحے کی پہلی لوڈنگ سست ویجٹ، نقشے کی ٹائلیں اور پلیئر اسکرپٹس چھپاتی ہے جو صرف کلک کے بعد ظاہر ہوتے ہیں۔ کنسول میں مخلوط مواد کا کوئی اندراج نہیں ہونا چاہیے اور ہر چھوئی گئی سطر https دکھانی چاہیے۔ ٹکٹ بند کرنے سے پہلے کنسول اور درخواست کی سطر محفوظ کریں، کیونکہ اگلی تعیناتی کے بعد وہ حالت دوبارہ بنانا مشکل ہے۔
جب وسیلہ کسی اور کا ہو، چار چیزیں بھیجیں: درست URL، درخواست کی قسم، کنسول کا متن اور وہ صفحہ جہاں یہ ظاہر ہوتا ہے۔ ٹکٹ میں چپکانے والی ہر چیز سے سیشن شناخت کنندگان چھپائیں۔ وہ رپورٹ جو صرف یہ کہے کہ تصاویر خراب ہیں مالک کو تلاش کے لیے کچھ نہیں دیتی۔
ٹنل اپنا کام جاری رکھتا ہے جبکہ اصلاح اس حوالے میں ہوتی ہے جس نے درخواست پیدا کی۔ تعیناتی کے بعد ٹیمپلیٹ اور وینڈر بنڈل میں میزبان نام ایک بار پھر تلاش کریں، اور معاملہ صرف اس وقت بند کریں جب کنسول میں کوئی مسدود مخلوط مواد کا اندراج باقی نہ ہو۔