정적 키 OpenVPN 링크가 여러 클라이언트를 처리할 수 있습니까?

정적 키 모드는 정확히 두 피어를 연결하며 이것은 설계이지 누군가 풀지 않은 제한이 아닙니다. client-to-client 는 서버 모드의 전달 옵션이므로 --secret 설정에 추가해도 연결할 수 있는 클라이언트 수는 달라지지 않습니다. 결정할 것은 어떤 플래그를 넣을지가 아니라 배포에 지점 간 링크가 필요한지 다중 클라이언트 서비스가 필요한지입니다. 여러 장치가 독립적으로 연결해야 한다면 보호 모드가 바뀌고 각 장치에 ID 가 부여됩니다.

두 피어, 하나의 키, 클라이언트별 상태 없음: 그 형태가 이 모드의 전부입니다.

정적 키 모드는 무엇을 위한 것인가

비밀 모드에서는 두 피어가 하나의 키 파일을 공유하고 그 키가 트래픽을 직접 보호합니다. 핸드셰이크도, 인증서 교환도, 클라이언트별 세션도 없는데, 서버 의미의 클라이언트가 없고 두 엔드포인트만 있기 때문입니다.

이 모드는 키 교체 절차가 문서화된 고정된 두 대의 장치에는 여전히 유용하며, OpenVPN 2.6 이 이를 폐기 예정으로 표시하는 이유는 TLS 모드가 그런 경우를 더 나은 속성으로 포괄하기 때문입니다. 이 모드가 할 수 없는 것은 연결하는 한 장치를 다른 장치와 구별하는 일이며, 파일 소유가 인증의 전부이기 때문입니다. 세 번째 장치를 추가한다는 것은 같은 키를 그것과 공유한다는 뜻이고, 그러면 처음 두 장치는 그것을 자기들과 구별할 수 없게 됩니다.

그래서 두 피어 한계는 구조적인 것이지 바꿀 수 있는 설정이 아닙니다.

client-to-client 가 빠진 조각이 아닌 이유

client-to-client 는 연결된 클라이언트가 서버를 통해 트래픽을 교환할 수 있는지 제어합니다. 그것은 클라이언트를 받아들이지도, ID 를 부여하지도, 설정되지 않은 서버 모드를 만들지도 않으며, 정적 키 설정에는 그것이 관리할 클라이언트 목록이 없습니다.

또 다른 흔한 혼동은 tls-crypt 나 tls-auth 자료에 관한 것입니다. TLS 서버는 그런 키 하나를 모든 클라이언트와 공유할 수 있는데, 각 클라이언트가 누구인지 증명하는 대신 제어 채널을 보호하기 때문입니다. TLS 모드의 공유 제어 채널 키는 공유 정적 데이터 키와 다른 객체이며, 둘 다 비슷하게 보이는 파일로 도착할 뿐입니다.

모드 선택은 두 질문으로 좁혀집니다. 하나 이상의 장치가 독립적으로 연결되어야 하는지, 배포에 장치별 폐기가 필요한지입니다. 둘 다 아니면 정적 키 모드는 유효하고, 둘 중 하나라도 필요하면 TLS 를 가리킵니다. 고유 ID 없이 두 번째 클라이언트를 받아들이는 세 번째 선택지는 없습니다.

다중 클라이언트 서버 구축

다중 클라이언트 서버에는 TLS 모드, 서버 측 인증서, 클라이언트별 ID 가 필요합니다. 서버 도우미는 주소 풀과 다중 클라이언트 모드를 설정하지만, TLS 구성이나 신뢰 앵커, 수용을 의미 있게 만드는 클라이언트 인증서는 제공하지 않습니다.

한 클라이언트의 자격 증명을 복사하는 대신 기존 인증 기관을 통해 각 장치를 등록하십시오. 서로 다른 ID 가 있어야 폐기, 클라이언트별 라우팅, 유용한 로그가 가능해지며, 공유 클라이언트 인증서 하나가 그 셋을 모두 무너뜨립니다.

배포가 외부 디렉터리나 두 번째 요소로 사용자를 인증한다면 그 설계는 그대로 둡니다. TLS 서버 모드로 전환하는 것은 피어가 터널 계층에서 자신을 어떻게 증명하는지를 정할 뿐 계정 백엔드를 규정하지 않습니다. 두 결정을 분리해 두어 한쪽의 변경이 다른 쪽을 조용히 바꾸지 않게 하십시오.

그다음 전달 정책을 의도적으로 결정하십시오. client-to-client 는 사용자 공간 서버 경로에서 클라이언트 간 트래픽을 활성화하며, 많은 배포가 원하고 일부는 가져서는 안 됩니다. 이것은 정책 스위치이지 ID 메커니즘이 아니며, 튜토리얼에 있었기 때문이 아니라 설계가 요구하기 때문에 켜야 합니다.

클라이언트가 실제로 독립적인지 확인

두 클라이언트를 연결해 서로 다른 주소를 받고 서버 로그에 서로 다른 ID 로 나타나는지 확인한 뒤, 하나를 폐기하고 다른 하나가 계속 작동하는지 확인하십시오. 이것이 ID 가 공유되지 않았다는 실용적 시험입니다.

허용된 피어 간 서비스와 차단된 채로 남아야 하는 서비스를 시험하십시오. 두 번의 성공적인 로그인은 수용을 증명할 뿐 격리를 증명하지 않으며, 배포가 사용자 그룹을 분리해야 할 때 이 차이가 중요합니다.

마지막으로 서버 모드는 기억이 아니라 실행 중인 구성에서 읽으십시오. 추가 옵션이 있는 정적 키 구성도 여전히 지점 간 링크이며, 올바른 TLS 서버만이 여러 클라이언트가 실제로 별개의 피어가 되는 유일한 구성입니다.

로그가 모든 장치에 같은 공통 이름을 보여 준다면 문제는 모드가 아닙니다. 문제는 등록 절차입니다.