چرا خطای 403 از یک سایت VPN شکست پروکسی نیست
خطای 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 تشخیص داده شود.