OpenVPN push-peer-info: 접근 권한 없이 클라이언트에 레이블 지정

배포 태그는 사람들이 이 기능을 찾는 흔한 이유입니다: 각 연결이 사이트나 역할 같은 것을 지녀야 하고, 서버는 두 번째 자격 증명 형식을 새로 만들지 않고 그것을 읽어야 한다는 것입니다. 커뮤니티 OpenVPN에는 이미 그 메커니즘이 있고, 규모도 작습니다. 문제가 되는 부분은 기대치입니다. 클라이언트 프로필에 평범한 변수를 설정해도 서버에서는 아무 일도 일어나지 않으며, 도착한 값은 클라이언트가 보냈다는 것만 증명합니다.

이 글은 작동 경로, 실제로 무엇이 도착했는지 보여 주는 검증 단계, 그리고 반쯤 구성된 훅을 남기지 않는 롤백을 위한 런북입니다. 여기에는 새 인증서, 새 플러그인, 프로토콜 확장이 필요하지 않습니다.

변수를 설정하고 경로를 활성화하십시오

클라이언트 프로필에서는 두 줄이 일을 하며 둘 다 필요합니다. 첫 줄이 없으면 보낼 것이 없고, 둘째 줄이 없으면 클라이언트가 피어 정보를 아예 제공하지 않습니다. 순서는 중요하지 않으며, 이는 알아 둘 만합니다. 두 줄이 생성된 프로필의 서로 다른 위치에 들어가는 일이 많기 때문입니다. 중요한 것은 클라이언트가 읽기 전에 프로필을 다시 쓰는 무엇이든 두 줄이 살아남는 것입니다.

setenv UV_DEPLOY field-support
push-peer-info

UV_ 접두사는 장식이 아닙니다. 일반 DEPLOY 변수는 클라이언트 프로세스 안에 머물고 절대 전달되지 않지만, 접두사가 붙은 형식은 프로토콜이 사용자 정의 필드에 예약한 이름 공간입니다. 승인된 프로필의 나머지는 그대로 두고, 배포하기 전에 배포하는 클라이언트 빌드가 두 지시자를 모두 지원하는지 확인하십시오.

실용적인 점검 하나가 마지막이 아니라 여기에 들어갑니다. 지시자가 클라이언트 바이너리에 도달하고 래퍼에 삼켜지지 않는지 확인하십시오. 자체 명령 행을 생성하는 그래픽 클라이언트나 저장된 프로필을 다시 불러오는 관리 인터페이스는 인식하지 못하는 줄을 버릴 수 있습니다. 서버가 아무것도 보지 못한다면 가장 먼저 볼 곳이 여기입니다.

서버 훅에서 필드를 읽으십시오

서버 측에서는 받은 피어 정보가 검증되어 연결 워크플로의 환경에 삽입되며, 바로 그 점이 여러분 쪽의 프로토콜 작업 없이 훅에서 읽을 수 있게 합니다. 서버는 제어 채널을 해석하거나 여러분을 위해 무엇인가를 저장할 필요가 없습니다. 연결이 설정되는 동안 값은 그저 존재합니다. 인증된 이름 옆에 레이블을 기록하는 최소 client-connect 스크립트는 다음과 같습니다.

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

로그를 해석하는 대신 환경을 통해 변수를 읽고, 항상 기본값을 주십시오. ${UV_DEPLOY:-unset} 는 필드를 절대 보내지 않는 클라이언트에서도 스크립트가 계속 작동하게 하며, 이는 단계적 배포 중의 정상 상태입니다. 이름을 찾으려고 환경 전체를 로그에 쏟아붓지 마십시오. 레이블보다 훨씬 많은 것이 들어 있고, 보존할 생각이 없던 값까지 포함됩니다.

스크립트를 손으로 실행하면 모든 것에 대해 unset 이라고 보고합니다. 수동 셸은 연결 환경을 지니지 않기 때문입니다. 그것은 스크립트의 버그도 아니고 필드가 없다는 증거도 아닙니다. 변수가 존재하는 유일한 맥락인 실제 연결을 통해 시험하십시오.

실제로 무엇이 도착했는지 확인하십시오

레이블이 있는 클라이언트와 없는 클라이언트를 하나씩 연결한 다음 파일을 읽으십시오. 그 쌍이 시험입니다. 한 줄은 값을, 다른 줄은 기본값을 지녀야 하며, 둘 다 기대하는 같은 인증된 신원을 이름으로 밝혀야 합니다.

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

그 주석 줄들은 출력의 형태일 뿐 서버의 기록이 아닙니다. 자신의 파일을 읽으십시오. 둘째 클라이언트에도 값이 보인다면 변수는 환경의 다른 곳에서 설정된 것이며, 피어 필드가 아니라 오래된 설정을 읽고 있는 것입니다.

연결에 대해 서버 로그도 확인하십시오. 피어 정보가 거기에 나타날 수 있으며, 이는 디버깅에 편리하고 값을 지루하게 유지할 이유이기도 합니다. 사람 이름도, 티켓 번호도, 로그를 읽는 사람이 보면 곤란할 것도 넣지 마십시오.

레이블을 신원이 아니라 주장으로 다루십시오

클라이언트 프로필을 편집할 수 있는 사람은 누구나 태그를 바꿀 수 있으며, 터널이 인증되었다고 해서 태그가 권위를 갖는 것은 아닙니다. 전송은 이동 중인 값을 보호하지만 그 주장을 보증하지는 않습니다. 권한 부여는 여전히 인증된 신원과 서버가 소유한 등록 기록에 속하며, 필요한 때에는 레이블이 그 기록과 비교됩니다.

그 구분이 레이블을 어디에 쓸 수 있는지 결정합니다. 좋은 용도는 세션을 올바른 로그 파일로 보내는 것, 대시보드에서 표시 그룹을 고르는 것, 나중에 사람이 찾을 수 있도록 지원 세션에 표시를 남기는 것입니다. 나쁜 용도는 장치를 서브넷에 들이는 것, 방화벽 정책을 고르는 것, 세션이 어느 고객의 데이터를 읽을 수 있는지 정하는 것입니다.

값이 경로, 쿼리, 셸 명령에 도달하기 전에 검증하십시오. 예상 문자열의 허용 목록이면 배포 태그에는 충분하고 비용도 들지 않습니다. 피어가 제공한 문자열을 셸 명령 행에 절대 끼워 넣지 말고, 저장하는 관찰은 세션으로 한정하며 다음 클라이언트가 재사용할 터널 주소에 묶지 마십시오.

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

깔끔하게 되돌리십시오

기능을 제거하는 일은 두 번의 삭제와 한 번의 확인입니다. 클라이언트 프로필에서 setenv 및 push-peer-info 줄을 빼고, 그다음 서버에서 훅과 그 로그 대상을 제거하거나 비활성화하십시오.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

그 뒤 클라이언트 하나를 다시 연결하고 로그 줄이 더 이상 나타나지 않는지 확인하십시오. 프로필 변경 후에도 계속 실행되는 훅은 보통 테스트 장치에 아직 배포된 두 번째 프로필이며, 지금 찾는 편이 감사 중에 찾는 것보다 쌉니다.

마지막에 남는 것은 출처가 문서화된 작고 제한된 세션 메타데이터 조각입니다. 클라이언트가 주장하고, 서버가 기록하며, 접근에 관해 그 무엇도 그것에 의존하지 않습니다. 이것이 이 기능의 유용한 형태이며, 거기에 이르는 데 새 자격 증명은 필요하지 않습니다.