클라이언트 훅일까, 서버 훅일까? OpenVPN 스크립트가 실행되는 곳

과제는 분명합니다. 노트북이 연결되면 노트북에서 무언가가 바뀌어야 한다는 것입니다. 하지만 편집하는 설정은 서버의 것이고, 바로 이 지점에서 가정이 깨집니다. 서버 파일에 적힌 경로는 그 서버 위의 파일을 가리키며, 아무리 push해도 어느 프로세스가 그것을 실행하는지는 바뀌지 않습니다. 두 훅 중 하나를 고르는 일은 대개 어느 기계가 작업을 소유하는지 정하고, 그에 따르는 한계를 받아들이는 문제입니다.

두 대의 기계, 먼저 답해야 할 두 가지 질문

상태 변화가 어디에서 일어나야 하는지 묻고, 그다음 어떤 이벤트가 그것에 해당하는지 물으세요. 변화가 사용자별 권한 부여나 클라이언트별 설정 결정이라면 사용자 디렉터리를 아는 곳, 즉 서버에 속합니다. 변화가 경로라면, resolver 설정이나 엔드포인트의 로컬 보조 도구라면 엔드포인트에 속하며, 엔드포인트만이 그것을 할 수 있습니다.

이 두 질문을 반대 순서로 답하는 것이 사람들이 Windows 노트북에 배치 파일을 push하려는 결말로 이어집니다. 서버는 누가 연결했는지 알고, 노트북은 자기 네트워크 스택이 어떤지 압니다. 어느 쪽도 상대의 정보를 갖지 않으며, 그 시도는 대개 분명한 오류 대신 조용히 실패합니다.

둘보다 먼저 세 번째 질문을 던질 만합니다. 플랫폼이 애초에 원하는 훅을 제공하는가? 설정을 스스로 생성하는 어플라이언스는 같은 이벤트 이름을 제공하지 않을 수 있고, .ovpn 파일을 가져오는 데스크톱 클라이언트가 그 파일이 작성된 클라이언트와 같다는 보장은 없습니다. 플랫폼을 먼저 확인하면 거기에 없는 훅을 둘러싸고 설계하는 일을 피할 수 있습니다. 또한 앞에 있는 기계에 어떤 문서가 실제로 적용되는지도 알려 줍니다.

서버 측 선택지: 연결마다 하나의 이벤트

client-connect 스크립트는 인증된 클라이언트가 연결할 때 서버 프로세스 문맥에서 실행되며, common name과 할당된 주소 같은 문서화된 연결 세부 정보를 받습니다. 클라이언트별 설정 조각을 쓰고, 정책 결정을 강제하고, 서버가 소유한 상태를 기록하기에 알맞은 자리입니다.

사람들이 놓치는 구분은 그 훅과 서버의 up 훅 사이의 차이입니다. up 훅은 서버가 터널 장치를 열 때 발동하며, 다중 클라이언트 서버에서는 데몬 시작 시 한 번 일어납니다. 로그인마다 일어나는 이벤트가 아니며, 거기에 둔 코드는 사용자가 연결할 때가 아니라 서비스가 시작할 때 실행됩니다.

웹 인터페이스가 있는 어플라이언스에서는 생성된 데몬 파일을 편집하는 대신 지원되는 확장 메커니즘을 사용하세요. 생성된 파일은 다음 저장 때 다시 쓰이며, 그 다시 쓰기가 최악의 순간에 변경 사항을 조용히 지웁니다. 확장 텍스트 사본을 어플라이언스 밖에 보관하면 펌웨어 업데이트로 의도까지 잃지 않습니다.

클라이언트 측 선택지: 로컬에서 실행되어야 하는 작업

커뮤니티 클라이언트는 터널 장치가 올라올 때와 경로가 설치될 때 로컬 스크립트를 실행할 수 있습니다. 이 둘은 서로 다른 시점이며, 잘못된 쪽을 고르면 보조 도구가 의존하는 경로가 존재하기 전에 시작하는 전형적인 경쟁이 생깁니다.

보조 도구는 그 클라이언트에 존재해야 하고, 클라이언트를 실행하는 계정으로 읽고 실행할 수 있어야 하며, 명시적인 script-security 설정으로 허용되어야 합니다. 관리자로 클라이언트를 실행할 때 동작하는 스크립트는 로그인 전 서비스나 다른 사용자의 세션에 대해 아무것도 알려 주지 않습니다.

이름도 중요합니다. up 훅은 장치 생성에, route-up은 경로 설치에 해당하지만, 사설 네트워크에 도달할 수 있어야 하는 작업은 장치 생성이 모든 경로와 resolver 항목, 애플리케이션이 준비되었다는 뜻이라고 가정하지 말고 도달 가능성을 확인해야 합니다.

실행 가능한 코드를 push하는 것이 선택지에 없는 이유

push로 내려보내는 옵션은 의도적으로 제한되어 있고, 스크립트를 실행하는 옵션은 서버가 내려보낼 수 없는 범주에 속합니다. 이 제약이 있는 이유는 그렇지 않으면 침해되었거나 잘못 설정된 서버가 연결하는 모든 클라이언트에서 임의의 명령을 실행할 수 있게 되기 때문입니다.

로컬에서 스크립트 실행을 허용해도 그것은 달라지지 않습니다. script-security 설정은 여러분이 고른 로컬 스크립트를 허용할 뿐, 서버에 새 스크립트를 공급할 권한을 주지 않습니다.

목표가 단순히 VPN 경로를 설치하는 것이라면 원격 실행 방식을 고안하는 대신 지원되는 경로 설정을 사용하세요. 목표가 정말로 로컬 코드를 요구한다면 조직의 엔드포인트 관리 도구로 배포하고, 사용자 권한으로 실행되는 다른 소프트웨어처럼 검토하세요.

두 훅 중 무엇이든 신뢰하기 전에 확인할 것

훅마다 네 가지를 적으세요. 기계, 이벤트 이름, 실행되는 계정, 그리고 만들어 내야 하는 상태 변화입니다. 그다음 연결, 재연결, 정리 경로를 시험하세요. 재연결에서 상태를 흘리는 훅은 한 번도 실행되지 않은 훅보다 나쁩니다.

실제로 실행할 계정에서, 실제로 실행되는 순간에 시험하세요. openvpn(8) 매뉴얼은 두 훅 계열과 push 제약을 문서화하며, 배포하는 플랫폼은 그것들을 애초에 노출하는지 문서화합니다. 대화형 관리자 터미널에서 성공하는 스크립트는 가설이지 검증이 아닙니다.