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, и на неё стоит ссылаться, когда вы пишете отчёт.