Azure VPN 게이트웨이를 통해 두 지사의 트래픽 라우팅
하나의 Azure VPN 게이트웨이에 있는 두 사이트 간 연결은 지사 트래픽을 통과시킬 수 있지만, 양쪽 끝이 접두사를 학습하고 LAN 반환 경로가 존재할 때만 가능합니다.
두 지사는 서로 직접 터널 없이도 Azure VPN 게이트웨이를 통해 트래픽을 교환할 수 있습니다. 각 지사는 같은 게이트웨이로 사이트 간 연결을 열고, 게이트웨이는 학습한 접두사를 두 연결 사이에서 전달합니다. 이것을 작동하게 하는 것은 두 번째 터널이 아니라 경로 교환입니다. 지사 A는 지사 B의 접두사를 배워야 하고, B는 A의 접두사를 배워야 합니다. 아래 점검을 순서대로 수행하고 처음 실패하는 점검에서 멈추십시오. 이후의 모든 단계가 그 점검에 의존합니다.
무엇이든 구성하기 전의 전제 조건
이 설계가 애초에 작동할 수 있는지는 네 가지 조건이 결정합니다. 게이트웨이는 경로 기반이어야 하고 BGP를 지원하는 SKU에 있어야 하며, 두 연결 모두 BGP가 활성화되어야 하고, 지사의 주소 공간이 겹치지 않아야 하며, 어느 쪽도 실제 접두사를 숨기기 위해 NAT에 의존해서는 안 됩니다.
ASN은 의도적으로 계획하십시오. Azure의 문서화된 기본값은 65515이며, 각 지사 라우터에는 게이트웨이나 다른 지사와 충돌하지 않는 자체 프라이빗 ASN이 필요합니다. 기존 게이트웨이 구성을 확인하지 않고 기본값을 재사용하는 것이 나중에 AS 경로가 거부되는 방식입니다.
VNet 피어링 동작을 기대하지 않는지도 확인하십시오. 게이트웨이는 구성한 두 연결 사이에서 경로를 교환합니다. 임의의 피어링을 전이적으로 만들지는 않습니다. 세 번째 네트워크가 두 지사에 모두 도달해야 한다면 자체 연결이나 자체 경로가 필요하며, 게이트웨이가 트래픽을 분배할 것이라는 가정은 안 됩니다. 나중에 사이트를 추가할 때 사람들이 다시 찾는 설계 결정이므로 첫 변경 창 전에 이 경계를 적어 두십시오.
이 순서로 구성
각 단계에는 관찰 가능한 결과가 있으므로 그것이 나타날 때까지 진행하지 마십시오.
- 가상 네트워크 게이트웨이에서 BGP를 활성화하고 ASN과 피어 주소를 기록합니다.
- 각 지사에 대해 해당 지사의 실제 주소 공간, ASN, BGP 피어 주소로 로컬 네트워크 게이트웨이를 만듭니다.
- 각 사이트 간 연결을 만들고 연결 자체에서 BGP를 활성화합니다.
- 지사 라우터가 가정에 따라 게이트웨이의 공용 IKE 엔드포인트가 아니라 Azure가 할당한 게이트웨이 주소와 피어링하도록 구성합니다.
네 번째 단계에서 대부분의 시도가 멈춥니다. Azure가 보고하는 BGP 피어 주소가 지사 라우터가 이웃으로 사용해야 하는 주소이며, 사람들이 터널 다이어그램에서 기대하는 주소와 항상 같지는 않습니다.
지사 접두사 자체(예: A에서 10.10.0.0/16, B에서 10.20.0.0/16)를 알리십시오. 빠진 특정 네트워크를 덮으려고 기본 경로나 넓은 집계를 알리면 그 틈은 나중에 조용한 블랙홀로 돌아옵니다.
양쪽 끝에서 경로 교환 확인
연결 상태는 점검이 아닙니다. 두 연결 모두에서 IPsec이 올라가 있어도 그 사이로 어떤 접두사도 지나지 않을 수 있습니다. 게이트웨이의 BGP 피어와 학습된 경로를 읽고, 다른 지사 방향 경로가 사용 가능한 경로로 나타나는지 확인하십시오.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP 테이블에 있는 접두사도 정적 경로나 더 구체적인 접두사에 전달 결정을 빼앗길 수 있습니다. 받은 경로만이 아니라 선택된 경로를 확인하십시오.
LAN 쪽 반환 경로 추적
Azure에서는 맞아 보이지만 현장에서 실패하는 부분입니다. 지사 A의 호스트는 그 라우터가 기본 게이트웨이이거나 호스트나 그 게이트웨이에 B의 접두사 경로가 있을 때만 패킷을 A의 VPN 라우터로 보냅니다. 반대 방향에서도 같아야 합니다.
별도의 코어 스위치가 LAN의 기본 게이트웨이라면 VPN 라우터를 가리키는 다른 지사 방향 경로가 필요합니다. 그것이 없으면 요청은 도착하고 응답은 인터넷 경로로 나가며, 사용자는 열렸다가 멈추는 연결을 보게 됩니다.
이것을 고치려고 게이트웨이 서브넷의 네트워크 보안 그룹에 손을 대지 마십시오. 그 서브넷에는 자체 요구 사항이 있고 거기에 두는 NSG는 지사 측 정책의 지원되는 대체물이 아닙니다. 필터링은 지사의 방화벽과 워크로드 자체에 속하며, 거기서 규칙 소유자가 검토할 수 있습니다. 그 규칙을 서브넷 NSG로 옮기면 다음 장애를 디버그할 팀에게서도 규칙이 숨겨집니다.
작업을 허용하고, 거부되는 테스트로 증명
학습된 경로는 권한이 아닙니다. 실제로 필요한 원본, 대상, 서비스를 지사의 방화벽과 엔드포인트 정책을 통해 허용하고 나머지는 거부된 상태로 두십시오.
지사 A의 일반 워크로드에서 지사 B의 실제 서비스로 테스트하고 응답을 확인한 다음, 금지된 상태로 남아야 하는 작업을 시도하십시오. VPN 어플라이언스 자체가 만드는 트래픽은 다른 원본 주소를 사용하고 LAN 라우팅 단계를 건너뛸 수 있으므로, 라우터에서의 성공적인 ping은 보이는 것보다 적은 것을 증명합니다.
교환한 접두사, 사용 중인 ASN, 각 측의 LAN 반환 경로, 서비스를 허용하는 정책이라는 네 가지 사실을 적고 마무리하십시오. 이 중 하나가 빠지면 구성은 첫 변경까지 작동하고, 그다음에는 아무도 이유를 설명할 수 없습니다.