VPN이 장애보다 더 오래 걸리는 이유

Wi-Fi는 삼십 초 전에 돌아왔는데 VPN은 아직 꺼져 있어서 클라이언트가 고장 난 것처럼 보입니다. 흔히 그것은 자기만의 재시도 일정을 따르고 있을 뿐이고, 그 일정은 네트워크가 방금 돌아왔다는 것을 모릅니다. 그 간극이 전부입니다. 복구 시간은 장애에 클라이언트가 이미 받아들인 대기 시간을 더한 것입니다. 모든 타이머를 낮추는 것이 하나의 대응이고, 어떤 타이머가 중요한지 이해하는 것이 또 다른 대응입니다.

조정이 도움이 되는지는 세 가지 조건이 결정합니다. 어느 단계가 느린지, 실패가 애초에 재시도 가능한지, 그리고 네트워크가 돌아왔음을 클라이언트가 어떻게 아는지입니다.

하나처럼 보이는 세 가지 대기

엔드포인트 확인, IKE 또는 TLS 협상, 패킷 재전송, 그리고새 시도 시작은 각기 다른 타이머를 가진 별개의 사건입니다. strongSwan은 IKE용재전송 백오프를 문서화하고,OpenVPN은 다른 의미론의 자체 재시도 제어를 가집니다. 한쪽 숫자를 다른 쪽으로 복사하는 것은 메커니즘이 같다고 가정하지만, 그렇지 않습니다. 어느 간격을 보고 있는지 결정하기 전에 로그 순서를 읽으세요.

로그의 조용한 일 분이 반드시 멈춘 프로세스는 아닙니다. 설정된 대로 정확히 동작하는 지수 백오프일 수 있습니다.

실제로 어느 단계가 느린가?

로그에 인증 오류로 실패하는 시도가 보이면 자격 증명이 틀렸으므로 어떤 타이머 변경도 도움이 되지 않습니다. 시도 자체가 없다면 클라이언트는 대기 창 안에 있고 일정이 해법입니다. 시도가 있고 시간 초과가 난다면 도달 가능성이나 리스너 부재가 문제이며, 더 빠른 재시도는 로그만 채웁니다. 이 세 상태는 각각 담당이 다르고, 그중 하나만 타이밍 문제입니다.

숫자를 건드리기 전에 실패를 분류하세요.

타이머를 낮추는 것이 도움이 될 때와 아닐 때

짧고 잦은 장애 후의 대기가 지배적 비용일 때 재시도 상한을 낮추세요. 예를 들어 액세스 포인트 사이를 이동하는 노트북입니다. 장애가 길거나 드물 때는 그대로 두세요. 공격적인 재시도는 컨센트레이터가 가장 응답하기 어려운 바로 그 순간에 부하를 더합니다. 두 경우 모두 매개변수를 하나 바꾸고 기록한 뒤, 나아졌다고 가정하지 말고 다음 복구를 측정하세요.

모든 프로필에 복사된 아주 낮은 시간 초과는 측정 없는 조정의 흔한 종착점입니다.

클라이언트를 탓하기 전에 준비 상태를 확인하세요

클라이언트는 무언가 시도하기 전까지 네트워크가 쓸 수 있다는 것을 보지 못하는 경우가 많습니다. 캡티브 포털, DHCP 갱신, 경로 변경은 그 모든 일이 일어나기 전에 설정된 일정에서 기다리게 할 수 있습니다. 운영 체제의 네트워크 상태 변화와 클라이언트의 다음 시도를 같은 시계에서 지켜보면 누구의 대기인지 보입니다. 빠른 방법은 네트워크 준비 이벤트의 타임스탬프와 그 이후 첫 시도의 타임스탬프를 적는 것입니다.

대기 중에도 직접 트래픽이 여전히 차단되는지 확인하세요. 트래픽이 새는 더 빠른 재연결은 개선이 아닙니다.

무엇을 기록할까

어떤 타이머가 어떤 값에서 어떤 값으로 바뀌었는지, 그 뒤 복구가 어땠는지 적으세요. 클라이언트 버전도 기록하세요. 기본값은 릴리스마다 달라지고, 문서화되지 않은 아주 낮은 시간 초과는 프로필을 읽는 다음 사람을 혼란스럽게 합니다.

그 기록이 다음 소프트웨어 업그레이드를 실험이 아니라 비교로 바꿉니다.