ESXi 게스트 VPN: 라우팅인가 브리징인가 — 포트 그룹 전에 결정하세요

패킷을 라우팅하거나 Ethernet 도메인을 확장하세요: 포트 그룹 변경은 그 선택의 하류에 있습니다. 사설 주소를 가진 애플리케이션에서 보면 결과가 동일해 보일 수 있지만, 하이퍼바이저 요구 사항은 전혀 다릅니다. 그래서 포트 그룹이 먼저 넓혀지고 설계 질문은 나중에 답해지며, 보통 브로드캐스트 폭풍 뒤에야 답이 나옵니다. 다음 점검을 순서대로 수행하고 요구 사항이 아직 모호할 때 멈추세요. 선택되지 않은 설계는 어떤 포트 그룹 설정으로도 고칠 수 없습니다.

결정은 서비스 소유자의 몫입니다. 하이퍼바이저 구성은 그것을 구현해야 하며, 우연히 결정해서는 안 됩니다.

원격 끝이 실제로 무엇을 필요로 하는지 확인하세요

원격 클라이언트가 도달해야 하는 서비스와 사용하는 프로토콜을 나열하세요. 목록이 알려진 프리픽스의 TCP 서비스 몇 개라면 라우팅으로 충분합니다. 정말로 2계층 인접이 필요한 것이 있다면 — 브로드캐스트 의존 검색, 비IP 프로토콜, 게이트웨이를 받아들이지 않는 장치 — 라우팅으로는 흉내 낼 수 없으며 일찍 말해야 합니다. 그 목록의 비IP 항목에 대해 정직하세요. 라우티드 설계가 일주일 뒤 조용히 실패하는 곳이 바로 거기입니다.

그다음 클라이언트 풀을 확인하세요. 라우티드 설계에는 주소 범위와 원격 측의 명시적 반환 경로가 필요하고, 브리지드 설계에는 확장된 Ethernet 도메인이 주소 할당과 격리를 소유해야 합니다. 무엇을 고르든 이 VM 밖의 누군가가 동의해야 합니다.

각 설계가 가상 네트워크에 요구하는 것

두 설계는 가상 네트워크가 견뎌야 할 것이 다르며, 표가 이를 가장 짧게 보여 줍니다:

라우팅은 브로드캐스트 도메인을 제자리에 두고 어떤 서비스가 게이트웨이를 넘는지 제한할 자연스러운 지점을 줍니다. 브리징은 경계를 옮깁니다. 클라이언트가 확장된 Ethernet 도메인의 참여자가 되고, 주소 할당, 격리, 모든 2계층 정책이 이제 그들에게 적용됩니다. 선택한 행을 변경 기록에 쓰세요. “라우티드 TUN, 클라이언트 풀 10.90.0.0/24, 코어의 반환 경로” 같은 문장은 다음 엔지니어가 포트 그룹 설정에서 설계를 다시 논쟁하지 못하게 합니다.

누가 누구의 프레임을 볼 수 있어야 하는가

포트 그룹을 건드리기 전에 플랫폼 소유자에게 한 가지를 물으세요. 이 설계가 이 VM이 다른 참여자에게 보낸 프레임을 받도록 요구합니까? 답이 아니오라면 이 절은 아무것도 적용되지 않습니다. 라우티드 TUN은 그 가시성이 결코 필요 없기 때문입니다. 답이 예라면, promiscuous 모드에 관한 Broadcom 지침 이 중요한 읽을거리입니다. VM이 vSwitch에서 얼마나 더 많이 볼 수 있는지 설명하고 그 정책을 하나의 포트 그룹으로 한정할 것을 권합니다.

이를 허가증이 아니라 요구 사항 점검으로 다루세요. 브리징 필요가 문서화되면 전용 연결 하나에만 설정을 켜고 다른 모든 곳에서는 끄세요. 다른 브리지 예제에서 복사한 넓은 VLAN 트렁크는 아무도 제거할 생각을 하지 않는 부분이며, 단일 VLAN 설계는 단일 VLAN으로 남아야 합니다.

어느 포트 그룹이 왜 바뀌었는지 설계 행을 쓴 같은 곳에 기록하세요. 그 짝이 다음 감사를 가능하게 합니다.

게스트의 객체를 명시적으로 유지하세요

Linux 안에서 브리지 멤버십과 주소 소유권은 별개의 객체이며, 둘을 혼동하면 혼란스러운 반쯤 동작하는 상태가 됩니다. 주소는 브리지 인터페이스나 라우티드 터널에 할당하고 같은 경로의 양쪽에 할당하지 말며, 멤버 포트는 IP 구성이 없도록 유지하세요.

하나의 서브넷을 라우티드 TUN과 무관한 Ethernet 인터페이스에 독립적으로 두지 마세요. 그 구성은 같은 프리픽스로 가는 두 경로 와 비대칭 응답, 그리고 두 경로 중 어느 것도 언급하지 않는 flapping 지원 스레드를 만듭니다. 게스트가 컨테이너나 로컬 하이퍼바이저도 호스팅한다면 그것들이 이미 같은 업링크로 브리징되고 있지 않은지 확인하세요. 하나의 NIC에 두 브리지는 설계이지, 변경 창에서 발견하고 싶은 사고가 아닙니다.

ping이 아니라 패킷 경로로 확인하세요

도달성만이 아니라 실제 경로를 검증하세요. 클라이언트에서 어느 소스 주소가 원격 서비스에 도착하는지 확인하고, 응답이 같은 길로 돌아오는지 확인하세요. 게스트에서는 특정 흐름의 전달 카운터를, 포트 그룹에서는 선택한 설계가 필요로 하는 것 이상의 가시성이 활성화되지 않았음을 확인하세요.

마지막으로 실패 방향을 시험하세요. 터널을 멈추거나 클라이언트를 분리하고 트래픽이 사용되지 않는다고 생각한 라우티드 경로로 조용히 떨어지지 않는지 확인하세요. 그 낙하가 바로 브리지드 설계가 조용히 의도치 않은 라우터가 되는 방식입니다.