종료된 openconnect: 라우트와 DNS가 여전히 터널을 가리킨다

터널은 내려갔지만 머신은 여전히 올라가 있는 것처럼 동작합니다. 조회는 타임아웃까지 매달리고, 라우트는 더 이상 존재하지 않는 인터페이스를 가리킵니다. 이것은 연결 해제 도우미를 실행하지 않고 죽은 openconnect 프로세스의 흔적입니다. 그것이 만든 네트워크 상태는 여전히 설치되어 있고, 시스템의 다른 무엇도 이를 제거하는 방법을 모릅니다.

상태가 만들어진 순서대로 머신을 살펴봅니다. 프로세스, 링크, 라우트, 리졸버 순서입니다. 각 단계는 클라이언트가 정말 사라졌는지 아니면 터미널에서만 분리되었는지를 알려 주고, 그 차이가 무엇이든 고칠지 결정합니다.

구성이 아니라 프로세스부터 시작하십시오

라우트를 건드리기 전에 터미널을 열고 무엇이 아직 실행 중인지 확인하십시오.pgrep -a openconnect각 인스턴스를 인수와 함께 나열하여 pid 파일과 부여된 스크립트를 보여 줍니다. 예상하지 못한 프로세스는 어떤 로그보다 빠르게 유령 터널을 설명합니다.

아무것도 실행 중이 아니라면 링크를 보십시오.ip link show tun0인터페이스가 살아남았는지 알려 주고,ip route show dev tun0아직 연결된 라우트를 나열합니다. 다음으로 리졸버를 이것으로 확인하십시오resolvectl status. 변경하기 전에 세 출력을 모두 기록하십시오. 그 기록이 나중에 오래된 항목과 새 항목을 구분하는 방법입니다.

사라진 인터페이스는 보통 자신의 라우트를 함께 가져갑니다. 링크보다 오래 남는 라우트는 보통 프로세스가 아직 살아 있거나 두 번째 클라이언트가 장치를 소유한다는 뜻입니다.

변경을 되돌리는 것은 도우미 스크립트입니다

openconnect는 인터페이스, 라우트, 리졸버 항목을 스스로 제거하지 않고 외부 도우미를 호출합니다./etc/vpnc/vpnc-scriptupstream 빌드에서는/usr/share/vpnc-scripts/vpnc-scriptDebian과 Ubuntu 패키지에서는 다음 옵션으로 선택됩니다:-s. 터널을 세우는 바로 그 스크립트가 터널을 해체합니다.

프로세스가 그 도우미를 호출하지 않고 종료되면 상태가 남습니다.OpenConnect 설명서는 스크립트 없이는 라우팅과 이름 서비스가 제대로 작동하지 않는다고 분명히 밝히고, 종료 시 인터페이스 상태를 해체하는 구성 요소로 도우미를 설명합니다. 그래서 클라이언트를 다음 옵션으로 시작할 때 경로가 중요합니다:-s.

어떤 시그널이 그 경로에 도달하는지는 버전마다 바뀌었습니다. 7.06 설명서는 SIGTERM을 스크립트를 건너뛰는 즉시 종료로 취급합니다. 현재 빌드는 INT와 TERM을 세션이 로그오프되고 도우미가 실행되는 깨끗한 중지로 문서화합니다. 두 동작 중 하나를 가정하지 말고 실제로 가진 바이너리의 SIGNALS 절을 읽으십시오.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

빌드가 문서화한 시그널을 보내십시오

시그널을 알면 패턴이 아니라 pid로 프로세스를 중지하십시오.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

그런 다음 종료 상태를 믿는 대신 첫 번째 절의 세 검사를 반복하십시오.ip link show tun0실패해야 하고,ip route show dev tun0아무것도 출력하지 않아야 하며,resolvectl status더 이상 VPN 링크를 나열하지 않아야 합니다.

SIGHUP은 중지 버튼이 아니라, 연결을 끊고 스크립트를 실행하며 세션을 다음 옵션으로 재개할 수 있게 남깁니다:--cookie. SIGUSR2는 즉시 재연결을 강제합니다. SIGKILL은 정리를 완전히 건너뛰며, 그것이 바로 이 문서가 다루는 상태입니다.

resolv.conf를 바꾸지 않고 리졸버를 고치십시오

대부분의 Ubuntu 시스템에서/etc/resolv.confsystemd-resolved로 가는 심볼릭 링크이며, 편집해야 할 파일이 아닙니다. 이를 바꾸면 VPN뿐 아니라 모든 네트워크의 이름 해석이 깨집니다. 대신 터널의 등록을 제거하십시오:

resolvectl revert tun0
resolvectl query example.com

시스템이 systemd-resolved 대신 resolvconf를 사용한다면 인터페이스별 기록은 링크를 놓으라는 지시가 있을 때까지 남고,resolvconf -d tun0가 동등한 작업입니다. 명령을 고르기 전에 어떤 리졸버가 사용되는지 확인하십시오.

죽은 링크 뒤의 서버를 여전히 겨냥한 조회는 타임아웃까지 매달리고, 그 지연은 남은 라우트보다 고장 난 DNS 서버처럼 보입니다.

다음 연결 해제를 지루하게 만드십시오

시작과 종료 시 pid 파일 경로를 동일하게 유지하려면 매번--pid-file를 전달하거나,openconnect를 유닛 아래에서 실행하고그KillSignal이 사용 중인 버전이 문서화한 시그널과 일치하게 하십시오. 먼저 포그라운드에서 시험하면 도우미가 출력하는 종료 메시지를 볼 수 있습니다.

연결하고, 연결을 끊고, 세 검사를 한 번 실행하십시오. 깨끗한 종료는 VPN 링크도, VPN 라우트도, VPN 리졸버 항목도 남기지 않습니다. 셋 중 하나가 살아남으면 이제 어느 구성 요소가 정리에 실패했는지 압니다. 다음 조사는 매달린 조회가 아니라 그 답에서 시작됩니다.