런북: 두 OpenVPN 고객을 별도로 온보딩하기

한 호스트에 두 고객을 두는 일은 서버 블록 하나와 두 번째 포트를 더하는 것처럼 들린다. 그러나 고객이 실제로 소유한 모든 것을 나열하면 다른 프로젝트가 된다. 리스너, 터널 풀, 아이덴티티, 신뢰 파일, 경로, 폐기 일정이다. 이 중 하나를 빠뜨리면 두 번째 고객은 첫 번째 고객의 일부를 조용히 물려받는다. 고객마다 카드를 만들고 첫 클라이언트가 연결하기 전에 채워 넣어라.

고객마다 완전한 리소스 카드를 배정하라

전체 세트를 함께 예약하라. 공용 포트, 터널 서브넷, 구성 경로, 로그 대상, 서비스 인스턴스 이름, 장치다. 이들을 하나의 그룹으로 이름 붙이는 것이 첫 고객의 풀이나 인터페이스를 그대로 담은 채 작동하는 파일을 복사하는 고전적 실수를 막는다. 값은 예시일 뿐 예약된 포트가 아니므로 호스트가 이미 쓰는 것을 확인하라. 서비스가 시작되는 것과 고객이 완성되는 것은 같지 않다.

카드를 구성 옆에 두고 값이 바뀔 때마다 갱신하라. 현실에서 벗어난 문서는 없는 것보다 나쁘다.

신뢰 자료를 각 고객 안에 두라

고객마다 별도의 발급 기관을 두면 경계를 생각하기 쉬워지고 서명 키를 인터넷에 노출된 호스트 밖에 둘 수 있다. 공유 루트도 작동할 수 있지만 공통 앵커가 두 서비스를 하나의 멤버십 도메인으로 만들지는 않는다. 각 리스너가 어떤 체인을 받아들이고 어떤 클라이언트 아이덴티티를 허용하는지 정하고 둘 다 기록하라. 무언가 연결될 때까지 시행착오로 체인에서 인증서를 떼어내지 마라.

서버 자체의 개인 키는 고객마다 보호된 파일에 속하며, 구성과 함께 복제되는 템플릿 디렉터리에 속하지 않는다.

프로세스뿐 아니라 네트워크도 분리하라

두 포트의 두 프로세스는 분리하지 않으면 여전히 하나의 호스트와 라우팅 테이블을 공유한다. 설계를 믿기 전에 무엇이 수신 중인지 확인하라.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

리스너 확인은 어느 프로세스가 각 공용 포트를 소유하는지 보여 주고, 검증은 클라이언트 인증서가 의도한 앵커로 연결되는지 보여 준다. 어느 출력도 A의 클라이언트가 B의 서브넷에 도달할 수 없음을 증명하지 않으므로 출발지와 목적지 정책, 반환 경로, 의도적으로 공유하는 서비스를 정의하라. 네트워크 네임스페이스나 컨테이너는 라우팅 컨텍스트를 분리하고 우발적 혼합을 줄이지만, 그것들만으로는 완전한 테넌트 경계가 아니다. 위협 모델이 요구하면 더 강한 격리 메커니즘을 선택하라.

인수인계 전에 폐기를 배포하라

폐기에 배포 경로가 없으면 인증서 배포는 완성되지 않는다. 온보딩의 일부로 CRL의 발급자와 유효 기간을 확인하라.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

CRL 검사는 목록이 언제 발급되었고 언제 만료되는지 보고하며, 서비스 상태는 그것을 읽는 인스턴스가 실행 중임을 확인한다. 새로 폐기된 것이 없어도 발급 정책의 일정에 따라 목록을 갱신하라. 만료된 CRL은 모든 클라이언트를 거부할 수 있기 때문이다. 읽는 사람이 부분 쓰기를 만나지 않도록 완전한 파일을 게시하고, 배포 전에 서명을 검증하라. 발급, 엔드포인트 운영, 퇴역의 소유자를 기록하여 A 고객 종료가 B를 방해하지 않게 하라.

그다음 승인 쌍을 실행하라. 허용된 클라이언트는 자기 서비스에 도달하고, A의 자격 증명은 B의 리스너에게 거부된다. 이것이 테스트로 표현한 경계다.