페이지는 열리지만 VPN에서 업로드가 멈춘다: 어느 원인이 이기는가

페이지는 열리고 VPN은 연결됐다고 알리며 파일 업로드는 매번 같은 지점에서 멈춘다. 이 설명에는 패킷 크기 문제, 이름 해석 문제, 애플리케이션 한도, 그리고 계속 재설정되는 터널이라는 네 가지 원인이 들어맞는다. 각각은 다른 관찰로 확인하거나 배제할 수 있으므로, 결정은 원인을 추측하는 것이 아니라 올바른 시험을 고르는 일이다.

네 후보와 하나의 모양

도구를 열기 전에 목록의 대부분이 걸러지므로 먼저 실패의 모양을 보라. 일정한 크기에서 생기는 정체는 반증될 때까지 크기 문제다. 무작위 지점에서 생기는 정체는 손실이나 안정성 문제다. 연결이 열리기 전의 실패는 이름 문제다.

네 번째 후보는 애플리케이션이다. 업로드 한도, 요청 시간 제한, 프록시의 본문 크기 상한은 브라우저에서는 네트워크 장애처럼 보이는 실패를 만들며, 보통 멈춤이 아니라 거부로 나타난다.

무엇이든 시험하기 전에 관찰된 모양을 적어 두라. "매번 거의 같은 바이트 수에서, 터널이 올라간 채로 멈춘다"는 "업로드가 안 된다"보다 훨씬 강한 출발점이다.

그다음 시험하는 동안 경로를 고정하라. 출구, 프로토콜, 서버를 동시에 바꾸면 어느 것에도 돌릴 수 없는 결과가 나온다. 실행마다 변수 하나, 그리고 적어 두라.

정책을 건드리기 전에 크기를 이분하라

가장 저렴한 판별법은 숫자 하나를 바꾸는 시험이다. 목적지로 크기를 늘려 가며 단편화 금지 ping을 보내고, 통제하는 파일을 같은 서비스에 업로드한 뒤 각각 어디서 멈추는지 비교하라.

ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/upload

첫 명령은 전체 크기 패킷이 경로를 지나는지 알려 준다. MTU가 1500바이트이면 단편화되지 않는 가장 큰 ICMP 페이로드는 1472바이트이고, 터널은 안쪽 패킷이 시작되기 전에 그 예산에서 더 가져간다. 두 번째는 애플리케이션 수준 전송의 크기와 소요 시간을 주며, 실제로 중요한 숫자는 이것이다.

둘을 함께 읽어라. 임계값을 넘으면 실패하는 시험과 같은 임계값 근처에서 멈추는 업로드는 일관된 이야기다. 시험이 모두 성공하는데 업로드가 경로가 분명히 나르는 바이트 수에서 멈춘다면 애플리케이션이나 서버를 가리키며, MTU를 아무리 손봐도 바뀌지 않는다. 그 부정적 결과는 긍정적 결과만큼 값어치가 있다. 조사에서 가장 비싼 가지를 잘라 낸다.

그다음 전송 중 안정성을 확인하라. 큰 업로드 중간에 키를 갱신하는 터널은 크기 의존처럼 보이지만 그렇지 않은 실패를 만들므로, 가동 시간 값을 읽는 것이 이를 확인하는 가장 저렴한 방법이다.

수리와 임시 우회 중에서 선택하라

증거가 크기를 가리킨다면 정직한 답 두 개와 부정직한 답 하나가 있다. 정직한 답은 필요한 ICMP 피드백을 허용해 경로 MTU 탐색을 복원하거나, 알린 세그먼트 크기를 제한해 상대가 더 작은 세그먼트를 보내게 하는 것이다. 부정직한 답은 인터페이스 MTU를 포럼에서 복사한 값으로 낮추고 무엇이 바뀌었는지 전혀 확인하지 않는 것이다.

선택은 무엇을 통제하느냐에 달려 있다. 직접 운영하는 네트워크에서는 모든 프로토콜에서 기제가 계속 작동하므로 ICMP 메시지를 허용하는 것이 더 깔끔한 수정이다. 통제하지 않는 경로에서는 제한이 현실적인 선택이며, 서버 전체가 아니라 좁게 적용해야 한다.

증거가 애플리케이션을 가리킨다면 애플리케이션이나 그 프록시 설정을 고쳐라. 413 응답과 멈춘 연결은 서로 다른 실패이며, 후자는 보통 자체 한도가 있는 프록시를 포함한 사슬 어딘가의 시간 초과다.

어느 쪽이든 원래 값을 보관하고 되돌린 뒤 다시 시험하라. 성공한 전송과 동시에 일어난 변경은 그것이 원인이라는 증거가 아니며, 되돌릴 수 있는 능력이 진단과 우연을 가른다.

다음 사건까지 살아남도록 결정을 기록하라

관찰된 실패의 모양, 시험 결과, 한 변경, 재시험 결과라는 네 가지 사실이면 충분하다. 그것으로 다음 사람은 같은 문제인지 같은 증상을 가진 새 문제인지 판단할 수 있다.

MTU 발견은 특정 링크에 국한되므로 경로 맥락도 적어 두라. 집에서는 되고 호텔에서는 실패하는 노트북에는 두 경로가 있으며, 한쪽에 적용한 수정은 다른 쪽에 대해 아무 말도 하지 않는다.

마지막으로 "VPN이 업로드를 망쳤다"는 요약에 맞서라. 터널은 성공한 경우에도 실패한 경우에도 있었고, 달라진 것은 경로가 날라야 했던 패킷의 크기 또는 전송을 멈춘 지점이다. 실제 기제를 이름 붙이는 것이 이 기록을 쓸모 있게 만든다.