macOS 터미널에서 VPN 상태 확인: scutil, 라우트, 아니면 ping

배포 스크립트 어딘가에는 복사가 시작되기 전에 터널이 올라와 있는지 확인하는 부분이 있습니다. 쓸 수 있는 답은 세 가지이며 같은 뜻이 아닙니다. scutil가 보고하는 서비스 상태, 커널이 고른 라우트, 그리고 반대쪽 끝이 실제로 응답하는지 여부입니다. 이들을 비교하는 것이 곧 복사를 예측하는 확인과 로그만 꾸미는 확인의 차이입니다.

VPN이 올라와 있는지에 대한 세 가지 답

서비스 상태는 제어 평면의 사실입니다. macOS는 클라이언트 프로세스가 그렇게 말했기 때문에 구성이 연결되었다는 것을 압니다. 라우트는 데이터 평면의 사실입니다. 커널이 이 목적지를 그 인터페이스로 보냅니다. 도달 가능성은 종단 간 사실이며, 나머지 둘 중 어느 것도 보지 못하는 이유로 실패할 수 있습니다.

쓸모 있는 확인은 처음 둘을 결합하고 세 번째를 나머지 둘이 거짓말하지 않았다는 확인으로 씁니다. 어느 하나만으로는 타임스탬프가 붙은 추측일 뿐입니다.

표시 이름이 아니라 식별자를 읽으세요

scutil --nc list
scutil --nc status "Office"

목록은 서비스마다 한 줄을 출력하고, 각 줄에는 괄호 안의 상태와 이어서 서비스 식별자, 유형, 표시 이름이 담깁니다. 표시 이름은 누군가 시스템 설정에 입력한 값이고 예고 없이 바뀔 수 있으므로 식별자를 기준으로 스크립트를 작성하세요. 상태 명령은 단어 하나를 출력하고 일부 서비스 유형에서는 그 뒤에 통계가 붙습니다. 이름을 출력 전체에서 찾는 대신 그 첫 단어를 맞추세요. 이름은 다른 곳에도 나타납니다.

서비스를 시작하면 권한 요청이 뜨거나 프로필이 관리되는 경우 곧바로 거부될 수 있습니다. 그 거부는 터널의 결함이 아니며, 누가 그것을 올릴 수 있는지에 대한 정책 선언입니다.

서드파티 클라이언트는 목록에 보이지 않습니다

목록이 비어 있다고 VPN이 없는 것은 아닙니다. 시스템 자체의 네트워크 설정에서 만든 구성은 여기에 나타나지만, 공급업체 클라이언트, 관리 프로필, 서드파티 앱은 이 명령이 절대 보지 못하는 활성 터널을 유지할 수 있습니다. 자기 서비스에 대한 권위는 자기 도구입니다. 자기에게 한 번도 등록하지 않은 클라이언트를 scutil에 물으면 아무것도 돌아오지 않으며, 아무것도 돌아오지 않는 것은 연결 끊김과 같은 답이 아닙니다.

목록이 비어 있는데 트래픽이 분명히 암호화되어 있다면 인터페이스를 찾으세요. 예상 범위의 주소를 가진 utun 또는 ppp 장치가 무언가 터널을 세웠다는 증거입니다. 이는 서비스 상태보다 약한 신호이므로 인터페이스를 신원의 증거로 취급하는 대신 라우트 확인과 함께 쓰세요. 여러 클라이언트가 여러 그런 인터페이스를 만들 수 있고, 그중 하나만 의도한 터널에 속합니다.

상태는 라우팅이 아닙니다

연결된 서비스는 터널이 존재한다고 말합니다. 목적지가 그것을 쓴다고는 말하지 않습니다. 주소를 읽고 나서 커널에 직접 물으세요.

ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20

전체 터널 클라이언트는 터널을 통과하는 기본 라우트를 넣고, 분할 터널 클라이언트는 특정 사설 프리픽스를 넣습니다. 둘 다 Connected를 보고하며, 상태만 확인하는 스크립트는 거리낌 없이 잘못된 경로로 달립니다. 터널을 멈춘다고 다른 클라이언트가 넣은 라우트가 반드시 사라지는 것은 아니며, 그것이 한 기계가 연결된 서비스와 오래된 라우트를 동시에 갖게 되는 한 가지 경로입니다. 관심 있는 목적지를 보세요. 라우트 테이블 전체가 아니라.

이름 붙이기는 별개의 문제입니다

주소는 통하는데 다른 기기가 이름으로 Mac에 닿지 못하는 일은 VPN 결함으로 보고됩니다. 로컬 호스트 이름, 호스트 이름, DNS 레코드는 서로 다른 세 가지입니다. scutil --get LocalHostName은 Bonjour 이름을 보여 주고, sudo scutil --set HostName mac-office은 시스템이 보고하는 이름을 설정합니다.

어느 설정도 사무실 영역에 레코드를 만들지 않습니다. 다른 호스트가 DNS로 이름을 해석해야 한다면 영역 소유자가 레코드를 추가해야 하고, 그렇지 않으면 스크립트가 주소를 써야 합니다. 안정적인 이름을 설정하면 알림이 일관되지만 리졸버가 답하게 되지는 않습니다.

스크립트에 서비스 식별자와 예상 라우트 형태를 함께 기록하고, 복사 전에 둘 다 확인하세요. 올라와 있지만 엉뚱한 방향으로 라우팅된 터널은 터널이 없는 것과 똑같이 실패하며, Connected라고 적힌 로그 줄은 다음 사람을 잘못된 곳으로 보냅니다.