클라이언트 VLAN인가 태그된 트렁크인가: 올바른 OpenVPN 모드 고르기

거의 같은 표현으로 두 가지 요청이 들어옵니다. 모든 VPN 클라이언트를 지정한 VLAN에 넣거나, 기존 VLAN 트렁크를 VPN 너머로 전달하는 것입니다. 서로 다른 제품입니다. OpenVPN에 내장된 VLAN 인식 모드는 첫 번째 요청을 위한 스위치 모델이며, 투명한 태그 전송의 동의어가 아닙니다. 잘못 고르면 설정된 것처럼 보이지만 정작 중요한 프레임을 조용히 버리는 설계가 됩니다.

VLAN 인식 모드가 실제로 만드는 것

서버 전용 TAP 배포에서 vlan-tagging을 켜면, 데몬은 자신의 TAP 장치와 연결된 각 클라이언트를 내부 스위치의 포트로 모델링합니다. 클라이언트 포트는 태그가 없고, 그 VLAN 연결은 서버에서 클라이언트별 vlan-pvid 컨텍스트로 설정되며, 클라이언트가 보내는 내용으로 정해지지 않습니다. 이것이 모델의 핵심입니다. 소속은 인증된 상대에 대해 서버 쪽이 내리는 결정입니다. 클라이언트 프로필에는 자신이 어느 VLAN에 속하는지 알 필요가 없습니다.

서버의 TAP 쪽은 vlan-accept을 통해 태그 있음 또는 태그 없음 수용 정책을 따로 가집니다. 그 스위치 내부의 전달은 client-to-client이 설정된 경우에도 일치하는 VID 사이에서만 일어나므로, 서로 다른 VLAN에 있는 두 클라이언트는 둘 다 서버에 연결되어 있어도 서버를 거쳐 서로 도달할 수 없습니다.

그 모델은 액세스 포트 모델입니다. 클라이언트에서 나가는 프레임은 태그가 없고, 연결은 서버가 신원을 기준으로 부여합니다. 노트북에 자기 트래픽을 스스로 태그하라고 요구하는 것은 다른 설계를 요구하는 일입니다.

할당은 클라이언트가 스스로 제시하는 값이 아니라 인증된 클라이언트 신원을 따라야 합니다. 할당을 빠뜨리는 것은 격리 상태도 아닙니다. 클라이언트는 기본 PVID로 떨어지므로, ccd 항목이 없는 것은 중립이 아니라 조용한 정책 결정입니다.

투명 트렁크가 대신 요구하는 것

이미 태그된 프레임을 끝에서 끝까지 나르려면 먼저 VLAN 인식 처리를 끕니다. 스위치 모델과 태그 보존은 서로 대안이며, 둘 다 켜는 것은 한 기능에 다른 기능의 일을 시키는 것입니다.

끄는 것은 시작일 뿐입니다. 각 끝의 브리지와 물리 스위치 포트는 어떤 VLAN이 허용되는지, 어떤 태그가 네이티브인지, 태그 없는 프레임을 어떻게 다루는지에 합의해야 합니다. 제한 없는 트렁크를 늘리면 연결하려던 두 개보다 훨씬 많은 브로드캐스트 도메인이 노출됩니다.

프레임 크기에는 별도의 예산이 필요합니다. 태그된 이더넷 프레임에 캡슐화를 더하면 안내서에서 복사하는 페이로드 수치보다 커집니다. 라우티드 터널에 맞던 MTU는 트렁크 경로가 작동한다는 증거가 아닙니다.

답을 결정하는 세 가지 조건

첫째, 클라이언트 플랫폼이 TAP을 지원합니까? Android와 iOS는 지원하지 않고 macOS 지원도 제한적이므로, 모바일 사용자가 많은 환경에서는 VLAN을 어떻게 배치하든 두 TAP 설계 모두 불가능합니다. 라우티드 TUN 세션은 이더넷 프레임이 아니라 IP 패킷을 나르며, 서버 쪽 VLAN 설정으로는 바뀌지 않습니다. 토폴로지를 설계하기 전에 사용 환경을 확인하십시오. 이 조건만은 우회할 수 없습니다. 스위치 작업이 끝난 뒤에야 발견되는 조건도 대개 이것입니다.

둘째, VLAN을 누가 할당합니까? 답이 «서버가 인증한 사람을 기준으로 할당»이라면 스위치 모델이 맞습니다. 답이 «이미 존재하는 태그로 기존 스위치 인프라가 할당»이라면 트렁크 설계가 필요합니다.

셋째, 네트워크의 어디까지 도달할 수 있어야 하는지입니다. 스위치 모델은 구조상 각 클라이언트를 하나의 VLAN에 둡니다. 트렁크 설계는 브리지이며, 잘못 설정된 브리지는 떨어져 있어야 할 브로드캐스트 도메인을 이어 붙입니다.

고른 설계를 시험하기

허용된 VLAN에 있어야 할 클라이언트와 그렇지 않은 클라이언트를 하나씩 연결한 뒤, 서버 자체가 아니라 실제 끝점에서 시험하십시오. 서버 쪽 도달 가능성은 브리지나 스위치가 존재함을 증명하지만, 클라이언트가 어느 VLAN에 떨어졌는지는 증명하지 않습니다.

ip -d link show tap0
bridge vlan show

서버에서 두 번째 명령은 각 브리지 포트의 VLAN 소속을, 포트가 태그되었는지 여부까지 보여 줍니다. 링크 계층보다 위를 디버깅하기 전에 의도한 할당과 비교하십시오.

배포가 두 설계 중 무엇을 쓰는지 기록하십시오. «VLAN 인식»이라는 메모는 모호하고, 다음 엔지니어는 자기가 먼저 배운 쪽을 전제합니다. OpenVPN VLAN 참조 문서는 스위치 동작과 클라이언트별 컨텍스트를 정의하며, 어떤 모델을 돌리는지 확인하는 가장 짧은 길입니다.