RAM에서 실행되는 VPN 런타임은 로그에 대해 아무 말도 하지 않는다

읽기 전용 이미지에서 부팅하고 실행 상태를 tmpfs에 두는 VPN 서버는 실제적이고 유용한 설계입니다. 이를 로그 없음이라고 설명하기도 쉽지만, 설계가 그것을 입증하지는 않습니다. 저장 위치는 사본이 사는 곳을 정하고, 수집과 보존은 기록이 존재하는지를 정하며, 재부팅은 전자에만 영향을 줍니다. 이 둘을 구분하는 것이 검토의 전부입니다.

상태를 쓸 수 있는 모든 프로세스를 나열하는 것부터 시작하세요: 데몬, 인증 서비스, 저널, 모든 모니터링 에이전트, 관리 도구.

저장과 수집은 다른 질문이다

기록자마다 목적지와 정책이 다릅니다. VPN 데몬은 상태 파일을 쓰고, 인증 백엔드는 계정 이벤트를 쓰고, 저널은 서비스 출력을 모으고, 모니터링 에이전트는 지표를 전혀 다른 곳으로 보냅니다. 그중 하나를 재부팅 때 사라지게 하는 설계는 나머지 셋에 대해 아무 말도 하지 않은 것입니다. 각 기록자를 목적지까지 따라가고 그 목적지가 기계에 있는지 기록하세요.

애플리케이션별 파일, 업로드된 진단, 외부 서비스도 같은 대우가 필요합니다. 익숙한 로컬 로그가 없다고 해서 연결이나 계정 기록이 어디에도 없다는 증거는 아니며, 아직 어디로 가는지 찾지 못했다는 증거입니다.

tmpfs는 보장이 아니다

Linux tmpfs는 물리적 RAM 디스크가 아닙니다. 커널 문서는 마운트가 허용하면 페이지를 스왑에 쓸 수 있다고 명시하므로, 애플리케이션이 한 번도 복사하지 않아도 tmpfs 파일이 디스크에 도달할 수 있습니다. mount는 스왑 기반 tmpfs가 작동 중인지 보여 주고, 다른 메모리 파일 시스템은 또 다르게 동작합니다. /run 아래 경로가 휘발성을 뜻한다고 가정하지 말고 실제 마운트 옵션을 읽으세요.

다음으로 사람들이 잊는 방식으로 재부팅을 견디는 것들을 목록화하세요: 영구 상위 계층, 연결된 스토리지, 최대 절전 이미지, 크래시 덤프, 전체 VM의 인프라 스냅샷입니다. 각각은 일시적이라고 여겼던 상태의 후보 목적지입니다. 그 목록은 확인할 대상이며, 모든 호스트에 그것들이 다 있다는 주장이 아닙니다.

Journald에는 두 목적지와 전달자가 있다

Journald는 이 분리를 잘 보여 줍니다. 휘발성 저장은 항목을 /run/log/journal 아래에, 영구 저장은 /var/log/journal 아래에 두고, 자동 모드는 둘 사이에서 선택합니다. 적용되는 모드는 실행 중인 시스템에서 오지 이미지 설명에서 오지 않으며, 휘발성으로 바꿔도 이미 영구적으로 쓰인 것은 지워지지 않습니다. 전달도 별도 채널로, 로컬에 아무것도 남기지 않는 저장 설정도 메시지를 다른 대상에 넘길 수 있습니다.

한 설정이 다른 설정을 제어하지 않으므로, 적용 모드는 저널 자체나 그 설정 파일에서 읽고 전달 대상은 따로 확인하세요.

재부팅을 견뎌야 하는 것

상태 없는 런타임은 반복 가능한 교체를 지원하며, 서비스가 스스로 만들 수 없는 구성, 권한 부여, 복구 자료에는 의도적인 출처가 필요합니다. 로컬 쓰기를 사라지게 하려고 유일하게 작동하는 등록이나 폐기 상태를 잃는 것은 나쁜 거래이며 흔합니다. 의도적으로 무엇이 살아남아야 하는지 정하고, 실제로 그런지 확인하세요.

같은 논리가 운영 기록에도 적용됩니다. 보안과 서비스 관리가 실제로 필요로 하는 이벤트를 정당한 범위와 보존 기간으로 정하고 나머지는 최소화하세요. 최소화는 모든 진단을 끄는 것과 같지 않습니다.

적용 중인 저장과 전달 구성을 몇 가지 무해한 이벤트와 비교하고, 그다음 기계를 재부팅하거나 교체한 뒤 무엇이 남았고 서비스가 어디서 상태를 복구했는지 다시 확인하세요.