GCP VPC Peering
VPC Peering란?
프라이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워킹 연결하는 기능이다.
https://jinho.dev/posts/vpc/
GCP에서 VPC Peering를 사용하는 경우
GCP에서는 크게 3가지로 나눌 수 있다.
- 동일한 Project에서 각각 다른 VPC간의 내부 통신을 하고 싶은 경우
→ 다른 MSP와 동일 - 하나의 Project의 VPC와 또다른 Project의 VPC간 내부 통신을 하고 싶은 경우
→ Project와 Project 간은 서로 내부IP로 통신이 불가능하므로 Project간 내부 통신을 하고 싶은 경우 VPC Peering을 사용한다.
Project란 무엇일까?
Project를 한마디로 표현하면
일종의「상위폴더」라고 말할 수 있다.
GCP에서는 여러개의 Project를 생성 할 수 있으며,
하나의 Project에 속한 Google Cloud Resource는
다른 Project의 Google Cloud Resource와는 독립적이며,
Project간의 내부 통신은 불가능하다.
그렇기 때문에 GCP에서는 목적에 따라 Project를 나눠서 관리를 한다.
- 온프레미스와 Project간 Interconnect가 맺어져 있는 상태에서 온프레미스가 추가로 생성된 Project와 통신하고 싶은 경우
→ 온프레미스와 Interconnect를 맺은 Project를 Hub Project로 두고
추가로 생성된 Project(Spoke Project)와 온프레미스간의 통신을 위해
Hub Project와 Spoke Project간의 VPC Peering 설정이 필요하다.
목표
이번 글에서는 「하나의 Project의 VPC와 또다른 Project의 VPC간 내부 통신을 하고 싶은 경우」에 대해서 알아 볼 것이며, 아래 그림에 (빨간 BOX로 표시해둔)해당하는 VPC Peering 생성 시 선택 가능한 「Exchange subnet routes with public IP」기능에 대해 언제 사용되는 옵션인지 살펴볼 것이다.
(「Exchange custom routes」는 「온프레미스와 Project간의 Interconnect맺어있는 상태에서 온프레미스가 추가로 생성된 Project와 통신하고 싶은 경우 」에 필요한 기능임으로 다음 글에서 다룰 예정이다)
참고(RFC1918 사설IP 대역)
WorkFlow
- 두개의 프로젝트를 준비
- Project A VPC생성
- 「private-public-ip-vpc1」 라는 이름으로 VPC 생성.
- 이름은 「private-public-ip-subnet1」, 대역대는 「172.168.1.0/24」로 subnet 생성.
- 「private-ip-vpc1」 라는 이름으로 VPC 생성.
- 이름은 「private-ip-subnet1」, 대역대는 「172.16.0.0/16」로 subnet 생 성.
3. Project B VPC생성
- 「private-public-ip-vpc2」 라는 이름으로 VPC 생성.
- 이름은 「private-public-ip-subnet2」, 대역대는 「172.168.2.0/24」로 subnet 생성.
- 「private-ip-vpc2」 라는 이름으로 VPC 생성.
- 이름은 「private-ip-subnet2」, 대역대는 「172.26.0.0/16」로 subnet 생 성
4. Peering 구성
- 「private-public-ip-vpc1」 ⇔ 「private-public-ip-vpc2」
- 「private-public-ip-vpc1」 ⇔ 「private-ip-vpc2」
- 「private-ip-vpc1」 ⇔ 「private-ip-vpc2」
================================
1. 두개의 프로젝트를 준비
Project A : kdyoung-int-210504 Project
B : gcp-team-210510
2. Project A VPC생성
Project A에서 VPC생성 및 subnet 생성
3. Project A VPC생성
Project B에서 VPC생성 및 subnet 생성
4. Peering 구성
A.「private-public-ip-vpc1」 ⇔ 「private-public-ip-vpc2」
ACTIVE확인
private로 사용은 되었지만 RFC1918의해 정해진 사설 IP대역이 아닌 IP를 사용한 경우이다.
해당 경우에는 아래와 같이 각 프로젝트의 VPC Peering에서는 ACTIVE가 된 것 까지는 확인이 된다
private-public-ip-vpc1 → private-public-ip-vpc2
private-public-ip-vpc2 → private-public-ip-vpc1
Route확인
하지만 각 Imported Routes와 Exported Routes를 확인해보면
아무것도 없는 것을 확인 할 수 있다.
B.「private-public-ip-vpc1」 ⇔ 「private-ip-vpc2」
ACTIVE확인
private-public-ip-vpc1→ private-ip-vpc2
private-ip-vpc2 → private-public-ip-vpc1
Route확인
VPC Peering 라우팅 확인을 해보니
RFC1918에 의해 정해져 있는 사설 IP대역인
ProjectB의 private-ip-vpc2 의 「172.26.0.0/16」대역만 광고 한 것이 확인 되었다.
c.「private-ip-vpc1」 ⇔ 「private-ip-vpc2」
ACTIVE 확인
private-ip-vpc1 → private-ip-vpc2
private-ip-vpc2 → private-ip-vpc1
Route확인
아래와 같이 RFC1918에 따라 사설IP대역을 사용 중인 subnet은
서로 경로 정보를 주고받은 것을 확인 할 수 있다.
결론
subnet을 생성 시 RFC1918 사설대역이 아닌 IP대역대를 사용하게 되면
public IP로 인식을 하기 때문에 자동으로 경로 정보를 Export를 하지 않는다.
그런 경우 사용하는 옵션이 「Exchange subnet routes with public IP」이다.
즉, private IP로 사용하지만 public IP대역대를 사용함에 있어 public IP로 인식되며「Exchange subnet routes with public IP」옵션을 사용하지 않으면 경로정보를 Export하지 않는다.
B. 「private-public-ip-vpc1」 ⇔ 「private-ip-vpc2」
위의 경우로 예를 들어 보면,
해당 경우는 「private-public-ip-vpc1」의 subnet「172.168.1.0/24」이 public IP로 인식이 됨으로 경로 정보를 광고하지 않는다. 즉, 경로 정보를 Export하지 않았음으로 「private-ip-vpc2」 의 Imported Routes에서는 emtpy로 표시가 되는 것까지 위에서 확인을 했었다.
이런 경우
「private-public-ip-vpc1」 쪽의 vpc peering에서 「Export subnet routes with public IP」선택
「private-ip-vpc2」 쪽의 vpc peering에서는 「Import subnet routes with public IP」선택
을하면 「172.168.1.0/24」에 대한 경로 정보 Export하게 되며, 통신이 가능한 상태가 된다.
