사이트 VPN을 위해 두 사이트에 같은 VLAN ID가 필요한가?

두 사무실의 VLAN 번호가 같으면 사이트 간 터널에 도움이 될 것처럼 느껴지지만, 터널이 실어 나르는 것은 아무것도 바꾸지 않는다. VLAN ID는 한 건물 안의 Ethernet 브로드캐스트 도메인에 표식을 붙이는 것이고, 터널은 게이트웨이 사이에서 IP 패킷을 전달한다. 두 사이트가 전혀 다른 VLAN 번호 체계를 쓰고도 서로 라우팅될 수 있고, 두 사이트가 같은 VLAN 번호 체계를 쓰고도 서로 도달하지 못할 수 있다. 도달 가능성을 결정하는 변수는 주소 계획이다.

신화: 양쪽 끝의 같은 VLAN ID

이 믿음은 합리적인 곳에서 나온다. 한 건물 안에서는 같은 VLAN의 두 포트가 통신할 수 있고 다른 VLAN의 두 포트는 그럴 수 없으므로, VLAN 번호가 연결성을 부여하는 것처럼 보인다. 라우팅된 터널 너머에는 태그가 설명할 공유 Ethernet 세그먼트가 없고, 게이트웨이는 VLAN 레이블을 주고받지 않는다.

터널에 필요한 것은 겹치지 않는 두 주소 범위와 그 사이의 트래픽을 허용하는 정책이다. 어느 사무실에서든 VLAN을 바꿔도 터널은 계속 동작한다. 터널 구성 어디에서도 그것을 참조하지 않았기 때문이다. 이것이 논쟁을 끝내는 시험이다. VLAN 번호를 다시 매기고 주소는 그대로 둔 채 터널이 유지되는지 보라.

반대 시험도 마찬가지로 유익하다. 두 사무실에 같은 서브넷을 주면, 같은 VLAN 번호를 아무리 맞춰도 주소가 모호하지 않게 되지는 않는다.

터널이 실제로 실어 나르는 것

IPsec은 주소, 프로토콜, 포트로 표현된 정책에 따라 IP 패킷을 보호한다. IPsec 아키텍처 스위치 태그가 설명하는 모든 것보다 몇 계층 위인 IP 계층에서 그 선택자들을 설명한다. 패킷이 터널로 들어갈 때는 이미 VLAN을 떠난 뒤이며, 태그는 로컬 스위치가 소비한 상태다.

정책 기반과 경로 기반 설계는 터널을 고르는 방식에서 다르지, 실어 나를 수 있는 것에서 다르지 않다. 정책 기반 피어는 트래픽 선택자를 일치시키고 일치하는 패킷을 터널로 보낸다. 경로 기반 피어는 터널 인터페이스에서 트래픽을 라우팅하고 결정을 라우팅 테이블에 맡긴다. 둘 다 여전히 보호 범위를 협상하므로, 터널을 가리키는 경로가 피어가 보호하기로 합의한 범위를 넓히지는 않는다.

이 구분은 흔한 절반의 실패를 설명한다. 경로는 있고 패킷은 터널로 들어가지만, 협상된 선택자에 그 프리픽스가 결코 포함되지 않았기 때문에 먼 쪽이 패킷을 버린다. 설치된 정책을 읽으면 어느 범위가 실제로 효력을 발휘했는지 알 수 있다.

ip xfrm policy
ip route show
swanctl --list-sas

실제로 깨뜨리는 겹침

서로 다른 서브넷을 가진 두 사무실은 터널을 통해 깔끔하게 라우팅되고, 그 VLAN 번호는 무관하다. 같은 서브넷을 가진 두 사무실은 그렇지 않다. 특정 주소에 대한 요청이 두 가지 의미를 가질 수 있고 라우팅 테이블은 하나만 고를 수 있기 때문이다. 한 사이트의 번호를 다시 매기는 것이 깔끔한 해결책이며, DNS와 방화벽 변경까지 세면 대개 대안보다 저렴하다.

번호를 다시 매길 수 없을 때는 의도적인 변환 설계로 각 측에 서로 다른 주소 뷰를 제시할 수 있다. 그것은 일대일 매핑, 일치하는 선택자, 변환된 뷰를 반영하는 DNS 항목, 재작성을 견디는 반환 라우팅을 뜻한다. 실제 운영 비용이 드는 지원되는 설계이며, VLAN ID를 바꾸는 일이 하는 것은 그것이 아니다.

양쪽 끝의 같은 VLAN 번호는 때때로 공유 템플릿의 우연이고, 그 우연을 동작하는 터널의 원인으로 취급하면 나중에 무언가 깨질 때 잘못된 변경으로 이어진다.

계층마다 하나의 일, 문서로

로컬 스위치는 어느 포트가 브로드캐스트 도메인을 공유하는지 결정하고, 그 VLAN 번호 체계는 다른 어떤 사이트도 알 필요가 없는 로컬 장부다. 게이트웨이는 피어를 인증하고 협상된 보호 범위를 강제한다. 라우팅 테이블은 복호화된 패킷이 다음에 어디로 갈지 결정하고, 접근 정책은 그 패킷이 애초에 허용되어야 했는지 결정한다.

이 일들을 분리해 두는 것이 변경을 안전하게 만든다. 한 사무실의 VLAN 번호 재지정은 로컬 스위치, DHCP 범위, 어쩌면 방화벽 영역에 닿고 터널에는 닿지 않는다. 프리픽스 변경은 터널 선택자, 양쪽 경로, 접근 정책에 닿고 스위치 태그에는 닿지 않는다.

반환 경로, 사설 DNS, 애플리케이션 ID 요구는 다시 별개의 일이며, 어느 것도 다른 사이트에서 VLAN 번호를 복사해서 오지 않는다. 도달 가능한 프리픽스와 허용된 서비스를 나열한 설계 문서는 스위치 교체를 견디지만, VLAN 번호를 나열한 문서는 그렇지 않다.

태그가 터널에 도달한다고 가정하기 전에 브리지 도구로 로컬 상황을 확인하라.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

layer-2 확장이 진짜 요구 사항일 때

일부 설계는 사이트 간에 실제로 Ethernet 동작이 필요하다. 브로드캐스트 탐색에 의존하는 레거시 애플리케이션, 머신이 이동하는 동안 주소를 유지해야 하는 마이그레이션, layer-2 가정을 내장한 프로토콜 같은 경우다. 그런 경우에는 프레임을 실어 나르는 오버레이나 브리지 서비스가 필요하고, 그러면 VLAN 멤버십, 루프 방지, 장애 처리가 종단 간 문제가 된다.

그것은 훨씬 큰 장애 도메인이며, 파일 공유를 동작시키려는 시도의 우연한 결과가 아니라 의도적인 선택이어야 한다. 평범한 파일 서버, 데이터베이스, 웹 애플리케이션에는 승인된 IP 경로가 필요하고, 그 아래에 늘어난 브로드캐스트 도메인이 없을 때 더 행복할 것이다.

VPN 계약을 도달 가능한 프리픽스와 허용된 서비스로 적고, VLAN 레이블은 로컬 운영이 필요로 하는 곳에만 기록하라. 그러면 각 사무실은 모든 변경을 터널 재설계로 만들지 않고도 자체 스위칭 번호를 다시 매길 수 있다.