SIGKILL 이후 OpenVPN DNS가 남는다: 먼저 소유자를 확인하라

OpenVPN 클라이언트가 강제 종료된 뒤 DNS가 더 이상 해석되지 않으며, 첫 번째 본능은 /etc/resolv.conf 파일을 다시 쓰는 것입니다. 그 편집은 정상 동작하는 리졸버를 망가뜨릴 수 있는 반면 진짜 오래된 상태는 다른 곳에 있습니다. 먼저 정리해야 할 질문은 터널이 설치한 DNS 설정을 누가 소유하는지, 그리고 정리를 건너뛴 종료가 실제로 중요했는지입니다.

세 가지 조건이 복구를 결정합니다. 프로세스를 끝낸 신호, 설정을 받은 리졸버 구성 요소, 그리고 터널 링크가 아직 존재하는지 여부입니다. 이 순서대로 답하면 보통 전역 파일을 건드리지 않고 수정이 따라옵니다.

어떤 종류의 종료가 일어났는지 판단하라

Community 에디션의 OpenVPN에서는 SIGINT와 SIGTERM이 모두 정상 종료 요청입니다. SIGKILL은 잡을 수 없습니다. 차단도 처리도 할 수 없으므로 어떤 종료 루틴도 실행될 기회를 얻지 못합니다. 전면 터미널의 일반 Ctrl+C는 SIGINT를 만들고, 기다리기를 포기한 슈퍼바이저는 보통 SIGKILL로 확대합니다. 차이가 중요한 이유는 두 번째 경우에만 훅이 건너뛰어졌음이 보장되기 때문입니다.

screen이나 tmux 안에서 실행해도 Ctrl+C가 어떤 신호를 보내는지는 바뀌지 않습니다. 터미널이 보통 하는 일이 아니라 프로세스가 실제로 받은 것을 확인하십시오.

서비스나 연결 관리자가 터널을 실행할 때는 pid를 죽이는 대신 그 연결을 소유자를 통해 중지하십시오. 관리자가 프로세스를 다시 올릴 수 있어 새 터널과 혼란스러운 리졸버 상태가 남을 수 있습니다. 독립 프로세스는 정리가 실행되도록 평범한 종료 요청만 필요합니다.

누가 리졸버를 소유하는지 판단하라

systemd-resolved, resolvconf 스타일 스크립트, 단순한 파일 재작성은 서로 다른 세 소유자입니다. 첫 번째는 링크별 설정을 메모리에 두고 인터페이스가 사라지면 버립니다. 두 번째는 무언가 지울 때까지 남는 기록을 유지합니다. 세 번째는 파일을 쓰고 복원을 그것을 쓴 사람에게 맡깁니다.

복구 명령을 고르기 전에 소유자를 식별하라. 같은 증상이라도 어느 것이 사용 중인지에 따라 세 가지 다른 정답이 있습니다.

NetworkManager가 관리하는 VPN은 이미 리졸버 변경을 소유하고 있을 수 있습니다. 그 위에 두 번째 도우미를 더하면 같은 링크를 두고 경쟁하는 두 소유자가 생기고, 진 쪽의 상태가 다음 재연결에서 다시 나타납니다. 관리자가 책임진다면 스크립트가 아니라 관리자에서 설정을 고치십시오.

down 훅이 할 수 있는 일과 할 수 없는 일

스크립트 down는 TUN/TAP 장치가 닫힌 뒤 한 번 실행됩니다. 추가하면 down-pre이 순서를 뒤집어 장치가 아직 있는 동안 스크립트를 실행하며, 살아 있는 링크가 필요한 도우미들이 요구하는 동작입니다.

어느 지시문도 SIGKILL 이후에 훅을 실행하게 만들지 않습니다. 권한도 down-pre로 복원되지 않습니다. 데몬이 user 또는 group로 내려가거나 chroot에 들어가면 훅은 그것이 남긴 접근 권한으로 실행됩니다. 호출된 훅이 리졸버를 갱신하지 못할 수도 있습니다. OpenVPN 참조는 신호와 콜백 수명 주기를 다룹니다.

프로세스 종료 상태 옆에서 훅 자체의 오류를 확인하십시오. 사라진 정리와 실패한 정리는 리졸버에서는 같아 보이고 로그에서는 다르게 보입니다.

실제로 남은 상태를 확인하라

systemd-resolved를 쓰는 시스템에서 resolvectl status은 어느 링크가 아직 VPN DNS 서버나 라우팅 도메인을 나르는지 보여 줍니다. 그 링크는 이미 사라진 연결의 것일 수도 있고, 아직 살아 있는 다른 터널의 것일 수도 있습니다.

사라지는 인터페이스는 링크별 구성을 함께 가져가므로, 건너뛴 훅이 깨끗한 DNS와 공존할 수 있습니다. 링크가 아직 등록되어 있고 중지된 연결만 소유한다면 소유 관리자가 그것을 제거해야 합니다. 더 오래된 스크립트가 전역 리졸버 파일을 다시 썼다면 대신 그 스크립트의 문서화된 복원 단계를 찾으십시오.

다른 링크를 훔치지 않고 복구하라

링크별 설정을 직접 관리한다면, resolvectl revert은 링크 이름을 받아 그 인터페이스의 런타임 DNS 구성을 지웁니다. 프로필 편집이 아니라 런타임 동작이므로 지속적인 연결 구성은 그대로 남습니다. 잘못된 링크를 지정하면 동작 중인 터널의 DNS를 지우게 되므로, 이름은 상태 출력에서 가져옵니다.

편집하기 전에 /etc/resolv.conf이 관리되는 심볼릭 링크인지 확인하고, 그다음 클라이언트를 한 번 더 정상적으로 중지한 뒤 DNS를 다시 보십시오. 두 번째 중지에서 정리된다면 이전 문제는 구성이 아니라 강제 종료였습니다.