OpenVPN 클라이언트가 한 번의 시간 초과 후 계속 내려가 있는 이유

월요일 아침: 금요일에 올라온 터널은 사라졌고, 인터페이스는 여전히 목록에 있으며, 저널에는 누군가 알아차렸다는 말이 없습니다. 호스트는 온라인이고 대시보드는 초록색이며, 주말에 보낸 모든 것은 대신 물리 인터페이스로 나갔습니다. 여기에는 두 개의 독립적인 결정이 빠져 있습니다: 하나는 클라이언트 프로세스가 일시적 장애를 견디는지, 다른 하나는 그 위의 무언가가 프로세스가 종료된 뒤 다시 시작하는지입니다. 둘 중 하나만 고치면 다른 틈은 열린 채로 남습니다.

모니터링의 주장이 아니라 유닛이 실제로 한 일에서 시작하십시오. systemctl status openvpn-client@office 과 journalctl -u openvpn-client@office -n 50 은 종료 이유와 클라이언트가 떠나기 전에 쓴 마지막 줄을 보여 줍니다.

누구도 알아차리기 전에 프로세스가 종료되었다

오류 없이 사라지는 클라이언트는 보통 의도적으로 종료된 것입니다. 그 동작을 결정하는 것은 서비스 관리자가 아니라 프로필입니다: ping-exit 는 상대가 응답을 멈추는 즉시 프로세스를 끝내고, ping-restart 는 프로세스를 유지하며 그 안에서 다시 연결합니다. 세션 상한과 비활동 타이머도 밖에서 보면 같은 모습을 만듭니다: 터널도 경보도 없습니다.

두 ping 지시문은 한 프로필에 함께 있을 수 없으므로 하나를 고르고 선택을 기록하십시오. 서버도 살펴보십시오: 서버 자신의 ping-exit 는 클라이언트가 무엇을 요청했든 세션을 닫으며, 그 결정을 누가 했는지는 서버 로그에만 기록됩니다.

ping-exit와 ping-restart 중 선택

스스로 치유되어야 하는 노트북이나 원격 사이트에는 ping-restart 를 고르고, 죽은 터널이 프로세스를 멈춰 다른 무언가가 대응해야 하는 경우에는 ping-exit 를 남겨 두십시오. 숫자보다 관계가 더 중요합니다: ping 10 과 ping-restart 60 의 조합은 검사 전 열 초, 재시작 전 예순 초의 침묵을 뜻하며, 손실이 있는 모바일 링크에서는 공격적이고 유선에서는 합리적입니다. 이유를 줄 옆에 적어 두지 않으면 다음 독자는 기본값이 의도적이었다고 받아들일 것입니다.

그다음에 종료된 것이 정말 프로세스인지 확인하십시오. 터널이 죽어 있는데 활성이라고 보고하는 유닛은 다른 장애이며, 아래에서 다룹니다.

유닛을 실제로 재시작하는 감독

systemd 호스트에서 가장 작은 지속적 변경은 drop-in 파일 하나입니다: Restart=on-failure 과 RestartSec=10 이 /etc/systemd/system/[email protected]/restart.conf 안에 있습니다. drop-in은 systemd가 자체 정의를 다시 읽을 때만 읽히므로, 그 뒤에 systemctl daemon-reload 를 실행하십시오. 값이 반영되었다고 가정하지 말고 systemctl show -p Restart -p ExecMainStatus openvpn-client@office 로 확인하십시오. 파일 이름의 인스턴스는 유닛이 실제로 불러오는 프로필이어야 하므로, office 용으로 쓴 파일은 openvpn-client@home 에 아무 효과도 없습니다.

on-failure 는 한 가지 경우를 무시합니다: 상태가 영인 정상 종료입니다. 일부 정리 경로가 그렇게 끝나므로, 매뉴얼 페이지의 문구를 믿지 말고 기록된 상태를 읽으십시오. 클라이언트가 영으로 포기한다면 Restart=always 이 필요하며, 그 대가는 정말 망가진 프로필이 시작 속도 제한에 걸려 저널이 가득 찰 때까지 계속 돌아온다는 것입니다.

Restart=always 는 의도적 중지 후에도 작동합니다. 유지 관리에는 systemctl stop 를 쓰고, 작업하는 동안 유닛이 내려가 있어야 한다면 마스크하십시오.

터널이 내려가 있는 동안 누출을 잡아라

감독은 터널을 다시 올리지만, 터널이 없는 동안 트래픽이 나가는 것을 막지는 않습니다. persist-tun 는 재연결 사이에 장치와 경로를 유지하며, 이는 편리하고 창을 열어 줍니다. 장치는 살아남고 경로는 여전히 그것을 가리키며, 패킷은 보호도 보고도 없이 빠져나갑니다. 이것은 정책 선택이며 중립적인 기본값이 아닙니다.

호스트가 보호되지 않은 패킷을 전혀 내보내서는 안 된다면, 그것을 보장할 수 있는 것은 방화벽뿐입니다. 터널 인터페이스와 VPN 서버 주소를 허용하고 나머지를 모두 버리는 출력 규칙은 클라이언트가 죽은 뒤에도 유지되며, 클라이언트 자신의 구성에는 클라이언트가 나르지 않는 트래픽을 필터링할 수 있는 것이 없습니다.

클라이언트를 의도적으로 중지하여 시험하십시오. systemctl stop openvpn-client@office 를 실행한 다음 curl -m 5 https://example.com 를 실행하면, 물리 링크에서는 성공하지 않고 실패해야 합니다. 성공한다면 방화벽 규칙이 없거나 너무 관대한 것입니다.

다시 연결하고 터널이 다시 트래픽을 나르는지 확인한 다음에야 검사를 모니터링에 추가하십시오. cron에서 ip addr 를 tun 장치에 대해 폴링하는 것은 가장 자주 실패하는 감독입니다: persist-tun 가 있으면 장치가 세션보다 오래 살아남고, 아무것도 나르지 않는데도 검사는 건강하다고 보고하기 때문입니다.