L2 VPN 대 L3 터널: 사이트를 브리지하기 전 다섯 가지 점검

도구가 같은 네트워크에 있어야 한다고 고집하기 때문에 사이트를 브리지하고, 삼 주 뒤에는 새벽 두 시에 스위치 로그를 읽고 있다. 그런 직감이 너무 많은 Ethernet-over-IP 링크를 결정한다. 여기서 정말 중요한 차이는 하나뿐이다: 프레임 전체가 끝에서 끝까지 이동하는지, 아니면 IP 패킷만 이동하는지다. 아래 다섯 가지 점검을 순서대로 수행하고 첫 번째로 실패하는 지점에서 멈추라.

애플리케이션이 실제로 무엇을 선로에 올리는지 점검하라

어떤 제품 이름이든 논의에 들어오기 전에, 링크를 넘어야 하는 트래픽을 일 분 동안 캡처하라: tcpdump -i eth0 -nn -e 'not ip'. 이 옵션은 -e 링크 계층 헤더를 출력하는데, 그것이 바로 라우티드 터널이 버리는 부분이다. 캡처가 비어 있으면 애플리케이션은 IP로 말하고 L3 터널은 그것을 그대로 전달한다. 프레임이 나타난다면 EtherType을 적어 두라, 왜냐하면 0x0806 은 ARP이고, 0x88cc 은 LLDP이며, 벤더 값은 대개 IP 대체 수단이 없는 탐색 프로토콜을 뜻한다. 바로 이 지점에서 평범한 tun 인터페이스로는 부족해진다.

먼 쪽에서도 캡처를 반복하라. 한 호스트의 가상 스위치 안에만 존재하는 프레임은 브로드캐스트 도메인을 WAN 너머로 늘릴 이유가 아니다.

탐색이 링크를 넘어야 하는지 점검하라

라우티드 터널에는 공유 세그먼트가 없으므로 그룹으로 향한 어떤 것도 반대편에 도달하지 않는다. ARP, DHCP 브로드캐스트, 224.0.0.251주소의 mDNS, SSDP, NetBIOS 이름 질의는 모두 여러 호스트가 동시에 들을 수 있는 링크를 전제한다.

애플리케이션이 그중 무엇에 실제로 의존하는지, 그리고 이미 프록시가 있는지 물어라. DHCP 릴레이, mDNS 반사, 정적 ARP 항목은 각각 하나의 의존성을 없애고, 각각은 운영하고 감시해야 할 또 하나의 서비스다. 두세 개가 남는다면 브리지가 정직한 답이다.

추가 헤더가 얼마나 드는지 점검하라

프레임은 살 곳이 필요하므로 보내는 모든 것에 두 번째 헤더 스택이 둘러진다. VXLAN 오버레이에서는 바깥 IP 헤더, UDP 헤더, 8바이트 VXLAN 헤더가 붙어, 꽉 찬 1,500바이트 페이로드가 평범한 1,500바이트 인터넷 링크의 경로 MTU를 넘어선다. OpenVPN tap 모드도 같은 방향으로 자체 오버헤드를 더한다. 내부 쪽 MTU를 낮추지 않으면 ping에는 응답하지만 첫 대형 전송에서 멈추는 링크가 된다.

청구서는 헤더 바이트에서 끝나지 않는다. 스위치가 하드웨어에서 처리하는 브로드캐스트와 멀티캐스트가 이제 WAN을 타고, 브리지된 모든 사이트는 같은 주소 계획, DHCP 범위, 중복 주소 동작을 물려받는다. 그래서 이 링크는 사이트마다 프리픽스 하나를 두는 라우티드 풀보다 감사하기가 훨씬 어렵다.

고르기 전에 계산하라. 세 사이트로 복제되는 바쁜 세그먼트는 그것을 만들게 한 파일 전송보다 더 많은 브로드캐스트 트래픽을 옮길 수 있다.

어떤 종류의 L2 VPN을 제안받는지 점검하라

용어 자체가 모호하고, 그 모호함이 누가 당신의 트래픽을 나르는지를 결정한다. 때로는 페이로드를 뜻한다: IP 안의 Ethernet 프레임을 다른 터널처럼 인터넷으로 보내는 것으로, VXLAN, ZeroTier, OpenVPN의 tap 모드가 그렇게 한다. 때로는 구매한 서비스를 뜻한다: 두 사이트를 한 사업자 망 안에서 잇는 캐리어 Ethernet 회선이나 MPLS 가상 회선이다.

둘 다 세그먼트를 주므로 애플리케이션은 구분할 수 없지만 운영상 차이는 크다. 오버레이는 MTU, 암호화, 하위 경로의 책임을 당신에게 남긴다. 캐리어 서비스는 그것들을 넘겨받고 그 값을 청구하며, 공용 인터넷으로 프레임을 라우팅하지 않는다. 어느 쪽을 원하는지는 두 사이트가 사업자를 공유하는지 아니면 회사만 공유하는지에 달려 있다.

브리지하기 전에 더 싼 우회로를 점검하라

브리지된 링크 요청의 대부분은 하나의 깨진 이름 조회에서 오지, 프레임이 정말 필요한 프로토콜에서 오지 않는다. 먼저 리졸버와 검색 도메인을 라우티드 터널로 통과시켜라: dhcp-option DNS 10.8.0.1 와 dhcp-option DOMAIN internal.example 를 OpenVPN 서버 설정에 두면 놀랄 만큼 많은 경우가 해결된다. 먼 쪽의 로컬 포워더는 브로드캐스트 트래픽을 전혀 움직이지 않고 같은 일을 한다.

레거시 도구 하나가 여전히 실패한다면 그 도구를 목적지 세그먼트의 프록시나 점프 호스트 뒤에 두라. TCP 포워더 하나는 브리지된 WAN보다 운영이 싸다.

결정을 순서대로 닫아라: 트래픽이 비 IP EtherType을 싣는가, 탐색이 넘어가야 하는가, MTU가 추가 헤더를 흡수할 수 있는가, 사업자 회선이 실제로 있는가, 그리고 라우티드 우회로가 이름 붙일 수 있는 이유로 실패했는가? 어느 단계에서든 '아니오'는 이미 가진 터널에 유리하게 논쟁을 끝낸다. 캡처와 EtherType 목록을 변경 기록과 함께 보관하라, 왜냐하면 다음 사람이 같은 질문을 하고 측정을 반복하고 싶지 않을 것이기 때문이다.