TAP 서버 하나일까 여러 개일까? 브리지 위의 OpenVPN 클라이언트

여러 TAP 클라이언트에 각각 하나의 서버 프로세스, 하나의 UDP 포트, 호스트의 TAP 장치 하나가 필요한 것은 아닙니다. 이더넷 모드의 OpenVPN 서버 하나가 다수의 인증된 클라이언트를 받아들여 단일 브리지에 연결할 수 있으며, 이것이 계층 2 세그먼트를 확장하는 문서화된 방법입니다. 단일 프로세스 설계는 매뉴얼이 문서화한 방식이며 보통 올바른 기본값입니다.

진짜 질문은 그 클라이언트들이 그 세그먼트를 공유해야 하는가이며, 프로세스 수는 이에 답하지 못합니다. 격리 속성은 토폴로지에서 나오며 데몬이 몇 개 실행되는지와는 무관합니다. 이 비교의 나머지는 두 토폴로지와 각각이 무엇을 쉽게 만드는지에 관한 것입니다.

두 가지 아키텍처, 두 가지 설정이 아니다

라우팅 TUN 배포는 각 클라이언트에 서버의 라우팅 도메인으로 향하는 지점 간 링크를 제공합니다. 브로드캐스트는 서버에서 멈추고, 클라이언트는 서로의 프레임을 볼 수 없으며, 클라이언트 간 트래픽이 있다면 명시적으로 라우팅하고 필터링해야 합니다.

브리지 TAP 배포는 클라이언트를 하나의 이더넷 세그먼트 구성원으로 만듭니다. 브로드캐스트를 보게 되고 ARP로 서로를 찾을 수 있으며, 분리를 유지하기 위해 라우팅이 아니라 브리지와 방화벽 정책에 의존합니다. 클라이언트가 같은 스위치에 연결된 것처럼 보여야 할 때 유용합니다.

따라서 비교는 클라이언트가 무엇에 도달해야 하는지에 관한 것이지 성능에 관한 것이 아닙니다. 먼저 계층을 고르고, 그다음 그것을 몇 개의 프로세스가 담당할지 정하세요.

server-bridge 도우미가 하는 일

server-bridge 도우미는 다중 클라이언트 이더넷 모드를 구성합니다. 주소 풀 형식은 게이트웨이, 넷마스크, 브리지된 서브넷 안의 전용 범위를 받으며, 예를 들어 게이트웨이는 192.168.50.1, 풀은 192.168.50.160부터 192.168.50.199까지입니다.

그 범위는 다른 어떤 DHCP나 정적 할당과도 겹치지 않게 예약하십시오. 도우미는 그 범위에서 주소를 할당하지만 같은 세그먼트의 다른 할당자와 조정하지 않으며, 겹치는 두 풀은 무작위 연결 장애처럼 보이는 중복 주소를 만들어냅니다. 예약한 범위를 사이트 주소 계획에 적어 다음 사람이 재사용하지 않게 하십시오. 서버 구성의 주석은 그 기록을 대신하기에 부족합니다.

외부 서버가 주소를 배포하는 환경을 위한 DHCP 프록시 형식이 있습니다. 여기에는 나름의 전제 조건이 있으며, 두 형식을 섞으면 문서가 경고하는 바로 그 충돌이 발생합니다. 브리지된 서브넷에는 할당자를 하나만 고르십시오.

격리는 프로세스 수에서 오지 않는다

같은 제한 없는 브리지에 연결된 여덟 개의 OpenVPN 프로세스도 여전히 하나의 브로드캐스트 도메인을 공유합니다. 클라이언트는 브리지를 넘어 서로에게 ARP를 보낼 수 있고, 리스너 수는 그 점을 바꾸지 못했습니다.

클라이언트 그룹이 계층 2에서 서로를 보지 않아야 한다는 요구라면, 설계에는 별도의 브리지나 VLAN 연결과 그에 따르는 접근 규칙이 필요합니다. 이는 네트워크 설계 결정이며, 서버 프로세스가 하나든 여덟이든 같은 결정입니다. 브리지 필터링은 일부 트래픽을 제한할 수 있지만 별도의 브로드캐스트 도메인을 만들지는 않습니다. 세그먼테이션의 보완으로 다루고 대체로 보지 마십시오.

클라이언트가 특정 IP 서비스에 도달하기만 하면 된다면, 라우팅 TUN 설계가 보통 브리지와 필터링보다 단순합니다. 각 클라이언트는 자체 링크를 얻고, 정책은 브리지 내부가 아니라 라우팅과 방화벽 규칙에 있습니다.

여러 프로세스가 여전히 옳은 경우

별도 프로세스는 서로 다른 인증 백엔드, 서로 다른 인증 기관, 별도의 업그레이드 주기, 또는 호환되지 않는 옵션 집합이라는 운영 요구로 정당화될 수 있습니다. 이는 실제 이유이며 클라이언트 수와 무관합니다.

여러 개를 쓴다면 각자 자신의 리스너와 장치 소유권을 주고 주소 범위를 조정하십시오. 같은 브리지에서 같은 풀을 자기 것이라고 믿는 두 서버는 결국 같은 주소를 내주게 됩니다.

그다음 여러 클라이언트로 동시에 설계를 검증하십시오. 주소가 고유한지, 의도한 클라이언트 간 트래픽이 동작하는지, 통신해서는 안 되는 쌍이 실제로 통신할 수 없는지 확인하십시오. 클라이언트 하나의 성공적인 ping은 다중 클라이언트 설계의 무엇도 시험하지 않습니다.

다이어그램을 믿기 전에 실행 중인 호스트에서 브리지와 서버 모드를 읽으십시오. 중요한 구성은 커널과 데몬이 실제로 읽어 들인 것이며, 검토자가 확인할 수 있는 것도 바로 그것입니다.