Git 403 przy połączonym VPN: znajdź odpowiadającego
403 to odpowiedź, a nie wyrok w sprawie VPN. Ustal, który komponent odmówił, a potem porównuj jedną zmienną naraz między sieciami i zapisuj, co się zmieniło.
Działa w sieci Wi-Fi w biurze, a zawodzi na hotspocie telefonu, przy czym VPN jest połączony w obu przypadkach. Git zwraca 403, a błąd ma trzy linie. Pokusa polega na uznaniu hotspotu za przyczynę i zmienianiu ustawień sieci, aż coś się ruszy. HTTP 403 oznacza, że serwer zrozumiał żądanie i je odrzucił, więc użytecznym pytaniem jest który serwer, a użytecznym następnym krokiem jest porównanie zmieniające jedną rzecz naraz.
Przeczytaj status przed siecią
403 to nie nieudane wyszukiwanie, przekroczenie czasu TCP ani uzgadnianie TLS, które nigdy się nie zakończyło. To decyzja podjęta przez coś, co przeanalizowało twoje żądanie.
Dopóki nie wiesz, co podjęło tę decyzję, każda zmiana sieci, którą wypróbujesz, jest domysłem z wiarygodną historią.
Kto może odpowiedzieć kodem 403?
Aplikacja repozytorium jest tylko jednym kandydatem. Proxy, brama lub usługa filtrująca może stać przed nią i odpowiedzieć pierwsza, a klient widzi ten sam status tak czy inaczej. Zachowaj status, istotne nagłówki i oczyszczoną treść błędu, a następnie skoreluj je z logami autoryzowanej usługi. Zdalny URL i faktycznie osiągnięty punkt końcowy mogą się też różnić z powodu DNS lub konfiguracji proxy, więc sprawdź skonfigurowany adres i proces wysyłający żądanie.
Jeśli odmowa nigdy nie dotarła do repozytorium, jego logi będą milczeć, a ta cisza jest dowodem.
Porównuj jedną zmienną naraz
Porównanie z hotspotem jest użyteczne, bo zawęża problem, a nie dlatego, że dowodzi przyczyny. Dwie sieci mogą się jednocześnie różnić adresacją, rodziną IP, proxy, negocjacją TLS i polityką wyjścia.
Zmieniaj jedną rzecz na próbę i zapisuj resztę. Poniższa tabela to minimum, które trzymam w notatce, robiąc to:
| 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 |
Jeden wiersz, który różni się między działającym a nieudanym przebiegiem, to miejsce, w które idzie następna godzina.
Obejście to dowód, nie wyjaśnienie
Wymuszenie innej rodziny adresów może zmienić miejsce docelowe, trasę lub wybierany element pośredniczący, więc może zmienić wynik, nie dowodząc, że IPv6 jest niezgodny z repozytorium. Inna wynegocjowana wersja TLS to obserwacja z tej samej kategorii. Żadna z nich nie uzasadnia wyłączania sprawdzania certyfikatów ani osłabiania połączenia. Śledź politykę i logi komponentu, który odmówił, aż do rzeczywistej decyzji, zamiast zatrzymywać się na pierwszej zmianie, która działa.
Obejście, którego nie potrafisz wyjaśnić, zawiedzie ponownie gdzie indziej.
Napisz raport, który zostanie naprawiony
Daj właścicielowi komponentu, który odpowiedział, tę samą operację, dwie ścieżki i komponent, który powiedział nie. Usuń nagłówki autoryzacji, osadzone poświadczenia i szczegóły prywatnego repozytorium, zanim cokolwiek udostępnisz.
Użyteczny raport jest krótki, powtarzalny i nazywa warstwę, a nie objaw.
Sprawdzenie, które wykonuję, po kolei
Potwierdź zdalny URL i rozwiązany punkt końcowy, a następnie przechwyć status i nagłówki z nieudanego przebiegu. Powtórz identyczną operację w drugiej sieci i porównaj oba zapisy.
Następnie zanieś tę różnicę do komponentu, który odpowiedział:
- Konfiguracja proxy na kliencie i w sieci.
- Polityka wyjścia lub filtrowanie przed repozytorium.
- Zakres tokenu lub konta, w tym wygaśnięcie i warunki SSO.
- Uprawnienie repozytorium dla tożsamości, którą reprezentuje token.
Sama semantyka statusu znajduje się w RFC 9110, i warto ją zacytować, pisząc raport.