터미널을 닫을 때 AnyConnect가 끊긴다: 세션 점검

터널이 올라와 있는데 여분 터미널을 닫으면 클라이언트에서 키를 한 번도 누르지 않았는데 VPN이 내려갑니다. 리눅스 AnyConnect 클라이언트에서 보고되는 원인은 라우팅이 아니라 세션 회계입니다. 클라이언트는 터널이 올라올 때 어떤 로그인 세션이 있었는지 기록하고, 그중 하나라도 끝나면 터널을 내릴 이유로 취급합니다. 아래 점검은 순서대로 진행되며, 첫 번째로 실패하는 항목이 이 동작이 맞는지 알려 줍니다. 클라이언트의 평소 출력에는 터미널 이야기가 없기 때문에, 집중 장치를 탓하는 첫 직감은 대개 헛수고입니다.

시스템 파일을 편집하는 것부터 시작하지 마세요. 각 단계는 끊김을 설명하거나 후보를 하나씩 제거하며, 값싼 단계가 먼저 옵니다.

세션 끊김과 하위 링크 끊김을 구분하기

연결이 끊긴 직후 즉시 다시 연결하세요. 같은 네트워크에서, 새 자격 증명 없이, 몇 초 안에 돌아오는 터널은 죽은 업링크나 Wi-Fi 로밍, 집중 장치의 유휴 타임아웃이 아니라 닫힌 세션 같은 로컬 트리거를 가리킵니다. Connecting 에서 멈춰 있거나 네트워크를 바꿔야만 되는 터널은 다른 글의 주제입니다.

터널이 올라올 때 무엇이 열려 있었는지 적어 두세요. 클라이언트를 실행한 터미널, 두 번째 셸, 그래픽 로그인, 다른 컴퓨터에서 온 SSH 세션까지입니다. 이 목록은 곧 필요해지며, 다음 끊김 뒤에 기억으로 재구성하는 것은 믿을 수 없습니다.

접속 시점에 클라이언트가 무엇을 기록했는지 확인하기

클라이언트는 프로세스 부모나 터미널 소유권을 조사하지 않습니다. 접속 시점에 존재하던 로그인 세션 집합을 스냅숏으로 찍어 두고 나중에 그 집합과 비교합니다. 구성원 하나가 사라지면 비교가 실패하고 터널도 함께 내려갑니다. 그래서 접속한 창을 닫는 것은 무해할 수 있지만 무관한 여분 터미널을 닫으면 연결이 끊깁니다. 중요한 것은 그 세션이 원래 집합에 있었는지 여부입니다. 개수가 아니라 집합 비교이므로, 세션을 바꾸는 것도 하나를 잃는 것만큼 치명적일 수 있습니다.

무엇이든 바꾸기 전에 클라이언트가 볼 수 있는 것을 나열하세요:

who
w
last -n 10
sudo ls -l /run/utmp

who 의 모든 줄은 utmp 의 사용자 프로세스 항목입니다. 세션이 두 번 나타난다면, 그래픽 로그인에 한 번 그리고 터미널에 한 번, 두 항목 모두 접속 시점에 있었고 둘 다 후보입니다.

utmp에서 자기 항목만 제거하기

공개된 우회 방법은 사용하려는 세션을 클라이언트 시작 전에 utmp 에서 보이지 않게 만듭니다. 작은 C 프로그램이 getutent() 을 순회하며 ut_line 이 표준 입력의 TTY와 같은 레코드를 찾아 그 레코드를 다시 씁니다. 순서는 의도적입니다. setutent(), 항목 읽기, ut_id 복사, ut_type 를 DEAD_PROCESS 로 설정, 사용자와 라인 필드 비우기, pututline() 로 다시 쓰기, 그다음 endutent().

컴파일한 뒤 클라이언트를 시작할 셸에서 루트로 실행하세요:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

도구가 아무 일도 하지 않는다는 대부분의 보고에는 두 가지 실패 모드가 있습니다. 표준 입력에 연결된 TTY에 작용하므로 터미널이 없는 스크립트나 크론 작업에서 실행하면 맞출 대상이 없습니다. 그리고 /run/utmp 는 일반 사용자가 쓸 수 없으므로 루트가 아닌 실행은 종료 상태를 확인하지 않는 한 조용히 실패합니다.

터널이 닫힘을 견디는지 확인하기

메커니즘을 가정하지 말고 시험하세요. 계속 유지할 세션에서 연결하고, 두 번째 터미널을 열고, 그 두 번째를 닫은 다음 vpn state 와 인터페이스 목록으로 터널이 여전히 올라와 있는지 확인하세요. 터널이 살아남으면 트리거는 모든 세션이 아니라 특정 유형의 세션이었고, 계속 열어 둬야 할 세션을 찾은 것입니다.

그래도 끊긴다면 감시 대상 세션은 다른 곳에 있었습니다. 대개 터미널을 만든 그래픽 로그인이며, TTY 항목 하나를 걷어내는 것으로는 해결되지 않습니다. 더 많은 수술을 하기보다 첫 단계의 전체 목록으로 관찰을 반복하세요.

utmp 재작성이 잘못된 답일 때

utmp 은 공유 회계이지 개인용 표가 아닙니다. 아직 살아 있는 세션의 항목을 다시 쓰면 who, w 및 일부 감사 도구가 그 세션을 적게 보고하고, 나중에 같은 항목을 닫는 프로그램은 아예 실패할 수 있습니다. 도구를 자기 세션으로만 한정하고, 원본 파일 사본을 보관하고, 모든 레코드를 지우는 부팅 서비스로 만들지 마세요.

조직이 규정 준수를 위해 세션 회계를 수집한다면 이 우회 방법은 그 요구와 충돌하며, 지원되는 답은 클라이언트 버전이나 다른 접속 방식이지 패치된 utmp 이 아닙니다. 대부분에게 가장 덜 침습적인 해결책은 하루 종일 열어 둘 세션에서 클라이언트를 시작하고 그 창을 건드리지 않는 것입니다.

티켓을 닫기 전에 터널이 올라올 때 클라이언트가 어느 세션을 감시하고 있었는지 기록하세요. 그 한 줄이 신비한 끊김을 다음 사람이 재현할 수 있는 조건으로 바꿔 줍니다.