ExpressRoute + VPN: 어떤 장애 도메인을 다루고 있는가
두 번째 IPsec 터널은 엔드포인트를 덮을 뿐 그 아래 회선을 덮지 않는다. 각 장애 도메인을 정리하고, 암호화 없는 대체 경로를 허용할지 결정한다.
ExpressRoute 프라이빗 피어링 위에서 동작하는 IPsec 터널은 이미 존재하는 전송 구간에 암호화를 더한다. 두 번째 터널은 엔드포인트 가용성을 높이지만, 두 터널 아래의 통신사 경로에는 아무 일도 하지 않는다. 대시보드가 초록색 터널 두 개를 보여주고 설계 검토가 다른 질문을 던질 때 이 구분은 쉽게 사라진다. 이 연결이 견뎌야 하는 장애는 무엇인가? 먼저 그 질문에 답하고 터널 수를 세야 한다. 초록색 표시의 개수는 암호화 계층의 속성이고, 장애 도메인의 개수는 전체 경로의 속성이기 때문이다.
초록색 터널이 아니라 장애에서 시작한다
무엇이든 그리기 전에 네 줄을 적는다. VPN 엔드포인트 또는 피어 인스턴스 하나의 장애, 로컬 라우터 또는 첫 구간 연결 하나의 장애, 공유 ExpressRoute 경로의 장애, 그리고 프라이빗 피어링이 여전히 트래픽을 실어 나르는 동안 IPsec을 쓸 수 없게 되는 상황이다. 각 줄은 설계가 지켜야 할 것을 지목하고, 각각은 서로 다른 메커니즘으로 답을 얻는다.
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft는 ExpressRoute 프라이빗 피어링을 통한 프라이빗 IP 사이트 간 VPN과 인터넷 기반 사이트 간 연결과의 지원되는 공존을 문서화한다. 그 공존은 다른 하부 계층 설계이며, 프라이빗 터널 엔드포인트를 하나 더 추가했다고 해서 생기는 것이 아니다.
장애 도메인 1: VPN 엔드포인트
게이트웨이 하나의 터널 두 개는 보통 같은 Azure 쪽 리소스에서 끝나는 active-active 쌍이다. 이들은 단일 터널이나 인스턴스 문제는 막지만, 그 리소스가 사용할 수 없게 되거나, 재구성되거나, 용량이 고갈되는 것은 막지 않는다. 엔드포인트 중복성이란 자체 경로와 자체 구성을 가진 두 번째 지원 엔드포인트, 그리고 그곳에 도달할 수 있는 경로를 뜻한다.
다이어그램이 말하는 것이 아니라 실제로 무엇을 배포했는지 확인한다. 포털은 이 리소스들을 그 관계를 숨기는 방식으로 묶기 때문이다.
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'두 터널이 모두 공인 IP 하나를 가진 게이트웨이 하나를 가리킨다면, 그것은 특정하고 제한된 종류의 엔드포인트 중복성이다. 요구 사항이 요구하는 것이 바로 그것일 수 있으며, 중복 연결이라고 표현하는 대신 그렇게 적어야 한다.
장애 도메인 2: 로컬 경로와 통신사
암호화 아래에는 물리적, 상업적 현실이 있다. 고객 에지 장비, 교차 연결, 공급자 네트워크, 피어링 위치다. ExpressRoute 가용성 지침은 엔드투엔드 중복성이 Microsoft 쪽만이 아니라 고객과 서비스 공급자 구간을 포함한다고 분명히 밝힌다. 라우터, 전원, 첫 구간 연결을 공유하는 두 논리 경로는 여전히 그 의존성을 공유한다.
여기서 설계가 정직한 검토를 통과하지 못한다. 같은 공급자의 회선 두 개가 같은 건물에서 끝나고 같은 발주서의 장비로 구성되어 있다면, 그것은 두 개의 장애 도메인이 아니다. 청구서가 두 장인 하나의 장애 도메인이다.
통신사에 서면으로 질문한다. 이 경로 중 어느 것이 어디서 갈라지는가, 공유 구간이 실패할 때 문서화된 동작은 무엇인가. 설계 통화에서의 구두 보증은 지금 설계하는 장애를 견디지 못한다.
장애 도메인 3: IPsec 없이 살아남는 경로
프라이빗 피어링과 IPsec은 같은 애플리케이션 프리픽스에 경쟁하는 경로를 제공할 수 있다. 보호된 경로가 사라져도 남아 있는 직접 ExpressRoute 경로는 터널이 제공하던 암호화 계층 없이 여전히 사용할 수 있을 수 있다. 그것이 허용되는지는 정책 결정이며, 가장 자주 암묵적으로 남겨지는 결정이기도 하다.
여기서 암호화 요구 사항과 가용성 요구 사항이 실제로 충돌할 수 있다. «살아남은 경로는 모두 성공으로 본다»는 가용성 진술이며, 암호화 질문에 조용히 «아니오»라고 답한다. 어느 쪽이 이기는지, 어느 프리픽스에 대해, 누가 승인했는지 적어 둔다.
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table학습된 경로를 예상한 프리픽스와 비교한다. 작은 관리 업무를 나르는 대체 경로는 그 업무에는 충분할 수 있지만 프로덕션 수요가 필요로 하는 용량에는 한참 못 미칠 수 있으므로, 용량 가정을 경로 옆에 기록한다.
판정 하나가 아니라 세 개의 행으로 기록한다
엔드포인트 중복성, 전송 중복성, 재해 복구를 설계 기록에서 별도 항목으로 유지하고, 각각 고유한 메커니즘과 검증과 담당자를 둔다. 인시던트 검토에서 왜 이 연결은 게이트웨이 재시작은 견뎠지만 광섬유 절단은 견디지 못했는지 묻는다면, 세 행이 한 문장으로 답한다. «중복» 체크박스 하나로는 답할 수 없다.
그다음 값싸게 시험할 수 있는 행을 시험한다. 터널 하나를 실패시키고 트래픽이 옮겨 가고 다시 암호화되는지 확인한다. 경로 하나를 철수하고 남은 경로가 의도한 것인지 확인한 뒤, 여전히 암호화되는지 확인한다. 시뮬레이션하지 못한 장애는 문서화한다. 시험하지 않은 행은 가정이므로 그렇게 표시해야 한다.
쓸모 있는 산출물은 짧은 표와 행마다 한 문장이다. 어떤 행에 메커니즘이 없다면 그것이 발견 사항이며, 설계 검토에서 찾는 편이 두 터널 모두 결코 견디지 못했을 통신사 장애 중에 찾는 것보다 훨씬 싸다.