resolvconf 데이터베이스에서 오래된 VPN 레코드 제거하기

터널이 닫힌 다음 날에도 내부 이름은 여전히 VPN 서버로 확인되며, 리졸버 파일은 그 항목과 함께 계속 되돌아옵니다. Debian resolvconf 가 상태를 소유한 곳에서는 그 파일이 공급자 레코드로 조립되며, 그중 하나가 남은 잔여물입니다. 레코드 삭제는 일 분이면 되지만, 삭제해도 안전함을 증명하는 것이 진짜 작업입니다. 이 게이트들은 순서대로 실행되며, 실패한 게이트는 절차를 끝내고 다음 단계로 보내지 않습니다.

resolvconf 가 상태를 소유하는지 확인하기

같은 증상이라도 systemd-resolved 아래에서는 다른 명령과 다른 수리가 필요하기 때문에 소유자를 먼저 식별해야 합니다. resolvconf 패키지는 /run/resolvconf 아래에 데이터베이스를 두고 /etc/resolv.conf 를 그 데이터베이스에서 만든 파일로 연결합니다. 두 가지를 읽으면 문제가 정리됩니다: 심볼릭 링크의 대상과, 패키지가 설치되어 활성 상태인지 여부입니다. /run/systemd/resolve 아래의 대상이라면 다른 설계이며 아래 내용은 적용되지 않습니다.

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

링크가 다른 곳을 가리키거나 패키지가 없다면 여기서 멈추십시오. 이름만 빌려 다른 리졸버 관리자가 제공하는 호환 래퍼는 이 데이터베이스의 소유자가 아닙니다.

데이터베이스는 답이 아니라 입력을 담는다

데이터베이스는 입력을 담고 파일은 출력이므로, 입력을 나열하는 것이 없애려는 항목을 어느 프로그램이 설치했는지 확인하는 유일한 방법입니다. 레코드는 짧고, 그 키는 나중에 필요할 핸들입니다. VPN 인터페이스처럼 보이는 이름이 다른 클라이언트의 것일 수 있으므로 어느 것이 오래되었는지 결정하기 전에 읽어 보십시오. 키만으로도 보통 레코드를 식별할 수 있으므로 개인 주소와 내부 검색 도메인은 공유 진단에서 빼 두십시오.

sudo resolvconf --list
sudo resolvconf -i

첫 번째 명령은 공급된 레코드를 처리하지 않고 출력하고, 두 번째는 현재 DNS 구성을 제공하는 인터페이스를 나열합니다. 키는 관례적으로 인터페이스 이름과 공급 프로그램으로 만들어집니다. resolvconf 설명서는 그 키들이 가리키는 데이터베이스를 설명합니다.

키를 다시 만들지 말고 출력에서 복사하십시오. 오래된 스크립트가 그 이름을 썼다는 이유만으로 항목을 tun0 라고 부르지는 않습니다.

레코드에 소유자가 없음을 증명하기

살아 있는 연결이 설치하지 않은 레코드는 삭제해도 안전합니다. 키를 그것을 만든 연결과 연관 짓고, 그 연결이 사라졌음을 확인하십시오. 그 연관성이 게이트 전체이며, 삭제 명령으로 가는 길에 가장 자주 건너뛰는 단계입니다. 증거가 모호하면 레코드를 살아 있는 것으로 취급하고 멈추십시오.

프로세스 이름은 약한 증거입니다. OpenConnect 는 vpnc-script 를 호출하므로 vpnc 프로세스를 확인해도 어느 레코드가 현재인지는 알 수 없습니다. 새 연결이 오래된 연결이 남긴 인터페이스 이름을 다시 사용할 수도 있으며, 그러면 키가 실제보다 오래되어 보입니다. 레코드 안의 서버 주소를 아직 살아 있는 터널의 주소와 비교하고, 일치하면 멈추십시오.

소유 관리자를 통한 정상적인 연결 해제가 첫 번째 해결책입니다. 그것은 그 연결이 설치한 것을 철회하고 다른 공급자는 건드리지 않습니다.

제거와 재작성 확인하기

레코드가 오래되었다고 확인되면 정확한 키로 삭제한 다음, 가정하지 말고 결과를 읽으십시오. 이 명령은 호스트의 모든 애플리케이션에 대한 리졸버 상태를 바꾸므로 직접 통제하는 창에서 실행하십시오. 키에 셸이 확장할 문자들이 들어 있으므로 따옴표로 감싸십시오. 블록 안의 자리 표시자는 목록에서 복사한 키를 뜻하며 리터럴 문자열이 아닙니다.

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

업데이트가 활성화되어 있으면 삭제는 업데이트 스크립트를 실행하고, 업데이트가 비활성화되어 있으면 업데이트를 미루므로, 레코드 제거와 파일 재작성은 별개의 사건입니다. 파일을 보기 전에 목록을 다시 읽고 키가 사라졌음을 확인하십시오. 그다음 남은 공급자를 통해 여전히 확인되어야 하는 이름 하나와 공용 이름 하나를 조회하고, 둘 다 변경 전에 본 것과 비교하십시오. 개인 이름이 완전히 확인되지 않게 되면 그 레코드가 아직 그것을 나르고 있었던 것입니다.

resolvconf -u 는 그 업데이트 스크립트만 실행합니다. 그것은 오래된 레코드를 식별하거나 삭제하지 않으며, 오래된 입력에서 다시 만들면 같은 원치 않는 파일이 재현됩니다.

종료된 연결 해제 훅은 레코드를 남긴다

일회성 정리는 오늘의 상태를 복구하지만, 다음에 중단된 종료가 레코드를 되돌려 놓습니다. 해체 경로를 따라가 보십시오: 클라이언트의 연결 해제 훅, 그 훅이 호출하는 도우미, 그리고 둘 중 하나가 종료될 때 벌어지는 일입니다. 훅이 전혀 실행되지 않았기 때문에 중단된 종료가 흔한 원인입니다. 훅의 종료 상태를 한 번 기록해 두면 조용히 실패하는지 알 수 있습니다.

설정과 정리를 한 소유자 아래에 두십시오. 인터페이스 이름을 추측하는 두 번째 스크립트는 결국 다른 연결의 레코드를 삭제할 것이며, 그것은 처음 시작한 오래된 항목보다 나쁩니다. 어느 연결이 설치했는지 알고 있으므로 소유자가 레코드가 언제 오래되었는지도 결정해야 합니다.

그다음 수명 주기를 연습하십시오: 연결하고, 연결을 끊고, 레코드를 다시 나열하십시오. 항목이 스스로 사라지는 것이 수리가 유지된다는 유일한 증거입니다.