Today Keys : cloud wan, wan, global, network, sharing, core, policy, cne, edge, segment, allow, deny, select
이번 포스팅에서는 AWS Re:Invent 2021에서 소개된 AWS Cloud WAN에 대한 여섯 번째 포스팅입니다. 이번 포스팅에서는 서로 다른 Segment에 연결된 Attachment 간의 통신과 Segment의 Sharing 설정과 Segment의 filter 옵션에 대해서 테스트하는 예제를 다뤄봅니다.
Cloud WAN에 대한 포스팅으로 다룰 수 있는 내용들은 더 많이 있을 것 같지만, 우선 지금 진행하는 포스팅은 서로 다른 계정 간의 연결 테스트를 하는 포스팅과 나중에 다루기로 했던, Cloud WAN에 대한 개론에 대해서도 별도 포스팅까지 Part 8까지만 올리게 될 것 같습니다. Cloud WAN에 대한 추가적인 포스팅을 추가로 더 다루게 될 수도 있으나 우선은 Part 8까지만 계획 중입니다.
다음은 Segment 간의 통신을 테스트 하기 위해서 만든 Cloud WAN 아키텍처입니다.
Virginia 리전과 Singapore 리전에 각각 2개의 VPC를 만들고,
zigiseg1과 zigiseg2라는 이름의 segment를 만들어서, 각 리전에 VPC 1개씩을 Segment에 연결하였습니다.
각각의 VPC에는 1개씩 EC2 인스턴스가 있으며, EC2 인스턴스 IP를 아래 그림에 표기해 두었습니다.
이제 Segment 간의 통신 테스트를 해보겠습니다.
ZIGI-VIRG-VPC1-Attach와 ZIGI-SING-VPC1-Attach라는 Attachment는 zigiseg1 Segment에
ZIGI-VIRG-VPC2-Attach와 ZIGI-SING-VPC2-Attach라는 Attachment는 zigiseg2 Segment에 연결되어 있습니다.
Segment 내부에서는 Isolated Attachment를 하지 않으면 기본적으로 모두 통신이 가능합니다.
하지만, 동일 리전이라도 Segment가 다르면 서로 논리적으로 분리된 상태이기 때문에 통신이 되지 않습니다.
아래의 테스트를 보면 Virginia 리전의 VPC 간의 통신 테스트 시 Segment가 분리되어 통신이 되지 않는 것을 볼 수 있습니다.
마찬가지로 Singapore 리전에서도 Segment가 다른 VPC 간의 통신이 되지 않는 것을 볼 수 있습니다.
하지만, 동일 Segment 내에서는 앞선 포스팅에서도 테스트 했던 것처럼 통신이 가능합니다.
zigiseg2에 속한 Attachment는 각각 서로 다른 Virginia와 Singapore 리전이지만 정상적으로 통신이 가능한 것을 볼 수 있습니다.
이번에는 Segment의 Sharing과 관련된 테스트를 진행해 보겠습니다.
Sharing 테스트를 위해서, 다음과 같이 Cloud WAN 아키텍처를 구성했습니다.
현재 3개의 Segment(zigiseg1, zigiseg2, zigiseg3)가 있고,
각 Segment에는 1개의 VPC Type의 Attachment가 있으며, Virginia 리전에 2개, Tokyo 리전에 1개 VPC가 있습니다.
현재 각 Segment의 Edge Location 라우팅 정보를 확인해 보겠습니다.
Sharing 테스트 시에는 us-east-1 edge location에서만 라우팅 테이블을 확인하겠지만,
초기 구성 상태에서는 us-east-1(virginia)과 ap-northeast-1(tokyo)의 라우팅 테이블을 모두 확인하겠습니다.
zigiseg1의 us-east-1에서는
zigiseg1에 연결되어 있는 ZIGI-VIRG-VPC1-Attach의 대역이 Attachment를 Destination으로 설정되어 있습니다.
zigiseg1의 ap-northeast-1에서는
ZIGI-VIRG-VPC1-Attach가 us-east-1에 연결된 Attachment이기 때문에 zigiseg1 segment가 Destination입니다.
목적지가 Segment로 되어 있는 것은, 지금 확인하고 있는 라우팅 테이블이 Segment 자체의 테이블이 아니라
해당 Segment에 속한 Edge Location의 Core Network Edge(CNE)에 속한 테이블이기 때문입니다.
이 내용은 Cloud WAN에 대한 개념 포스팅에서 다시 얘기 드릴 예정입니다.
zigiseg2 Segment의 us-east-1의 라우팅을 보면,
zigiseg2에 연결된 ZIGI-Tokyo-VPC1-Attach의 대역인 10.2.0.0/22 을 목적지 네트워크로 하는 라우팅이 있습니다.
마찬가지로, ap-northeast-1의 라우팅에서 보면,
zigiseg2에 연결된 ZIGI-Tokyo-VPC1-Attach가 Tokyo에 위치해 있기 때문에 동일 대역(10.2.0.0/22)에 대해서,
Destination이 Attachment로 된 것을 볼 수 있습니다.
zigiseg3 Segment의 us-east-1의 라우팅도 위에서 설명한 것과 마찬가지로,
zigiseg3 Segment에 연결된 ZIGI-Virginia-VPC2-Attach 대역인 10.1.4.0/22 에 대한 라우팅을 확인 할 수 있습니다.
zigiseg3의 ap-northeast-1의 라우팅 테이블도 아래와 같이 확인이 가능합니다.
이제 Segment에 대한 Sharing을 테스트 해보겠습니다.
Core Network Policy의 sharing 설정에서, zigiseg1 Segment가 Sharing 되도록 설정합니다.
share with 옵션은 기본 값인 Allow all 로 둡니다.
Segment Sharing이 정상적으로 등록된 것을 확인하며, Core Network Policy를 적용합니다.
Core Network Policy가 적용되고 나면, 이제 라우팅 테이블을 확인해 봅니다.
zigiseg2을 라우팅을 보면, zigiseg1에 연결된 Attachment 대역인 10.1.0.0/22 에 대해서, 라우팅이 생긴 것을 볼 수 있습니다.
zigiseg3에서도 보면, 동일하게 zigiseg1에 연결된 네트워크 대역(10.1.0.0/22)가 추가 된 것을 볼 수 있습니다.
Sharing을 설정한 zigiseg1에서 보면,
zigiseg2와 zigiseg3에 연결된 Attachment의 대역인
10.2.0.0/22 (ZIGI-Tokyo-VPC1-Attach)와 10.1.4.0/22 (ZIGI-Virginia-VPC2-Attach) 이 모두 추가된 것을 볼 수 있습니다.
zigiseg1을 sharing 했지만, 통신을 위해서는 상호 간의 라우팅이 모두 등록되어 있어야 하기 때문에
zigiseg1에는 나머지 Segment에 연결된 대역,
zigiseg2, zigiseg3에는 Sharing 된 zigiseg1 Segment의 대역에 대한 라우팅이 테이블에 반영되는 것을 볼 수 있습니다.
이번에는 앞서 Sharing 시에 기본 값으로 두었던, Share with 옵션을 조정해서 테스트해 보겠습니다.
Share with 옵션에서, Allow all을 Allow selected로 값을 변경하겠습니다.
변경 이후에 Allow segment list에 zigiseg2만 선택 후, Sharing을 적용합니다.
수정된 Core Network Policy를 다시 적용합니다.
이제 zigiseg2 Segment에 속한 라우팅 테이블을 다시 확인해보면,
zigiseg2는 방금 전과 동일하게 zigiseg1에 속한 Attachment(10.1.0.0/22)에 대한 라우팅이 있는 것을 볼 수 있습니다.
하지만, zigiseg3 Segment에 속한 라우팅 테이블을 확인해 보면,
zigiseg1에 속한 Attachment(10.1.0.0/22)에 대한 라우팅이 사라진 것을 볼 수 있습니다.
zigiseg1 sharing 시에, Allow selected를 선택하고, zigiseg2 segment만 List에 추가했기 때문입니다.
zigiseg1 Segment에 속한 라우팅 테이블도, Allow List에 속한 zigiseg2에 속한 대역(10.2.0.0)만 있는 것을 볼 수 있습니다.
이 때, Destinations이 zigiseg1 Segment로 되어 있는 데,
결국 CNE → zigiseg1 → zigiseg2 → CNE 로 가는 구조인 것을 알 수 있습니다.
이번에는 Share with 옵션을 Deny selected로 변경해서, 테스트를 합니다.
Deny segment list는 Allow 때와 마찬가지로 zigiseg2로 선택합니다.
변경한 Sharing 설정을 반영하기 위해 Core Network Policy를 적용합니다.
Core Network Policy가 반영 된 이후에 다시 라우팅 테이블을 확인합니다.
이번에는 zigiseg1에 속한 Attachment(10.1.0.0/22)에 대한 라우팅이 사라진 것을 볼 수 있습니다.
zigiseg1 sharing 시에, Deny selected를 선택하고, zigiseg2 segment를 List에 추가했기 때문입니다.
zigiseg3의 경우, 다시 zigiseg1에 속한 Attachment(10.1.0.0/22)에 대한 라우팅이 테이블에 반영된 것을 볼 수 있습니다.
Deny selected의 List에 포함되지 않은 Segment이기 때문에 정상적으로 Sharing 된 것입니다.
zigiseg1 Segment의 라우팅 테이블에도 zigiseg3 Segment에 속한 대역(10.1.4.0)만 라우팅 테이블에 반영되었습니다.
이제 다음 테스트를 위해서, Sharing 설정을 다음과 같이 변경합니다.
zigiseg1과 zigiseg2 Segment를 Sharing 하도록 설정하고,
Share with 옵션을 기본 값이 Allow로 변경합니다.
Sharing 설정을 변경 한 이후에 zigiseg3 Segment에서
zigiseg1과 zigiseg2에 속한 대역이 정상적으로 모두 라우팅 테이블에서 보이는지 확인합니다.
이번에는 Segment의 옵션을 수정해 봅니다.
Segment 설정 옵션 중에, 제일 하단에 Segment filter라는 것이 있습니다.
zigiseg3 Segment에서 Segment filter 중에서 Deny selected를 선택하고,
Deny segment list에서 zigiseg1을 선택합니다.
마찬가지로 변경된 Segment 설정을 반영하기 위해서 Core Network Policy를 적용합니다.
이제 zigiseg3 Segment의 라우팅 테이블을 확인해 보면,
zigiseg1에 연결된 네트워크 대역(10.1.0.0/22)이 라우팅 테이블에서 사라진 것을 볼 수 있습니다.
zigiseg1 Segment를 Deny filter로 적용했기 때문입니다.
zigiseg1 Segment의 라우팅 테이블을 확인해 보면,
sharing에서 share with 옵션으로 deny 했을 때와는 조금 다른 것을 확인할 수 있습니다.
zigiseg3에서는 Deny filter로 zigiseg1을 적용했기 때문에 zigiseg1의 네트워크 대역이 라우팅에서 빠졌지만,
zigiseg1에서는 zigiseg3에 대한 네트워크 대역(10.2.0.0/22)에 대한 라우팅이 그대로 있는 것을 볼 수 있습니다.
즉, segment 자체에서 filter를 건 것은 해당 segment에서 라우팅을 분배 받지 않겠다라는 설정이기 때문에
Sharing한 Segment의 라우팅 테이블에는 영향을 미치지 않는 것을 알 수 있습니다.
