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, і на неї варто посилатися, коли ви пишете звіт.