VPN을 통한 SSH ServerAliveInterval: 프로브를 보내는 쪽은 어디인가?

SSH 세션을 살려 두라는 조언 대부분은 «ServerAliveInterval 30을 추가하세요»에서 멈추고 유용한 부분을 빼놓습니다. 핵심은 클라이언트 측 타이머로, 채널이 조용했을 때만 작동하고, 초가 아니라 응답 없는 프로브를 세며, 처음 일치하는 값이 이기는 파일 안에 삽니다. 이 세 가지 성질을 잘못 이해하면 건강한 VPN 세션도 끊기고 죽은 세션은 계속 매달려 있게 됩니다.

두 방향은 서로 다른 데몬에 속한다

ServerAliveInterval은 여러분의 ssh 클라이언트가 읽습니다. ClientAliveInterval은 반대편의 sshd가 읽고 반대 방향으로, 서버에서 클라이언트로 프로브합니다. 둘은 다른 이름이 아니라 서로 협력하지 않으므로 하나를 설정해도 다른 쪽의 동작에는 영향이 없습니다. 둘을 혼동하는 것이 한 호스트에서는 고친 것이 되어도 다음 호스트에서는 아닌 흔한 이유입니다.

둘 다 영을 받아들입니다. 영에서는 클라이언트가 아무것도 보내지 않고, 서버 쪽에서는 ClientAliveCountMax가 영일 때 응답 없는 검사 뒤에 이어질 연결 끊기를 비활성화합니다.

프로브가 증명하는 것과 증명하지 않는 것

설정한 간격이 지나도 서버에서 데이터가 오지 않으면, 클라이언트는 기존 암호화 채널로 작은 요청을 보내고 응답을 기다립니다. ServerAliveCountMax는 세션이 끊기기 전에 그중 몇 개까지 응답 없이 둘 수 있는지를 정합니다. 간격 60과 횟수 3이면 클라이언트는 약 삼 분의 침묵 뒤에 포기하며, 이 수치는 네트워크 표준이 아니라 여러분 설정의 성질입니다. 간격을 기본값 0으로 두면 프로브가 전혀 보내지지 않으며, 그래서 기본 클라이언트는 죽은 연결 위에 무한정 앉아 있을 수 있습니다.

교환이 SSH 전송 안에서 이루어지므로, 응답은 상대방의 SSH 프로세스가 아직 읽고 쓰고 있음을 증명합니다. 그 세션 안에서 시작한 프로그램에 대해서는 아무것도 말하지 않습니다: 데이터베이스 클라이언트, 전달한 포트, 오래 도는 스크립트는 전송이 유쾌하게 프로브에 응답하는 동안 멈춰 있을 수 있습니다.

TCPKeepAlive는 한 계층 아래의 별도 메커니즘입니다. 커널이 처리하고 암호화되지 않으며, SSH 데몬이 멈춘 상대도 여전히 이를 충족할 수 있습니다. 그래서 소켓이 아니라 세션이 중요할 때 SSH 수준의 프로브가 더 의미 있는 신호입니다.

어떤 값이 살아남을지는 순서가 정한다

OpenSSH는 각 매개변수에 대해 처음 얻은 값을 적용하므로, 특정 Host 블록은 함께 일치할 더 넓은 블록보다 앞에 있어야 합니다. 와일드카드 기본값은 파일 맨 위가 아니라 맨 아래에 두고, 더 아래의 Match 블록은 이미 설정된 값을 덮어쓸 수 없다는 점을 기억하세요. OpenSSH 클라이언트 구성 참조는 첫 값 규칙을 직접 밝히고 있으며, 공유 구성을 재구성하기 전에 한 번 읽어 볼 만합니다.

명령줄 옵션이 파일을 이기므로 임시 실험은 저렴합니다:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

썼다고 생각하는 것 대신 클라이언트가 실제로 해석한 것을 보려면 유효 구성을 덤프하게 하세요. 출력에는 그 호스트 이름에 대해 병합된 값이 들어 있고, 엉뚱한 앞선 블록을 잡는 가장 빠른 방법입니다:

ssh -G office-shell | grep -i alive

터널 위에서 keepalive가 하는 일

주기적인 트래픽은 상태 기반 NAT나 방화벽 매핑이 만료되지 않게 하며, 이는 유휴 흐름을 몇 분 뒤에 버리는 게이트웨이를 둔 VPN에서 실제 이점입니다. 60초마다 도착하는 프로브는 애플리케이션 데이터를 전혀 나르지 않고 그 매핑을 갱신합니다.

사라진 경로를 다시 세울 수는 없습니다. 터널 인터페이스가 사라지면 프로브도 다른 모든 것처럼 실패하고, 횟수가 소진되면 세션이 끝납니다. 생존 감지와 경로 복구는 다른 문제이며 ssh_config에서 설정할 수 있는 것은 첫 번째뿐입니다. 간격과 횟수가 실제로 사 주는 것은 클라이언트가 얼마나 빨리 알아차리는지이고, 사용자는 바로 그 부분을 멈춤으로 경험합니다.

다중화 연결은 주름 하나를 더합니다. ControlMaster가 관여하면 프로브는 마스터 연결에 속하고, 기존 마스터 위의 새 세션은 그 마스터가 협상한 것을 물려받습니다. mux 마스터가 멈춰 있으면 다른 창을 열어도 경로를 다시 시험하지 않습니다.

설정을 처음부터 끝까지 확인하기

서버에서는 파일을 읽고 어느 include가 이겼는지 추측하는 대신 유효 데몬 구성을 덤프하세요:

sshd -T | grep -i clientalive

그다음 디버그 출력을 켠 실제 세션을 관찰하세요. 횟수가 소진되면 클라이언트가 타임아웃 줄을 찍고, 그 주변의 타임스탬프는 침묵이 계속되었는지 아니면 프로브가 아예 보내지지 않았는지를 보여 줍니다. 프로브 트래픽 없이 죽는 세션은 보통 한 번도 일치하지 않은 블록에 키워드를 두고 있습니다.

터널로만 닿는 호스트에는 두 가지 확인을 더할 만합니다: 해석된 간격이 의도한 값인지 확인하고, 그 간격에 횟수를 곱한 값이 VPN 게이트웨이의 유휴 타임아웃보다 짧은지 확인하세요. 두 번째 수가 더 크면 게이트웨이가 먼저 조용히 흐름을 버리고 SSH 프로브는 아무것도 보고할 기회를 얻지 못합니다.