허브-스포크와 풀 메시: 사이트에 맞는 VPN 토폴로지는 무엇인가

두 지점 사무실이 하루 종일 서로 통신하는데, 그 사이 터널은 다른 리전의 데이터센터를 거쳐 우회합니다. 모든 요청이 그 우회에 두 번 값을 치르고, 파일 동기화가 뭔가 이상해질 때까지 아무도 알아차리지 못합니다. 토폴로지 질문은 바로 여기에서 시작됩니다: 어떤 다이어그램이 더 탄탄해 보이는지가 아니라, 어떤 트래픽 패턴에 비용을 지불하고 있는지입니다. 두 설계 모두 동작하며, 서로 다른 방식으로 서로 다른 비용을 치르며 실패합니다.

무엇보다 먼저 피어 관계의 수를 세십시오

N개 사이트에서 풀 메시는 N 곱하기 N에서 하나를 뺀 값을 둘로 나눈 만큼의 터널이 필요하고, 허브는 N개면 됩니다. 다섯 개 사이트에서는 열 대 다섯이니 아직 감당할 만해 보입니다. 열다섯 개가 되면 105 대 열다섯이 되고, 그 차이는 더는 산수가 아니라 인력의 문제입니다.

그 관계들 하나하나가 직접 관리해야 하는 상태를 안고 있습니다. IPsec에서는 보안 연관, 아이덴티티, 키 또는 인증서, 데드 피어 탐지, 그리고 원격 프리픽스마다 최소 하나의 경로가 필요합니다. WireGuard에서는 피어마다 공개 키와 AllowedIPs 블록이면 되는데, 피어당 비용은 더 싸지만 탐색 기능이 전혀 없습니다: 새 사이트를 추가하려면 기존 모든 사이트의 설정을 바꿔야 합니다.

그림이 아니라 트래픽 구성이 결정하게 하십시오

지점 트래픽이 대부분 중앙 ERP나 파일 클러스터로 향하는 요청이라면 허브는 타협이 아니라 올바른 형태입니다: 트래픽은 이미 그쪽으로 가고 싶어 했고, 정책 지점 하나가 쌍별 규칙으로 이루어진 메시보다 감사하기 쉽습니다. 메시는 지점들이 서로 데이터를 주고받을 때, 예컨대 두 사무실 사이의 복제나 사이트 간 음성, 엔지니어 십여 명이 하루 종일 여는 CAD 공유 같은 경우에 복잡성을 정당화합니다.

어색한 사례들은 그 중간에 있고, 그쪽이 다수입니다. 조직도에서 짐작하지 말고 먼저 측정하십시오.

표는 규칙이 아니라 결정을 가르는 기준으로 읽으십시오. 네 줄 중 세 줄이 같은 쪽을 가리키면 보통 설계가 정해지고, 갈리면 하이브리드인데, 이는 대부분의 성숙한 네트워크가 결국 운영하게 되는 형태입니다.

허브는 포워딩하라고 알려 줘야 합니다

스포크-허브 터널 두 개가 잘 돌아간다고 스포크 간 접근이 생기지는 않습니다. 허브에는 IP 포워딩이 켜져 있어야 하고, 각 스포크 네트워크로 가는 경로와 그 전송을 허용하는 방화벽 규칙이 있어야 하며, 반환 경로까지 계산되어야 합니다; 각 스포크에는 상대 사이트의 프리픽스로 가는 경로가 필요합니다. 리눅스 허브에서는 net.ipv4.ip_forward=1와, 쌍을 조용히 버리지 않는 FORWARD 체인이면 되고, 정책 기반 IPsec에서는 양쪽 끝에서 원격 스포크 서브넷을 나열하는 트래픽 셀렉터가 필요합니다. strongSwan의 포워딩 안내 는 커널과 방화벽 쪽을 다룹니다, 바로 그 계층이 빠졌을 때 말입니다. 저렴한 시험은 한 스포크에서 다른 쪽 서비스로 트래픽을 보내면서 허브의 카운터를 지켜보는 것입니다; 카운터가 전혀 늘지 않는 규칙이라면 경로가 아니라 순서가 잘못된 것입니다.

중앙 정책도 유용한 부분입니다. 지점들이 서로에게 닿지 않으면서 공유 서비스에는 닿도록 허용할 수 있고, 그 접근 매트릭스는 명시적으로 문서화할 가치가 있습니다. 누군가 읽을 수 있는 규칙 대신 빠진 경로로 때우는 것은 좋지 않습니다.

절반만 끝낸 버전을 조심하십시오: 스포크 A는 허브를 거쳐 스포크 B로 라우팅되고, 허브는 양방향으로 라우팅하며, 허브의 방화벽은 A에서 오는 새 연결은 허용하지만 B에서는 허용하지 않습니다. 첫 방향은 시험이 잘 통과하고 두 번째는 멈추는데, 라우팅 결함처럼 보이지만 그렇지 않습니다.

먼저 실패를 설계하고, 그다음 정상 경로를 설계하십시오

단일 허브는 공유 의존성이자 전송 병목이며, 허브 설계가 보통 틀어지는 지점이 바로 이중화입니다. 허브가 둘이면 모든 스포크가 터널을 두 개씩 가지며 반환 경로가 아웃바운드와 일치해야 합니다; 그렇지 않으면 상태 기반 방화벽이 응답을 버리고 증상은 연결이 열렸다가 죽는 것으로 나타납니다. 더 큰 배포에서는 정적 프리픽스 대신 터널 위의 라우팅 프로토콜로 이 문제를 해결하는데, 장비는 늘지만 추측이 사라집니다. 무엇을 고르든 반환 경로를 아웃바운드 옆에 적어 두십시오, 아무도 시험하지 않는 절반이 바로 반환 경로이니까요.

메시는 그 위험을 분산합니다: 한 사이트의 링크가 죽어도 다른 사이트가 고립되지 않습니다. 다만 경로 선택이 사람을 놀라게 할 지점도 그만큼 늘어나고, 애플리케이션 세션은 여전히 도움 없이 경로 변경을 견디지 못합니다.

어느 설계도 페일오버를 넘어 TCP 세션을 스스로 유지하지는 않습니다. 애플리케이션이 재접속할 수 없다면 토폴로지는 당신의 문제가 아닙니다.

변경 비용으로 고르고, 그다음 경로를 확인하십시오

틀렸을 때 손해가 더 적은 허브부터 시작하십시오, 그리고 트래픽이 그 비용을 정당화하는 사이트 쌍에는 직접 터널을 추가하십시오. 그 하이브리드는 결정을 못 한 것이 아니라, 대부분의 조직이 일 년 안에 수렴하는 설계입니다. 중요한 것은 각 직결 링크에 분명한 이유와 담당자가 있다는 점입니다.

그다음 그림 하나가 아니라 둘을 확인하십시오. 정상 경로라면 각 사이트에서 각 서비스 프리픽스로 traceroute를 실행해 홉이 다이어그램과 일치하는지 확인합니다. 장애 경로라면 터널 하나를 내리고 같은 시험을 반복하십시오, 모든 것이 살아 있을 때만 동작하는 경로는 설계된 것이 아니라 설정만 된 것이니까요.

두 그림을 접근 매트릭스와 함께 보관하고, 사이트가 추가될 때 다시 보십시오; 관리하는 비용은 다음 변경의 비용이지 현재 그림의 우아함이 아닙니다.