Git 403 bei verbundenem VPN: Finden Sie die antwortende Stelle

Im Büro-WLAN funktioniert es, am Handy-Hotspot nicht, in beiden Fällen mit verbundenem VPN. Git liefert 403, und die Fehlermeldung ist drei Zeilen lang. Die Versuchung ist, den Hotspot zur Ursache zu erklären und Netzwerkeinstellungen zu ändern, bis sich etwas bewegt. HTTP 403 bedeutet, dass ein Server die Anfrage verstanden und abgelehnt hat, also lautet die nützliche Frage: welcher Server, und der nützliche nächste Schritt ist ein Vergleich, der jeweils eine Sache ändert.

Erst den Status lesen, dann das Netz

Ein 403 ist kein fehlgeschlagenes Nachschlagen, kein TCP-Timeout und kein unvollständiger TLS-Handshake. Es ist eine Entscheidung, getroffen von etwas, das Ihre Anfrage ausgewertet hat.

Bis Sie wissen, was diese Entscheidung getroffen hat, ist jede Netzwerkänderung, die Sie probieren, eine Vermutung mit einer plausiblen Geschichte.

Wer kann mit 403 antworten?

Die Repository-Anwendung ist nur ein Kandidat. Ein Proxy, ein Gateway oder ein Filterdienst kann davor sitzen und zuerst antworten, und der Client sieht in beiden Fällen denselben Status. Sichern Sie den Status, die relevanten Header und einen bereinigten Fehlerkörper, und gleichen Sie sie dann mit den Logs des autorisierten Dienstes ab. Die entfernte URL und der tatsächlich erreichte Endpunkt können sich auch durch DNS oder Proxy-Konfiguration unterscheiden, prüfen Sie daher die konfigurierte Adresse und den Prozess, der die Anfrage stellt.

Wenn die Ablehnung das Repository nie erreicht hat, schweigen dessen Logs, und dieses Schweigen ist ein Beweis.

Vergleichen Sie eine Variable nach der anderen

Der Hotspot-Vergleich ist nützlich, weil er das Problem einengt, nicht weil er eine Ursache beweist. Zwei Netze können sich gleichzeitig in Adressierung, IP-Familie, Proxy, TLS-Aushandlung und Ausgangsrichtlinie unterscheiden.

Ändern Sie eine Sache pro Versuch und notieren Sie den Rest. Die folgende Tabelle ist das Minimum, das ich dabei in einer Notiz führe:

Eine einzige Zeile, die sich zwischen dem funktionierenden und dem fehlschlagenden Lauf unterscheidet, ist der Ort, an den die nächste Stunde geht.

Ein Workaround ist ein Beweis, keine Erklärung

Eine andere Adressfamilie zu erzwingen kann das Ziel, die Route oder die Zwischenstation ändern, die ausgewählt wird, also kann es das Ergebnis ändern, ohne zu beweisen, dass IPv6 mit dem Repository unvereinbar ist. Eine andere ausgehandelte TLS-Version ist eine Beobachtung derselben Kategorie. Nichts davon rechtfertigt, Zertifikatsprüfungen abzuschalten oder die Verbindung zu schwächen. Folgen Sie der Richtlinie und den Logs der ablehnenden Komponente bis zur tatsächlichen Entscheidung, statt bei der ersten Änderung stehenzubleiben, die funktioniert.

Ein Workaround, den Sie nicht erklären können, wird anderswo wieder scheitern.

Schreiben Sie einen Bericht, der behoben wird

Geben Sie dem Eigentümer der antwortenden Stelle dieselbe Operation, zwei Wege und die Komponente, die Nein gesagt hat. Entfernen Sie Autorisierungs-Header, eingebettete Zugangsdaten und private Repository-Details, bevor Sie etwas teilen.

Der nützliche Bericht ist kurz, reproduzierbar und benennt die Schicht statt das Symptom.

Die Prüfung, die ich der Reihe nach durchführe

Bestätigen Sie die entfernte URL und den aufgelösten Endpunkt, und erfassen Sie dann Status und Header aus einem fehlschlagenden Lauf. Wiederholen Sie dieselbe Operation in einem zweiten Netz und vergleichen Sie die beiden Aufzeichnungen.

Dann bringen Sie diesen Unterschied zu der Komponente, die geantwortet hat:

• Proxy-Konfiguration auf dem Client und im Netz.
• Ausgangsrichtlinie oder Filterung vor dem Repository.
• Token- oder Kontoumfang, einschließlich Ablauf und SSO-Bedingungen.
• Repository-Berechtigung für die Identität, die das Token vertritt.

Die Statussemantik selbst steht in RFC 9110, und sie lohnt sich als Zitat, wenn Sie den Bericht schreiben.