VPN이 연결된 상태의 Git 403: 응답하는 쪽 찾기

사무실 Wi-Fi에서는 되고 휴대전화 핫스폿에서는 안 되는데, 두 경우 모두 VPN이 연결되어 있다. Git이 403을 반환하고 오류는 세 줄이다. 핫스폿을 원인으로 보고 뭔가 움직일 때까지 네트워크 설정을 바꾸고 싶어진다. HTTP 403은 서버가 요청을 이해하고 거부했다는 뜻이므로, 쓸모 있는 질문은 어느 서버인가이고, 쓸모 있는 다음 단계는 한 번에 한 가지만 바꾸는 비교다.

네트워크보다 상태를 먼저 읽어라

403은 조회 실패도, TCP 타임아웃도, 끝나지 않은 TLS 핸드셰이크도 아니다. 그것은 요청을 해석한 무언가가 내린 결정이다.

그 결정을 누가 내렸는지 알기 전까지, 시도하는 모든 네트워크 변경은 그럴듯한 이야기가 붙은 추측이다.

누가 403으로 응답할 수 있는가?

저장소 애플리케이션은 후보 중 하나일 뿐이다. 프록시, 게이트웨이, 필터링 서비스가 그 앞에 앉아 먼저 응답할 수 있고, 클라이언트는 두 경우 모두 같은 상태를 본다. 상태와 관련 헤더, 정제된 오류 본문을 보관한 다음 승인된 서비스의 로그와 대조하라. 원격 URL과 실제로 도달한 엔드포인트도 DNS나 프록시 구성 때문에 다를 수 있으므로, 구성된 주소와 요청을 보내는 프로세스를 확인하라.

거부가 저장소에 도달한 적이 없다면 그 로그는 조용할 것이고, 그 침묵이 증거다.

한 번에 변수 하나만 비교하라

핫스폿 비교가 유용한 것은 문제를 좁히기 때문이지 원인을 증명하기 때문이 아니다. 두 네트워크는 같은 순간에 주소 지정, IP 계열, 프록시, TLS 협상, 송신 정책에서 다를 수 있다.

시도마다 한 가지만 바꾸고 나머지는 기록하라. 아래 표는 내가 이 일을 하면서 메모에 남기는 최소한이다.

되는 실행과 안 되는 실행 사이에서 다른 단 한 줄이 다음 한 시간이 가는 곳이다.

우회는 증거이지 설명이 아니다

다른 주소 계열을 강제하면 목적지, 경로 또는 선택되는 중간 지점이 바뀔 수 있으므로, IPv6가 저장소와 호환되지 않는다는 것을 증명하지 않고도 결과가 바뀔 수 있다. 협상된 TLS 버전이 다른 것도 같은 범주의 관찰이다. 어느 것도 인증서 검사를 끄거나 연결을 약화시키는 근거가 되지 않는다. 처음 되는 변경에서 멈추지 말고 거부한 구성 요소의 정책과 로그를 실제 결정까지 따라가라.

설명할 수 없는 우회는 다른 곳에서 다시 실패할 것이다.

고쳐질 보고서를 써라

응답한 구성 요소의 소유자에게 같은 작업, 두 경로, 거부한 구성 요소를 주어라. 무엇이든 공유하기 전에 인증 헤더, 내장 자격 증명, 비공개 저장소 세부 정보를 제거하라.

유용한 보고서는 짧고 재현 가능하며 증상이 아니라 계층을 지목한다.

내가 순서대로 하는 점검

원격 URL과 해석된 엔드포인트를 확인한 다음, 실패하는 실행에서 상태와 헤더를 캡처하라. 같은 작업을 두 번째 네트워크에서 반복하고 두 기록을 비교하라.

그다음 그 차이를 응답한 구성 요소로 가져가라:

• 클라이언트와 네트워크에서의 프록시 구성.
• 저장소 앞의 송신 정책 또는 필터링.
• 토큰 또는 계정 범위, 만료와 SSO 조건 포함.
• 토큰이 나타내는 신원에 대한 저장소 권한.

상태의 의미 자체는 RFC 9110에 있으며, 보고서를 쓸 때 인용할 가치가 있다.