WSL2의 Git이 VPN에서 멈춤: 인터페이스 MTU인가 경로인가?

클론이 인증을 마치고 오브젝트 수가 표시된 뒤 몇 분 동안 아무것도 움직이지 않습니다. Windows는 VPN이 연결되었다고 보고하고, 호스트 이름은 확인되며, 같은 머신의 브라우저는 같은 저장소 페이지를 문제없이 가져옵니다. 이 조합은 자격 증명이 아니라 패킷 크기를 가리키며, WSL2에는 자체 MTU를 가진 자체 Linux 인터페이스가 있기 때문에 크기 질문은 두 곳에서 물어야 합니다. 한 숫자는 경로의 Windows 쪽에, 다른 하나는 배포판에 속하며, VPN 어댑터만 읽으면 경로의 절반이 검토되지 않은 채 남습니다.

세 가지 신호가 크기 문제를 다른 원인과 구분한다

첫 번째 신호는 형태로, 연결 설정과 작은 교환은 성공한 뒤 대량 전송이 진행되지 않습니다. 두 번째는 대칭성으로, 같은 저장소와 같은 전송 방식이 실패하는데 같은 경로의 다른 호스트는 작동하거나, 실패가 시간대가 아니라 페이로드 크기에 따라 달라집니다. 세 번째는 침묵으로, 인증 오류도 프록시 거부도 이름 확인 실패도 없이 전송이 끝나지 않을 뿐입니다.

이 세 가지가 함께 패킷 크기 가설을 정당화합니다. DNS 실패, 만료된 토큰, 거부된 SSH 키, CONNECT를 거부하는 프록시는 각자 고유한 오류를 내며, 어느 것도 성공 후의 멈춤처럼 보이지 않습니다. 시험하는 동안 같은 저장소, 전송 방식, 시간대를 유지하는 것이 비교를 정직하게 만듭니다.

결정하기 전에 두 인터페이스를 비교하라

같은 세션에서 Windows 관점과 Linux 관점을 모으고, 어느 인터페이스가 그것을 나르는지 추측하는 대신 저장소 주소를 붙잡으세요. 아래 명령은 먼저 대상을 확인하므로 경로 조회는 클론이 실제로 접속하는 서버를 설명하며, 이는 브라우저가 보여 준 이름과 다를 수 있습니다. VPN이 시도 사이에 인터페이스 메트릭을 바꿀 수 있으므로 두 절반을 가까운 시점에 실행하세요.

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

인터페이스 이름과 경로 선택이 그곳에서만 의미가 있으므로, Linux 절반은 Windows 셸에 출력을 붙여 넣는 대신 배포판 안에서 실행하세요. Windows 셸에서 붙여 넣은 결과는 잘못된 숫자를 큰 확신을 가지고 보고합니다. 무엇이든 바꾸기 전에 양쪽에서 장치, 선택된 경로, MTU를 기록하세요.

숫자가 더 작아야 하는지 결정하라

경로가 나를 수 있는 것보다 큰 인터페이스 MTU는, 경로 MTU 탐색이 바로 그 일을 위해 존재하므로 자동으로 결함이 아닙니다. 탐색이 억제되면 실패 형태가 나타나는데, ICMP 메시지가 도중 어딘가에서 필터링되고, 송신자는 한계를 배우지 못하며, 큰 패킷은 사라지고 작은 패킷만 통과합니다. 이는 경로의 속성이지 Git의 속성이 아닙니다. 작은 파일은 성공하고 큰 파일은 끝나지 않는 연결이 있는 이유도 여기에 있습니다.

증거가 뒷받침한다면 Linux 인터페이스의 일시적 변경이 가장 저렴한 시험입니다. 사용 가능한 경로 크기보다 작은 값을 고르고, 이전 값을 기록하고, 비교가 의미를 가지도록 나머지는 일정하게 유지하세요. 더 작은 값에서 전송이 완료되면 그것은 우연이 아니라 진단입니다.

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

설정이 어디에 살아야 하는지 결정하라

시험에서 세 가지 선택지가 나오며 보통 그중 하나만 적절합니다. 더 작은 값이 전송을 고치고 그 값이 이 네트워크에 정말 필요하다면, 설정에는 배포판의 시작 훅, 플랫폼이 관리하는 네트워크 구성, 또는 문서화된 절차라는 수명 주기 소유자가 필요합니다. 값이 아무것도 고치지 않는다면 되돌리고 전송, 프록시, 인증 질문으로 돌아가세요.

시작 훅의 존재는 사용 중인 Windows와 WSL 버전, 구성된 네트워킹 모드에 달려 있습니다. Windows 네트워크 미러링은 VPN이 배포판과 상호작용하는 방식을 MTU 조정보다 더 중요하게 바꿀 수 있으므로, 그에 대한 우회책을 설계하기 전에 모드를 확인하세요. 한 통신사나 한 VPN 프로필에 맞는 값이 다음을 위한 기본값은 아닙니다.

피해야 할 것은 유혹적인 배치로, 모든 대화형 셸의 시작 파일에 권한 있는 네트워크 명령을 넣거나, 스크립트가 한 줄을 실행할 수 있도록 ip 바이너리 전체에 암호 없는 sudo를 주는 것입니다. 둘 다 진단을 영구적 노출로 바꾸고 원래 문제를 나중에 보기 어렵게 만듭니다.

깨끗한 시작 후 검증하고, 그다음 되돌려라

배포판을 다시 시작할 때까지만 유지되는 변경은 수정이 아닙니다. 배포판을 다시 시작하고 VPN을 다시 연결한 뒤, ping이나 작은 HTTP 요청 같은 대체물이 아니라 원래 Git 작업을 반복하세요. 그다음 새 세션에서 인터페이스가 의도한 값을 지니는지 확인하세요.

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

기록한 원래 값을 변경 옆에 두어 실험을 깨끗하게 되돌릴 수 있게 하고, IPv4 결과는 같은 호스트의 IPv6 연결에 대해 아무것도 말해 주지 않으므로 어느 주소 체계를 시험했는지 적어 두세요. WSL 네트워킹 문서는 수정이 어떤 모습이어야 하는지 결정하는 모드를 설명하며, MTU 숫자 자체는 로컬 측정이지 권장 사항이 아닙니다.