Git 403 با VPN متصل: پاسخ‌دهنده را پیدا کنید
کد 403 یک پاسخ است، نه داوری درباره VPN. مشخص کنید کدام مؤلفه درخواست را رد کرده، سپس هر بار یک متغیر را بین شبکه‌ها مقایسه کنید و آنچه تغییر کرده را ثبت کنید.
در Wi-Fi دفتر کار می‌کند و در هات‌اسپات گوشی کار نمی‌کند، با VPN متصل در هر دو حالت. Git کد 403 برمی‌گرداند و خطا سه خط است. وسوسه این است که هات‌اسپات را علت بدانید و تنظیمات شبکه را تغییر دهید تا چیزی جابه‌جا شود. کد HTTP 403 یعنی سروری درخواست را فهمیده و آن را رد کرده است، پس پرسش سودمند این است که کدام سرور، و گام بعدی سودمند مقایسه‌ای است که هر بار یک چیز را تغییر می‌دهد.
پیش از شبکه، وضعیت را بخوانید
کد 403 نه شکست جست‌وج است، نه پایان مهلت TCP، و نه دست‌دادن TLS که هرگز کامل نشد. این یک تصمیم است که چیزی آن را گرفته که درخواست شما را تجزیه کرده است.
تا زمانی که ندانید چه چیزی آن تصمیم را گرفته، هر تغییر شبکه‌ای که امتحان می‌کنید حدسی است با داستانی باورپذیر.
چه کسی می‌تواند با 403 پاسخ دهد؟
برنامه مخزن فقط یک نامزد است. یک پروکسی، یک درگاه یا یک سرویس فیلتر می‌تواند جلوی آن بنشیند و اول پاسخ دهد، و کارخواه در هر دو حالت همان وضعیت را می‌بیند. وضعیت، سرآیندهای مربوط و بدنه خطای پاک‌سازی‌شده را نگه دارید، سپس آن‌ها را با گزارش‌های سرویس مجاز تطبیق دهید. نشانی URL دور و نقطه پایانی که واقعاً به آن رسیده‌اید هم می‌توانند به دلیل DNS یا پیکربندی پروکسی متفاوت باشند، پس نشانی پیکربندی‌شده و فرایندی که درخواست را می‌فرستد بررسی کنید.
اگر رد شدن هرگز به مخزن نرسیده باشد، گزارش‌های آن ساکت خواهند بود، و همین سکوت یک مدرک است.
هر بار یک متغیر را مقایسه کنید
مقایسه با هات‌اسپات سودمند است چون مسئله را تنگ می‌کند، نه چون علتی را اثبات می‌کند. دو شبکه می‌توانند در یک لحظه در نشانی‌دهی، خانواده IP، پروکسی، مذاکره TLS و سیاست خروج متفاوت باشند.
در هر تلاش یک چیز را تغییر دهید و بقیه را ثبت کنید. جدول زیر کمینه‌ای است که هنگام انجام این کار در یک یادداشت نگه می‌دارم:
| Keep constant | Record when it changes |
|---|---|
| Repository, operation and credentials | Resolved address and IP family |
| Git process and configuration | Proxy use and the responding component |
| Intended VPN profile | Actual route and exit seen by the service |
تنها ردیفی که بین اجرای سالم و اجرای ناموفق متفاوت است، جایی است که ساعت بعدی به آن می‌رود.
راه‌حل موقت یک مدرک است، نه توضیح
تحمیل خانواده نشانی دیگر می‌تواند مقصد، مسیر یا واسطه‌ای را که انتخاب می‌شود تغییر دهد، بنابراین می‌تواند نتیجه را تغییر دهد بدون آنکه اثبات کند IPv6 با مخزن ناسازگار است. نسخه TLS متفاوتی که مذاکره می‌شود مشاهده‌ای در همان دسته است. هیچ‌یک از این دو توجیهی برای خاموش کردن بررسی گواهی‌ها یا تضعیف اتصال نیست. سیاست و گزارش‌های مؤلفه‌ای که رد کرده را تا تصمیم واقعی دنبال کنید، به‌جای آنکه در اولین تغییری که کار می‌کند بایستید.
راه‌حل موقتی که نمی‌توانید توضیح دهید جای دیگری دوباره شکست می‌خورد.
گزارشی بنویسید که درست شود
به مالک مؤلفه‌ای که پاسخ داده همان عملیات، دو مسیر و مؤلفه‌ای را بدهید که نه گفته است. پیش از به اشتراک گذاشتن هر چیز، سرآیندهای مجوز، اعتبارنامه‌های جاسازی‌شده و جزئیات خصوصی مخزن را حذف کنید.
گزارش سودمند کوتاه و تکرارپذیر است و لایه را نام می‌برد، نه نشانه را.
بررسی‌ای که به ترتیب انجام می‌دهم
نشانی URL دور و نقطه پایانی حل‌شده را تأیید کنید، سپس وضعیت و سرآیندها را از یک اجرای ناموفق ثبت کنید. همان عملیات را در شبکه دوم تکرار کنید و دو ثبت را مقایسه کنید.
سپس آن تفاوت را به مؤلفه‌ای ببرید که پاسخ داده است:
- پیکربندی پروکسی روی کارخواه و روی شبکه.
- سیاست خروج یا فیلتر در جلوی مخزن.
- دامنه توکن یا حساب، شامل انقضا و شرایط SSO.
- اجازه مخزن برای هویتی که توکن نمایندگی می‌کند.
خود معناشناسی وضعیت در RFC 9110 آمده است، و ارزش دارد که هنگام نوشتن گزارش به آن استناد کنید.