VPN سائٹ سے آنے والا 403 پراکسی کی ناکامی کیوں نہیں
اصل سے 403، مسترد CONNECT اور 407 چیلنج مختلف حدود کی نشاندہی کرتے ہیں۔ پہلے پراکسی کا اخراجی راستہ براؤزر کے VPN پتے سے موازنہ کریں۔
صارفین VPN بند کرتے ہیں، کسی اندرونی سائٹ پر 403 کا سامنا کرتے ہیں اور بتاتے ہیں کہ پراکسی خراب ہے۔ اس صفحے کو تین الگ چیزیں بنا سکتی ہیں: اصل نے درخواست مسترد کی، فارورڈ پراکسی نے سرنگ کھولنے سے انکار کیا، یا پراکسی نے اپنے اسناد طلب کیے۔ ان میں سے ہر ایک مختلف سوال کا درست جواب ہے، اور انہیں ایک عام ناکامی کے صفحے میں ہموار کرنا آپ کے پاس موجود واحد ثبوت کو تباہ کر دیتا ہے۔ انکار کو اس جزو کے مطابق ترتیب دیں جس نے اسے بنایا، پھر ہر جزو کے اصل میں استعمال ہونے والے نیٹ ورک راستے کا موازنہ کریں۔
403 پیدا کرنے والے جزو کا نام بتائیں
HTTP اسٹیٹس کوڈ اسی فریق کا ہے جس نے اسے بھیجا۔ جب اصل 403 واپس کرتا ہے، تو اس نے درخواست کا تجزیہ کیا ہے اور فیصلہ کیا ہے کہ کال کرنے والے کے پاس وسائل نہ ہو سکیں، یہ اجازت کا جواب ہے، نقل و حمل کا مسئلہ نہیں۔ جب فارورڈ پراکسی CONNECT کو 403 کا جواب دیتی ہے، تو اس نے سرنگ بنانے ہی سے انکار کر دیا ہے اور اوپر کسی سے کبھی رابطہ نہیں ہوا۔ جب یہ 407 کا جواب دیتی ہے، تو یہ اپنے اسناد چاہتی ہے، جن کا اطلاقیہ کے لاگ ان سے کوئی تعلق نہیں۔
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 ان کرداروں کی تعریف کرتا ہے، بشمول پراکسی کے لیے مخصوص چیلنج۔ جسم پڑھنے سے پہلے جواب کی اپنی حیثیت اور کوئی بھی Proxy-Authenticate ہیڈر پڑھیں، کیونکہ دوستانہ HTML غلطی کا صفحہ عام طور پر چھپا دیتا ہے کہ کس جزو نے اسے لکھا۔
CONNECT سرنگ بائٹ ریلے سے کیا چھپاتی ہے
جب پراکسی CONNECT کو 200 واپس کرتی ہے، تو یہ بائٹس ریلے کر رہی ہوتی ہے اور براؤزر اصل کے ساتھ اپنا TLS سیشن رکھتا ہے۔ اس لیے بائٹس ریلے کرنے والی پراکسی اس سیشن کے اندر خفیہ کردہ 403 نہیں پڑھ سکتی، اور یہ کبھی انکار کی مصنف نہیں بنتی۔ سرنگ کھلنے سے پہلے کا انکار بالکل مختلف واقعہ ہے، جو ایک پرت نیچے پیدا ہوتا ہے۔
TLS ختم کرنے والی معکوس پراکسی مختلف مقام پر ہے: یہ TLS حد کی مالک ہے، HTTP کا تجزیہ کرتی ہے اور جوابات کو قانونی طور پر دوبارہ لکھ یا روک سکتی ہے۔ یہ صلاحیت ترتیب کا انتخاب ہے، عام طور پر پراکسی کی خصوصیت نہیں، اور یہ اطلاقیہ کی رسائی پالیسی کو نظرانداز کرنے کا اختیار نہیں دیتی۔ جواب پڑھنا ایک صلاحیت ہے؛ کال کرنے والا کیا دیکھ سکتا ہے یہ طے کرنا اصل کا کام ہی رہتا ہے۔
عملی نتیجہ یہ ہے کہ 403 کی تشریح سے پہلے آپ کو معلوم ہونا چاہیے کہ آپ تین شکلوں میں سے کون سی چلا رہے ہیں۔ اسٹریم پراکسی میں HTTP معائنہ کے قواعد شامل کرنے سے اسے بصارت نہیں ملتی، اور بائٹ ریلے سے اصل کے انکار کی وضاحت کی توقع آپ کو غلط لاگ کی طرف بھیجے گی۔
پراکسی کے اخراجی راستے کا براؤزر کے سرنگ پتے سے موازنہ کریں
VPN سے منسلک براؤزر الگ پراکسی سرور کو خودبخود اس سرنگ پر منتقل نہیں کرتا۔ اصل پراکسی کا اخراجی پتہ دیکھتا ہے، اور اگر پراکسی اب بھی مقامی ڈیفالٹ راستے سے باہر جاتی ہے، تو محفوظ سائٹ ایسا پتہ دیکھتی ہے جس پر کبھی بھروسہ کرنے کے لیے ترتیب نہیں دیا گیا۔ لیپ ٹاپ کا اندرونی VPN پتہ اس اصل کے لیے نظر نہیں آتا۔ یہی سب سے عام وجہ ہے کہ کام کرنے والی سرنگ بھی ایسی سائٹ سے 403 دیتی ہے جو باقی سب کے ساتھ درست برتاؤ کرتی ہے۔
پتے گڈمڈ نہ ہوں اس لیے دونوں راستے الگ الگ جانچیں۔
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateپہلی درخواست دکھاتی ہے کہ اصل آپ کے اپنے پتے کو کیا جواب دیتا ہے، دوسری دکھاتی ہے کہ پراکسی کے پتے کو کیا جواب دیتا ہے۔ ملتی جلتی 403 جوڑی اصل کے اجازت کے قواعد کی طرف اشارہ کرتی ہے؛ 200 کے بعد 403 آنا پراکسی راستے کی طرف اشارہ کرتا ہے۔ VPN پول شامل ہے فرض کرنے کے بجائے اصل کے مالک سے پوچھیں کہ قواعد کا مجموعہ واقعی کون سے ماخذ پتے قبول کرتا ہے۔
ہر حد کو اسے الگ کرنے والی درخواست سے جانچیں
پراکسی پرت کو اطلاقیہ کی وجوہات سے انکار نہ کر سکنے والی چیز مانگ کر الگ کریں۔ اس ہوسٹ کی طرف CONNECT جس تک پراکسی کو پہنچنے کی اجازت ہے، آؤٹ پٹ پھینک کر، آپ کو بتاتا ہے کہ سرنگ میں داخلہ بہرحال کام کرتا ہے یا نہیں۔
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
اگر یہ CONNECT کے لیے 200 اور پھر TLS مصافحہ چھاپتا ہے، تو پراکسی داخلہ ٹھیک ہے اور بعد والا 403 اصل سے آیا۔ اگر یہ 407 چھاپتا ہے، تو --proxy-user کے ساتھ پراکسی اسناد دیں اور سائٹ کے بارے میں کوئی نتیجہ نکالنے سے پہلے دہرائیں۔ اگر یہ CONNECT لائن پر 403 چھاپتا ہے، تو جانچنے والی حد پراکسی کی اپنی اجازت فہرست ہے، اور اطلاقیہ اس میں شامل نہیں۔
اسناد کو شیل تاریخ اور چسپاں شدہ نقول سے دور رکھیں۔ کمانڈ لائن میں ٹائپ کردہ پراکسی پاس ورڈ دیگر مقامی صارفین کو نظر آتا ہے، اور اسناد کے ساتھ پکڑا گیا CONNECT نشان کسی بھی نشان سے بدتر ہے۔
صفحہ دوبارہ لکھنے کے بجائے فیصلے کو پڑھنے کے قابل رکھیں
یہ جاننے کے بعد کہ کس جزو نے انکار کیا، اس جواب کو محفوظ رکھیں۔ جو معکوس پراکسی اصل کے 403 کو 504 ٹائم آؤٹ کے طور پر دوبارہ لیبل کرتی ہے، یا اسے کامیابی کے صفحے سے بدل دیتی ہے، وہ اجازت کے فیصلے کو دستیابی کی کہانی کے پیچھے چھپاتی ہے اور اگلے جواب دہندہ کو غلط ٹیم کی طرف بھیجتی ہے۔ حسب ضرورت غلطی کے صفحات تب ٹھیک ہوتے ہیں جب وہ حیثیت رکھیں اور سیاق شامل کریں۔
کیچنگ بھی اسی دیکھ بھال کی حقدار ہے۔ RFC 9111 طے کرتا ہے کہ مشترکہ کیچ جوابات کو کیسے دوبارہ استعمال کر سکتے ہیں، اور ایک کال کرنے والے کے لیے پیدا کردہ انکار دوسرے کو اجازت کی طرح نہیں دیا جانا چاہیے۔ اگر انکار کے جوابات بہرحال محفوظ کیے جائیں، تو انہیں نجی اور محدود رکھیں، اور صرف اوپر کی ٹریفک کم کرنے کے لیے کبھی عوامی تازگی کا قاعدہ شامل نہ کریں۔
ایک تحریری فیصلے کے ساتھ اختتام کریں جو جزو، اس کی پیدا کردہ حیثیت اور وہ ماخذ پتہ بتائے جو اصل نے دیکھا۔ درست درخواست، نافذ پراکسی ترتیبات اور وقت درج کریں، تاکہ اگلی رپورٹ کو یادداشت سے دوبارہ نکالنے کے بجائے انہی شواہد سے ملایا جا سکے۔ وہ ریکارڈ اگلی رپورٹ کا جواب سیکنڈوں میں دیتا ہے اور اسی 403 کو دوبارہ VPN رکاوٹ کے طور پر تشخیص ہونے سے روکتا ہے۔