Git 403 csatlakoztatott VPN mellett: keressük meg a válaszadót

Az irodai Wi-Fi-n működik, a telefon hotspotján nem, mindkét esetben csatlakoztatott VPN mellett. A Git 403-at ad vissza, és a hiba három sor hosszú. A kísértés az, hogy a hotspotot tekintsük oknak, és addig változtassuk a hálózati beállításokat, amíg valami elmozdul. A HTTP 403 azt jelenti, hogy egy kiszolgáló megértette a kérést és elutasította, tehát a hasznos kérdés az, melyik kiszolgáló, a hasznos következő lépés pedig egy olyan összehasonlítás, amely egyszerre egy dolgot változtat.

Előbb a státuszt olvassuk, aztán a hálózatot

A 403 nem sikertelen névfeloldás, nem TCP-időtúllépés, és nem félbemaradt TLS-kézfogás. Ez egy döntés, amelyet valami hozott, ami feldolgozta a kérésünket.

Amíg nem tudjuk, mi hozta ezt a döntést, minden kipróbált hálózati változtatás találgatás egy hihető történettel.

Ki válaszolhat 403-mal?

A tároló alkalmazás csak egy jelölt. Egy proxy, egy átjáró vagy egy szűrőszolgáltatás állhat előtte, és válaszolhat elsőként, a kliens pedig mindkét esetben ugyanazt a státuszt látja. Őrizzük meg a státuszt, a releváns fejléceket és egy megtisztított hibatestet, majd vessük össze őket az engedélyezett szolgáltatás naplóival. A távoli URL és a ténylegesen elért végpont is eltérhet a DNS vagy a proxy konfigurációja miatt, ezért ellenőrizzük a beállított címet és a kérést küldő folyamatot.

Ha az elutasítás soha nem érte el a tárolót, a naplói hallgatni fognak, és ez a hallgatás bizonyíték.

Egyszerre egy változót hasonlítsunk össze

A hotspot-összehasonlítás azért hasznos, mert szűkíti a problémát, nem azért, mert bizonyít egy okot. Két hálózat ugyanabban a pillanatban különbözhet címzésben, IP-családban, proxyban, TLS-tárgyalásban és kimenő forgalmi szabályban.

Kísérletenként egy dolgot változtassunk, a többit jegyezzük fel. Az alábbi táblázat a minimum, amit eközben jegyzetben tartok:

Az az egyetlen sor, amely eltér a működő és a hibázó futás között, az a hely, ahová a következő óra megy.

A kerülőút bizonyíték, nem magyarázat

Egy másik címcsalád kikényszerítése megváltoztathatja az úti célt, az útvonalat vagy a kiválasztott köztes elemet, így megváltoztathatja az eredményt anélkül, hogy bizonyítaná, az IPv6 összeférhetetlen a tárolóval. Egy másik egyeztetett TLS-verzió ugyanebbe a kategóriába tartozó megfigyelés. Egyik sem indokolja a tanúsítvány-ellenőrzések kikapcsolását vagy a kapcsolat gyengítését. Kövessük az elutasító komponens szabályát és naplóit a tényleges döntésig, ahelyett hogy az első működő változtatásnál megállnánk.

A meg nem magyarázható kerülőút máshol újra meg fog bukni.

Írjunk olyan jelentést, amelyet kijavítanak

Adjunk a válaszoló komponens tulajdonosának ugyanazt a műveletet, két útvonalat és az elutasító komponenst. Távolítsuk el az engedélyezési fejléceket, a beágyazott hitelesítő adatokat és a privát tároló részleteit, mielőtt bármit megosztunk.

A hasznos jelentés rövid, reprodukálható, és a réteget nevezi meg a tünet helyett.

Az ellenőrzés, amelyet sorrendben végzek

Erősítsük meg a távoli URL-t és a feloldott végpontot, majd rögzítsük a státuszt és a fejléceket egy hibázó futásból. Ismételjük meg ugyanazt a műveletet egy második hálózaton, és hasonlítsuk össze a két feljegyzést.

Aztán vigyük ezt a különbséget ahhoz a komponenshez, amelyik válaszolt:

• Proxy-beállítás a kliensen és a hálózaton.
• Kimenő forgalmi szabály vagy szűrés a tároló előtt.
• A token vagy fiók hatóköre, beleértve a lejáratot és az SSO-feltételeket.
• A tároló engedélye annak az identitásnak, amelyet a token képvisel.

Maga a státusz szemantikája a RFC 9110-ban található, és érdemes idézni a jelentés írásakor.