nc -uz 가 OpenVPN 서버가 준비되었음을 증명할 수 없는 이유

nc -uz 을 OpenVPN 서버에 대해 실행해도 거의 아무것도 측정하지 못하며, OpenBSD 설명서 도 주의 사항에서 그 모드의 UDP 스캔은 무언가가 수신 중이든 아니든 성공을 보고한다고 말합니다. 종료 상태는 원격 상태가 아니라 로컬 전송을 반영하므로, 그것을 신뢰하는 감독자는 프로세스 표가 그럴듯해 보이는 동안 죽은 서버를 정상으로 표시해 둡니다. 그것을 교체하는 일은 프로세스, 수신기, 인증, 애플리케이션 도달 가능성이 서로 다른 네 가지 관찰이므로 검사가 어떤 질문에 답해야 하는지 정하는 데서 시작됩니다. 그중 하나를 지목하는 검사는 유용하지만, 네 가지를 모두 함축하는 검사는 부담입니다.

UDP 검사가 관찰할 수 있는 것과 없는 것

nc -uz 은 데이터그램을 보내고 종료하며, 반환하는 상태는 로컬 전송을 설명합니다. 닫힌 포트는 ICMP port unreachable 로 응답할 수 있지만, 이 스캔 모드의 문서화된 동작은 그것을 실패로 바꾸지 않으며, 필터링된 포트는 아예 응답을 내지 않습니다. 따라서 침묵과 성공은 호출자에게 같은 의미입니다.

그래서 이 검사는 서버가 아니라 로컬 스택의 시험이 됩니다. 호스트에 도달할 수 있는지, 포트가 바인딩되었는지, OpenVPN 프로세스가 실행 중인지, 클라이언트가 인증할 수 있는지는 확인하지 않습니다. TCP 연결 시험이 더 강한 것은 핸드셰이크가 명확한 답을 주기 때문이지만, 배포가 실제로 TCP에서 수신할 때만 그렇습니다. 같은 번호에서 검사를 TCP로 바꾸면 존재하지 않을 수도 있는 수신기를 시험하게 되고, UDP만 쓰는 서버에 대해서는 정상 서비스를 실패시킵니다.

검사를 구성된 전송에 맞추는 일은 두 결과 중 어느 것도 신뢰하기 전에 옵니다. UDP 배포에는 다른 신호가 필요하며, 다른 프로토콜이 아닙니다.

세 가지 호출자, 세 가지 다른 질문

준비 상태는 누가 묻는지에 달려 있습니다. 죽은 프로세스를 다시 시작하는 서비스 관리자는 인스턴스가 시작되어 수신기를 바인딩했음을 알아야 합니다. 로드 밸런서는 지금 도착하는 클라이언트가 받아들여질 것임을 알아야 합니다. 모니터링 시스템은 실제 네트워크에서 오는 경로가 여전히 허용된 리소스까지 세션을 나른다는 것을 알아야 합니다.

이것들은 같은 검사가 아니며, 하나의 검사가 세 가지를 모두 정직하게 덮을 수 없습니다. 먼저 호출자를 고르고, 그다음 증거를 고르세요.

현재 인스턴스에서 검사를 구성하세요

OpenVPN 은 인스턴스가 초기화를 마치면 시작 줄을 기록하며, 그 줄은 로컬 시작에 관한 유용한 증거입니다. 지난주 성공은 일 분 전 성공과 똑같이 읽히므로, 덧붙여지는 파일의 끝이 아니라 현재 시작에서 읽으세요. 서버는 어떤 클라이언트도 한 번도 연결하기 전에 초기화를 마칠 수 있으므로, 그 줄은 인증에 대해 아무것도 말하지 않습니다.

시작 검사에는 프로세스 상태를 현재 로그 증거와 구성된 전송에 맞는 수신기와 결합하세요. 프로세스가 실행 중이지만 초기화를 마치지 않았을 때 실패해야 하며, 이는 로그 조회가 이 부팅과 이 장치로 제한되어야 함을 뜻합니다.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

장치가 활성이고, 이 부팅이 초기화 줄을 만들었으며, 무언가가 UDP 포트를 잡고 있다는 세 가지 출력입니다. 어느 것도 클라이언트가 연결할 수 있다고 말하지 않습니다. 상태 페이지에서 이것들을 분리해 두어 장애가 초록 점 하나로 뭉개지지 않게 하세요.

일부러 깨뜨리고 검사를 지켜보세요

검사는 실패하는 모습을 본 뒤에야 신뢰할 수 있습니다. 서버를 멈추고 검사를 실행해 기대한 결과를 확인하세요. 그런 다음 다시 시작해 다른 변경 없이 검사가 회복되는지 확인하세요.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

블록을 줄마다 읽으세요. netcat 명령은 exit=0 를 출력하는데, 그때 아무것도 바인딩되어 있지 않으며, 이것이 한 줄로 드러나는 문제의 전부입니다. 첫 번째 ss 는 아무것도 출력하지 않고, 재시작은 성공하며, 두 번째 ss 가 다시 수신기를 보여 줍니다. 멈춘 서버에 대해 검사가 통과한다면, 그것은 로컬 스택을 측정하는 것이고 다른 것은 아닙니다.

반대 방향의 실패도 중요합니다. 정상 서버에 대해 실패하는 검사는 필요하지도 않았던 재시작을 일으키고, 재시작 루프 자체가 하나의 장애입니다. 검사를 그것에 따라 행동할 수 있는 무언가에 연결하기 전에 양방향을 시험하세요.

상태 줄이 말해야 하는 것

프로세스, 수신기, 인증, 애플리케이션 중 각 검사가 어느 경계를 덮는지 기록하세요. 하나의 검사가 둘 이상을 덮는 경우는 드물고, 그것들을 “up” 으로 압축하는 상태 페이지는 장애 때 중요한 차이를 감춥니다. 네트워크 경로에는 전용 ID 를 가진 실제 클라이언트를 사용해 핸드셰이크와 허용된 무해한 작업 하나를 마치게 한 뒤 연결을 끊으세요. 이렇게 하면 제어 채널, 인증 정책, 수신기를 한 단계에서 단련합니다.

그 ID 는 실제 사용자와 분리해 두고 검사에 필요한 최소 권한만 주세요. 넓은 접근 권한을 가진 준비 검사는 편의를 위해 추가된 새로운 공격 표면입니다. 인증을 멈춘 검사는 클라이언트 받기를 멈춘 서버와 똑같아 보이므로, 다른 계정과 마찬가지로 자격 증명을 교체하세요.

경고 문구에 경계를 명시해 첫 대응자가 장치, 소켓, 인증서, 경로 중 무엇을 봐야 하는지 알게 하세요. 무엇을 증명했는지 말할 수 없는 검사는 잘못된 이유로 신뢰받는데, netcat 검사가 애초에 살아남은 것도 바로 그 때문입니다.