OpenConnect vpnc-script: 어떤 파일이 실행되고 있나?

OpenConnect는 터널 핸드셰이크를 끝내고도 프라이빗 서브넷으로 가는 경로 없이 남겨둘 수 있습니다. 클라이언트와 로컬 네트워크 상태를 바꾸는 도우미가 서로 다른 프로그램이기 때문입니다. 인증이 증명하는 것은 게이트웨이가 세션을 받아들였다는 사실뿐이고, 그 뒤에 어떤 인터페이스와 경로, 어떤 리졸버 설정이 설치되었는지는 전혀 증명하지 않습니다. 혼란스러운 보고의 대부분은 오래된 답변에서 가져온 복사본으로 도우미를 바꾸는 데서 나오며, 그것은 머신의 모든 연결 동작을 바꿉니다. 어느 부분이든 편집하기 전에 실행 중인 클라이언트가 실제로 호출하는 도우미를 찾으세요.

두 프로그램, 두 책임

클라이언트는 전송, 인증, 터널 장치를 담당합니다. 별도의 도우미는 터널이 생긴 뒤 로컬 시스템에서 일어나는 일, 즉 인터페이스의 주소 설정, 게이트웨이가 알린 서브넷으로 가는 경로, 리졸버 구성을 담당합니다. OpenConnect 도우미 문서 는 그 분담과 도우미가 받는 환경을 설명합니다. 이 구분은 장애 때 중요합니다. 비밀번호 거부와 경로 누락은 데스크톱이 둘 다에 하나의 대화상자를 띄우더라도 같은 사건이 아닙니다.

이 분담을 염두에 두면 터널이 올라가 있는데도 프라이빗 이름이 여전히 해석되지 않는 이유도 설명됩니다. 두 경우 모두 터널은 동작하고, 다른 것은 로컬 통합 단계뿐입니다.

실행 중인 클라이언트가 쓰는 도우미를 찾기

경로는 패키지를 빌드할 때 정해지고 호출마다 덮어쓸 수 있으므로, 다른 배포판에서 기억하는 파일이 이 연결과 무관할 수 있습니다. 우연히 열어 둔 문서가 아니라 실행 중인 프로세스에 물으세요.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

프로세스 줄에 --script 인수가 있으면 그 파일이 컴파일된 기본값을 이깁니다. /etc/vpnc/vpnc-script 같은 오래된 경로는 존재하면서도 쓰이지 않을 수 있어서, 그것을 지우거나 고쳐도 최근 빌드에서는 아무것도 바뀌지 않습니다. 수정 날짜도 확인하세요. 몇 년 동안 아무도 손대지 않은 도우미는 패키지의 기본값이 일을 하고 있다는 강한 신호입니다.

NetworkManager 통합은 세 번째 소유자로, 자체 도우미와 자체 프로필 설정을 가집니다. 그 통합 위에 두 번째 경로나 리졸버 스크립트를 겹치면 경로가 중복되고, 두 프로그램이 모두 자기가 관리한다고 주장하는 리졸버가 남습니다. 연결마다 소유자를 하나 고르고 테스트 전에 다른 하나를 끄세요.

마지막 경고가 아니라 처음 실패한 작업을 읽기

인터페이스 구성, 경로 설치, 리졸버 선택, 오래된 상태 정리는 별개의 단계이고, 맨 마지막에 찍히는 경고는 연결을 끊은 장애가 아니라 정리 불평인 경우가 많습니다. 처음 실패한 구체적 작업까지 위로 읽으세요. 파일이나 주소를 지목하는 도우미 오류는 열 줄의 정리 소음보다 값집니다.

의도한 로컬 결과와 관찰한 결과를 비교하세요. 터널 장치가 있고, 알려진 프라이빗 주소로 가는 경로가 그것을 지나며, 리졸버가 프라이빗 이름에 응답하는지 봅니다. 처음 둘은 성공하고 셋째에서 실패하는 도우미는 라우팅이 아니라 리졸버 정책을 가리킵니다. 장치를 전혀 구성하지 않는 도우미는 실행되지 않았을 가능성이 크고, 그것은 네트워크가 아니라 권한 문제입니다. 로직을 다시 쓰기 전에 실행 비트와 서비스 계정을 확인하세요.

연결, 재연결, 연결 해제를 검증하기

설정은 계약의 절반일 뿐입니다. 같은 도우미가 터널이 닫힐 때 자기가 가진 상태를 복원하거나 제거해야 하기 때문입니다. 경로를 추가하고 절대 제거하지 않는 도우미는 세션보다 오래 남는 낡은 경로를 머신에 남깁니다.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

연결된 상태에서 처음 세 줄을 실행하고, 연결을 끊은 뒤 다시 실행해 경로와 리졸버 항목이 사라졌는지 확인하세요. 네 번째 줄은 도우미가 애초에 호출되었는지와 서비스가 어떤 실행 경로를 썼는지를 보여 줍니다. 그 두 출력을 티켓에 남기세요. 전후 비교가 정리 버그를 분명하게 만들기 때문입니다.

도우미를 패키지 상태로 두고 서비스 계정이 실행할 수 있게 유지하세요. 셸에서 도는 스크립트도 제한된 서비스 정책 아래에서는 거부될 수 있습니다. 정말로 사용자 정의가 필요하면 목적과 소유자를 기록하고 업그레이드마다 패키지 버전과 비교하세요. 설명 없는 도우미 포크는 일 년 뒤에 잘 동작하던 연결을 실패하게 만들 수 있는 몇 안 되는 것 중 하나입니다.