매시간 OpenVPN 끊김: 재협상인가 진짜 재연결인가?

육십 분, 혹은 삼십 분, 혹은 백이십 분: 딱 떨어지는 간격에 걸리는 끊김은 거의 결코 네트워크가 아니다. OpenVPN 은 데이터 채널을 보호하는 키 자료를 타이머에 따라 갱신하며, 짐작한 것보다 짧은 타이머는 계속 실패하는 링크와 똑같이 보인다. 사용자는 끊긴 연결을 보고하지만 로그는 성공한 키 교환을 보고한다. 아래 절차는 그 갱신을 진짜 재시작과 구분하고, 실제로 유효한 값을 읽고, 비용이 테이블 위에 올라온 뒤에야 값을 바꾼다.

첫 단계가 이 페이지의 나머지가 당신에게 해당하는지를 결정하므로 단계를 순서대로 하라. 건너뛰면 그와 아무 관련 없는 결함 때문에 저녁을 타이머 조정에 쓸 것이다.

소프트 리셋과 재시작을 구분하라

로그 줄이 진단의 전부다. 재협상은 같은 터널 안에서 소프트 리셋을 쓰고 이어서 새 키 교환을 하므로, 인터페이스는 주소를 유지하고 경로는 다시 추가되지 않으며 이미 맺어진 TCP 세션은 보통 잠깐 멈췄다가 살아남는다. 진짜 재시작은 세션을 찢고, 인터페이스를 다시 만들고, 다른 클라이언트 주소를 줄 수 있으며, 모든 장기 연결을 죽인다. 두 사건 모두 흔하고, 끊긴 통화를 설명하는 것은 그중 하나뿐이다.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

버전 줄이 중요한 것은 릴리스 사이에 로그 문구가 달라지고, 2.3에서 기억하는 메시지가 2.6에서는 다르게 쓰여 있을 수 있기 때문이다. 다른 사람의 포럼 발췌가 아니라 자신의 로그를 읽어라. 도움을 청할 때는 정확한 줄을 인용하라, 바꿔 말하면 사건을 식별하는 세부가 사라지기 때문이다. 사건 전후로 인터페이스 주소가 그대로이고 세션 목록이 살아남았다면 그것은 갱신이며 나머지 절이 적용된다.

유효한 타이머를 읽어라, 자신의 파일이 아니라

reneg-sec 은 데이터 채널 재협상 사이의 초 수이며 기본값은 3600이다. 각 피어가 자기 값을 가지며, 둘 중 작은 값이 실제로 갱신을 촉발한다. 그 한 가지 규칙이 대부분의 보고를 설명한다, 큰 수를 설정한 클라이언트 프로필도 서버가 기본값을 유지하면 매시간 초기화되기 때문이다.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

클라이언트 파일에서 결론을 내리기 전에 서버의 유효한 설정도, 그것이 푸시하는 모든 것을 포함해 읽어라. 그다음 상세 수준을 올려 한 간격을 처음부터 끝까지 관찰하면, 수준 3에서 이미 재협상 줄이 보이고 타임스탬프가 그 사건이 3600초마다 반복되는지 아니면 활동을 따르는지 알려준다.

실제로 푸시되는 곳에서 바꿔라

떠도는 처방은 클라이언트 프로필의 한 줄이지만, 절반쯤은 틀린 위치다. 피어의 낮은 값이 이기므로, 타이머를 영으로 둔 클라이언트도 바뀌지 않은 서버에 의해 재협상될 수 있다.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

프로필을 중앙에서 생성한다면, 배포된 사본이 아니라 템플릿을 편집하라. 그렇지 않으면 다음 프로비저닝 실행이 방금 지운 값을 복원하니, 확인은 하나가 아니라 두 간격으로 하고, 조용한 한 시간만으로는 7200으로 설정된 타이머와도 들어맞는다는 점을 기억하라.

혼합 배포에서 무슨 일이 일어나는지도 정하라. 변경을 먼저 클라이언트에 배포하면 서버가 아직 갱신을 촉발하는 창이 남는다, 무해하지만 확인을 위해 로그를 보고 있다면 혼란스럽다. 작은 값을 가진 쪽을 먼저 바꾸면 증상은 예상한 지점에서 사라진다.

재협상을 비활성화하면 무엇을 포기하는가

정기적 재협상은 데이터 채널 키 한 세트가 트래픽을 얼마나 오래 보호하는지를 제한한다. 타이머를 끄는 것은 터널을 깨지 않으며, 가정용 공유기나 소규모 사무실 게이트웨이에서 실질적 노출은 작다. 그래도 교환이며, 하기 전에 그 교환을 말할 가치가 있다. 바뀌는 것은 키 한 세트가 세션을 보호하는 시간이지, 터널이 애초에 동작하는지가 아니다.

비활성화의 합당한 경우는 끊기는 통화, 다시 세워야 하는 원격 데스크톱 세션, 처음부터 다시 시작하는 백업처럼 재개할 수 없는 것을 깨는 리셋이다. 일시 정지가 사용자에게 보이지 않는다면 기본값을 두는 데 드는 비용은 없고 주어진 키 순환을 유지한다.

패턴이 허락한다면 원인을 고치는 쪽을 택하라. 첫 핸드셰이크는 성공했는데 중간에 실패하는 갱신은 타이머가 아니라 경로를 가리키므로, 더 큰 제어 채널 교환에서의 패킷 크기 문제, 흐름을 떨어뜨리는 상태 기반 방화벽, 첫 시도에서만 성공하는 제안을 찾아라. 각각은 방금 읽은 같은 로그에 흔적을 남긴다. 타이머를 끄면 그 증거가 가려진다.

간격이 다른 곳을 가리킬 때

설정의 두 이웃이 비슷한 증상과 다른 해결책을 낳는다. 정해진 기간 동안 아무것도 오지 않으면 ping-restart 이 터널을 재시작하고, ping-exit 은 클라이언트를 완전히 내린다. 로그 어디에도 재협상이 없는 유휴 끊김은 이것들이나, UDP 매핑을 자기 일정대로 만료시킨 NAT 장치에 속한다.

소비자 공유기, 모바일 핫스팟, 통신사급 NAT는 모두 유휴 UDP 세션을 아무에게도 알리지 않고 만료시킨다. 그 고장은 시계가 아니라 유휴를 따르며, 조용한 십 분 뒤에 끊기고 한 시간의 꾸준한 트래픽을 견디는 세션은 재협상하고 있지 않다.

네 번째를 바꾸기 전에 측정한 간격, 찾은 유효한 값, 그것을 보여준 명령의 세 가지를 적어라. 타이머를 움직일 때 간격도 움직이면 메커니즘은 확인된 것이고 해결은 위의 교환에 대한 결정이다. 움직이지 않으면 설정을 되돌리고 keepalive, NAT 상태, 패킷 손실을 계속 보라.