다양한 클라이언트에 대해 여러 OpenVPN 인스턴스를 설정하는 모범 사례

다양한 클라이언트에 대해 여러 OpenVPN 인스턴스를 설정하는 모범 사례

저는 다양한 고객의 IoT 장치를 중앙 서버에 연결하기 위해 OpenVPN 인스턴스를 설정해야 하는 프로젝트를 진행하고 있습니다. 각 클라이언트에는 자체 격리된 VPN 연결이 있어야 합니다. 현재 인프라 및 인증서 처리를 계획 중이며 최선의 접근 방식에 대한 조언을 듣고 싶습니다.

인증서 처리를 위해 다음 구조를 고려하고 있습니다.

CA.crt
|_Customer1.crt
|  |_ServerCert.crt
|     |_ClientCert1.crt
|     |_ClientCert2.crt
|     |_ClientCertX.crt
|
|_Customer2.crt
   |_ServerCert.crt
      |_ClientCert1.crt
      |_ClientCert2.crt
      |_ClientCertX.crt

/etc/openvpn/server/Client1/따라서 각 클라이언트에 대해 및 와 같은 별도의 OpenVPN 인스턴스를 설정하고 다음 /etc/openvpn/server/Client2/과 같은 명령을 사용하여 시작합니다.

sudo systemctl start [email protected] 이것이 허용되는 접근 방식입니까? 여러 VPN 클라이언트 및 서버를 위한 인프라 구성에 대한 통찰력이나 대안 제안에 감사드립니다.

추가 질문은 다음과 같습니다.

  • Ansible과 같은 수많은 분산 장치를 관리하는 방법은 무엇일까요?
  • 각 OpenVPN 인스턴스마다 추가 포트가 필요합니다.
    • 443 TCP,UDP 및 1194 TCP,UDP를 사용한 후 다음은 무엇입니까?

감사합니다!

답변1

OpenVPN 매뉴얼에는 구성한 CA 인증서의 하위 인증서를 신뢰한다고 명시되어 있습니다. 따라서 VPN을 실제로 분리하려면 모든 구성에서 루트 인증서를 생략합니다. 어디에도 사용되지 않고 가치나 이점도 추가되지 않는데 왜 굳이 유지해야 할까요? EasyRSA를 사용하여 각 VPN에 대해 별도의 독립적인 "루트, 단일 수준" CA를 생성하세요.

왜 여기에 포트 443을 나열했는지 모르겠습니다. 잘 알려진 HTTPS 포트이고 자주 사용되기 때문에 OpenVPN에는 거의 사용되지 않으므로 사용 시 port-share. 이 경우 sslh데몬이 "투명 모드"를 사용하여 원격의 실제 IP를 볼 수 있고 OpenVPN이 해당 정보를 사용 가능하게 만드는 방식에 신경 쓰지 않아도 되기 때문에 더 좋습니다. 귀하의 프로젝트에 이러한 특성이 필요한지는 의심스럽습니다. 그 외에는 실제로 임의의 포트 번호를 사용할 수 있습니다. 1194는 "공식"으로 나열되어 있지만 11941, 1195, 5000(15년 전에 제안됨) 등을 설정하는 것을 금지하는 것은 없습니다. 포트 세트를 선택하고(1194 이상으로 시작한다고 가정하고) 각 연속 VPN 인스턴스에 하나씩 추가하기만 하면 됩니다.

나머지는 정확합니다. 독립 데몬에 대해 별도의 (공용) 포트를 사용하고 이를 별도의 SystemD 장치로 실행합니다. 다양한 VPN에 대해 별도의 컨테이너를 고려하세요. 단일 네임스페이스에서 별도의 VPN 인스턴스를 실행하는 것이 가능하지만 이를 분할하는 것이 더 쉽고 오류 발생 가능성도 낮습니다(그리고 리소스를 많이 소비하지 않습니다). 제가 이해한 바와 같이 귀하의 고객은 관련이 없는 개체이므로 이를 분리하는 것이 더 간단한 방법이 될 것입니다. 이 경우 컨테이너 내부의 VPN 구성은 기본 포트를 사용할 수 있지만 이에 대해 다른 포트를 전달(게시)합니다.

VPN 관리 전용 시스템을 지정하십시오. CA를 저장하므로 인증서만 발급할 수 있습니다. 해당 시스템은 CRL을 발행하는 데에도 필요합니다. 기본적으로 CRL은 30일 동안 유지되며 구성하면 crl-verifyCRL이 만료되면 VPN은 다시 유효해질 때까지 새 연결 수락을 중지합니다. 따라서 실제로 자동화해야 할 것은 CRL 재발급 및 배포입니다. CRL 파일을 업데이트할 때 데몬을 다시 로드할 필요가 없으므로 scp이전 파일을 통해 대상 시스템을 간단하게 만드는 것만으로도 충분합니다.

OpenVPN 클라이언트 구성 파일 템플릿을 생성하고 해당 템플릿에 내장된 인증서를 사용하여 클라이언트 구성을 생성하는 것이 유용합니다. Ansible 없이도 많은 시간을 절약할 수 있었습니다. 나는 종종 번들 openssl.cnfvars파일을 사용자 정의하여 여러 필드를 추가하고 사용되지 않는 항목을 제거하고 항목을 재구성하여 더 적은 질문으로(또는 일괄 처리를 위해 질문 없이) 실행되도록 합니다. 귀하의 경우에는 새로운 VPN 및 서버 구성을 생성하기 위한 템플릿과 생성 스크립트를 갖는 것이 유용할 수 있습니다. 이러한 템플릿, 스크립트 및 사용자 정의는 신규 고객 또는 기존 고객의 새로운 IoT 장치를 인스턴스화하는 Ansible 플레이북에 유용합니다. 후자의 경우 인증서의 CN을 IoT 장치의 일련 번호에 연결하는 것이 좋을 수 있으므로 계산이 단순화됩니다.

관련 정보