TCP 리셋은 VPN이 차단되고 있다는 증거가 아니다

클라이언트 로그에 “연결이 재설정됨, 다시 시작하는 중”이 나타나고, 결론이 증거보다 먼저 도착한다. 누군가는 네트워크가 VPN을 차단한다고, 인증서가 잘못됐다고, 특정 국가가 간섭한다고 결정한다. 리셋은 연결을 끝내는 TCP 패킷이며, 로그 줄은 클라이언트가 그것을 하나 받았다는 사실만 기록한다. 보낸 장치도, 보낸 이유도 밝히지 않는다.

리셋은 패킷이지 판결이 아니다

TCP는 리셋 처리를 정의한다. RST 플래그가 있는 세그먼트는 연결을 즉시 끝낸다. 수신자는 협상하지 않고, 재시도하지 않으며, 이유를 묻지 않는다. 리셋을 보고하고 넘어간다.

클라이언트가 아는 것은 그게 전부다. RST는 서버, 프록시, 방화벽, 또는 상태를 잃은 로드 밸런서에서 왔을 수 있다.

출처 규명은 별개의 작업이다. 캡처에 보이는 출발지 주소는 물리적 출처의 증거가 아니며, 그 뒤의 정책 결정에 대해서는 아무것도 말해 주지 않는다. 중간 장치는 주소를 위조할 수 있고, 상태를 가진 장비는 의도가 아니라 시간 초과로 리셋할 수 있다. 리셋을 판결로 취급하면 진실을 밝히는 단계를 건너뛰게 된다.

어떤 연결이 리셋되었는지 확인하라

먼저 활성 프로필이 실제로 TCP를 쓰는지 확인하라. UDP 터널에서의 리셋은 말이 되지 않고, HTTP 프록시의 로그는 VPN 자체와 다른 TCP 구간을 가리킬 수 있다.

목적지, 포트, 시도 시각, 그리고 클라이언트가 도달한 단계를 기록하라.

단계가 가장 유용한 항목이다. TLS 핸드셰이크 중의 리셋은 한 무리의 용의자를 가리키고, 인증 후의 리셋은 다른 무리를 가리킨다. 단계가 없으면 모든 이론이 들어맞는다.

경로의 양쪽 끝을 비교하라

서버를 관리한다면 같은 시도에 대한 서버의 이벤트를 비교하라. 연결을 받아들였는가? 의도적으로 닫았는가? 응답이 한 경계를 떠나 다음 경계에 도달하지 못했는가?

가능하면 클라이언트와 서버 양쪽에서 캡처하라. 클라이언트에서는 보이지만 서버에서는 보이지 않는 리셋은 서버에서 발생하지 않았다.

양방향의 RST 세그먼트를 주의하라:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

통제된 비교로 좁혀라

승인된 두 번째 네트워크를 쓰면 장애가 클라이언트를 따르는지 경로를 따르는지 알 수 있다. 같은 프로필이 다른 곳에서 작동한다면 클라이언트 설정은 대체로 정상이고 변수는 경로다.

그것만으로는 특정 중간 장치를 식별하지 못한다. 범위를 한 경로로 좁힐 뿐이며, 이는 유용하고 정직한 결과다.

“이 경로가 실패한다”와 “이 이름 붙은 주체가 일으켰다”를 구분해 두라. 전자는 검증할 수 있지만, 후자는 보통 단일 클라이언트에서 검증할 수 없다.

신뢰 설정을 바꾸지 않고 수정을 확인하라

TLS 검증을 끄지 말고, 자격 증명을 다시 만들지 말고, 리셋 한 줄만으로 차단 정책을 선언하지 마라. 그런 변경은 모두 시험 중인 시스템을 바꾸어 다음 비교를 무의미하게 만든다.

식별된 구성 요소를 소유자를 통해 고친 뒤, 같은 프로필과 같은 관찰을 반복하라:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

유용한 결과는 더 잘 국소화된 장애이지 더 자신 있는 이야기가 아니다. 프록시를 고친 뒤 리셋이 사라지면 원인이 있는 것이다. 다른 단계로 옮겨 가면 경로에 대해 무언가를 배운 것이다. 어느 쪽이든 증거는 두 번째 사람의 읽기를 견뎌야 한다. 관찰한 것을 적고, 결론 내린 것을 적지 마라.