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, и си струва да я цитирате, когато пишете доклада.