육십 초 TLS 시간 초과: 어느 쪽이 실제로 멈췄나?

클라이언트는 육십 초 뒤에 키 협상에 관한 메시지와 함께 포기하고, 노트북은 그 이유에 대해 아무 의견도 내지 않습니다. 그 문장은 클라이언트의 인내를 설명할 뿐 서버의 행동을 설명하지 않습니다. 서로 아주 다른 세 가지 상황이 이를 만듭니다. 패킷이 올바른 서비스에 도달하지 못한 경우, 서비스가 아무것도 기록하기 전에 패킷을 버린 경우, 서비스가 패킷을 거부하고 클라이언트가 볼 수 없는 곳에서 그것을 알린 경우입니다. 양쪽 끝에서 시도 하나를 대조하는 것만이 이들을 구분합니다.

시도 하나에 검색할 수 있는 정체성을 부여하세요

시작 시각과 시간대, 프로필 이름, 클라이언트가 실제로 해석한 목적지, 포트, 연결이 UDP인지 TCP인지를 적어 두세요. 프로필에 원격 항목이 여러 개 있으면 그 시도가 어느 것을 골랐는지 기록하세요. 재시도가 읽고 있는 파일을 바꾸지 않은 채 다음 항목으로 넘어갔을 수 있기 때문입니다.

종단점은 기억하는 다운로드가 아니라 활성 로그에서 가져오세요. 사설 주소를 가리키는 프로필은 완전히 유효하며, 그곳으로 라우팅할 수 없는 네트워크에서는 완전히 쓸모가 없습니다. 그 상황은 꺼진 서버와 똑같이 보입니다.

그다음 운영자에게 의도한 인스턴스에서 같은 시간대의 로그를 요청하세요. 시계 차이는 흔해서 몇 분의 차이만으로도 일치하는 이벤트가 없는 것처럼 보일 수 있으므로, 이벤트가 없었다고 결론 내리지 말고 차이를 기록하세요.

네 가지 관찰, 네 가지 서로 다른 다음 단계

서버가 무엇을 기록하느냐가 갈래를 정합니다. 시도가 전혀 없다면 주소 지정, 전송 또는 서비스로 가는 경로를 가리킵니다. 평범한 교환 전에 사라지는 들어오는 패킷은 실제 서비스의 제어 채널 요구 사항을 가리킵니다. 이름 붙은 거부는 그것이 지목하는 객체를 가리킵니다. 서버를 떠나지만 클라이언트에 절대 도달하지 않는 응답은 귀환 경로를 가리킵니다.

빈 애플리케이션 로그는 보기보다 약한 증거입니다. 로깅은 교환의 특정 지점에서 시작되며, 그 지점 전에 버려진 패킷은 읽고 있는 파일에 흔적을 남기지 않습니다. 허용되는 곳에서는 운영자가 서비스와 네트워크 관찰을 통해 무언가 도착했는지 확인할 수 있습니다.

메모에서 네 가지 결과를 따로 보관하세요. 유혹은 이것들을 “서버가 응답하지 않음”으로 합치는 것이고, 진짜 문제가 방화벽 규칙일 때 사람들을 암호 방식 변경으로 보내는 말이 바로 그것입니다. 시간 초과라는 단어만 기록한 메모는 방금 값을 치른 구분을 버린 것입니다.

증거가 지목하는 단계를 고치세요

완료된 TCP 연결은 무언가가 소켓을 받아들였다는 것만 증명합니다. 수신자가 구성한 OpenVPN 서비스라는 것은 증명하지 않으며, 같은 호스트 이름의 웹 서버는 브라우저에는 완벽하게 응답하면서 터널과는 무관합니다.

서버가 만료된 폐기 목록을 보고한다면, 그것은 클라이언트의 최종 시간 초과보다 훨씬 구체적인 사실이며 수정은 네트워크가 아니라 인증 기관에 속합니다. 양쪽이 제어 채널 보호나 공유 자료에 대해 합의하지 못한다면 비밀번호를 재설정해도 아무것도 바뀌지 않습니다. 어떤 자격 증명이 검사되기 전에 폐기가 일어나기 때문입니다.

증거가 실제로 뒷받침하는 한 가지를 바꾸고, 같은 프로필을 같은 종단점에 다시 시도하세요. 연결이 더 나아간다면 첫 번째 새 이벤트를 보존하세요. 그 이벤트는 새 문제가 아니라 조사의 다음 단계입니다.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

창을 늘리면 실제로 무엇이 바뀌나

육십 초는 클라이언트의 핸드셰이크 창이며, 커뮤니티 클라이언트 참조가 이를 조정하는 옵션을 문서화합니다. 늘리면 클라이언트가 포기하기 전에 더 오래 기다립니다. 없는 서비스가 나타나게 하지도, 거부된 패킷이 받아들여지게 하지도 않습니다.

느린 회선이나 부하가 큰 서버에서는 더 긴 창에 정당한 용도가 있으며, 교환이 일어나지 않는 것이 아니라 느리게 진행된다는 증거가 있을 때 시도할 가치가 있습니다. 먼저 시도하면 같은 진단을 또 일 분 늦추고 타임라인을 읽기 어렵게 만들 뿐입니다. 타임라인이 진행하다 멈추는 교환을 보여 준다면, 창은 도달 가능성이 아니라 부하의 증상입니다.