GCP에서 IDC와 Interconnect시 대역폭 중첩 문제

IDC와 전용선 연결 시 GCP 특정 IP 대역과 겹치는 문제 발생

IDC에서는 172.17.0.0/16 대역을 사용중인데 GCP docker bridge가 172.17.0.0/16을 이미 사용하고 있어 Cloud SQL에 연결할 수가 없는 상황. 이런 상황에서 GCP의 Private Service Connect를 고려해볼 수는 있지만 Cloud SQL은 아직 지원을 안함(2023년부터 지원 예정)

 

대안으로 SNAT를 사용한 연결 진행중

Interconnect 후 Cloud SQL에 연결하고자 할 경우 아래 승인된 네트워크 설정에 대한 제한사항을 반드시 먼저 확인해함. 왜냐하면 이 문제는 IDC 쪽에서 대역폭만 바꿔주면 아주 쉽게 해결되기 때문.

제한사항은 아래 문서를 통해 확인 가능

https://cloud.google.com/sql/docs/sqlserver/authorize-networks#limitations

아래는 SNAT, DNAT 설정법

Connect to Cloud SQL with Private IP (172.17.0.0/16)

Option 1) Intermediate proxy (SOCKS5)

The best solution is to set up a SOCKS5 proxy in the organization host VPC between the client and your Cloud SQL instance. The Cloud SQL Auth proxy supports chaining through a SOCKS5 proxy (using golang.org/x/net/proxy; see RFC 1928), a protocol that forwards TCP packets to a destination IP address. This method allows the intermediate node to forward encrypted traffic from the Cloud SQL Auth proxy to the destination Cloud SQL instance:

https://lh5.googleusercontent.com/Ezce8V6SqXosOL0_iLbElPMTSTLHEDGb352x8ZxV60QNPISUXhpJ-ArtnFAbphTgJkkkhBw67sRRsNwBk7BrltKfZNyWPAyhQWEYV3YmYk_svLgOYAAlcu-oHEGU_MGfZpWsd9KvBE1O5DELVNjAJUr51PVnx5__c5wx65CE9rk8h1ZA

The SOCKS5 support can be configured by specifying a SOCKS url in an ALL_PROXY environment variable when invoking the Cloud SQL Auth proxy. Users can direct the Cloud SQL Auth proxy to use a SOCKS5 proxy with the following command:

ALL_PROXY=socks5://SOCKS_PROXY_IP:PORT cloud_sql_proxy \

-instances=$INSTANCE_CONNECTION_NAME=tcp:5432

A good, open-source option for a SOCKS5 proxy is Dante.

How to deploy the SOCKS5 Proxy

For simple uses, a SOCKS5 proxy may be deployed on a GCE VM. For an example installation process, see this blog post.

For more complex uses where reliability is a concern, a proxy may be deployed on GKE. The SOCKS5 proxy will need to be containerized. For example, see this image that includes Dante with some basic configuration.

The performance of a SOCKS5 proxy will be bounded by the available CPU and memory, so for larger setups where more applications will be using the proxy, it's worth deploying more instances of the SOCKS5 proxy. Likewise, depending on how much usage you anticipate, you might consider whether it's necessary to deploy one proxy per application.

Option 2) Proxy VM with IP tables SNAT

Source: Client in On-prem ->

Proxy VM with iptable SNAT in GCP ->

VPC peering ->

Destination: Cloud SQL MSSQL

1. GCP VPC Firewall allow rule 등록

gcloud compute firewall-rules create fw-cloudsql-proxy \

--direction=INGRESS --priority=1000 \

--network=network-name \

--action=ALLOW \

--rules=tcp:1433 \

--source-ranges=172.17.0.0/16 (or specific source IPs)

2. Proxy VM 생성 및 iptables 설치 구성 (Cloud SQL 과 Private connect 연결된 *VPC 안에 생성필요)

ip_forward enable 설정

$ cat /proc/sys/net/ipv4/ip_forward

0

$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

1

$ cat /proc/sys/net/ipv4/ip_forward

1

vi /etc/sysctl.conf

net.ipv4.ip_forward=1

sudo sysctl -p

sudo sysctl --system

iptables 설치

sudo apt-get update

sudo apt-get install iptables-persistent

iptables 상태확인

sudo iptables -t nat -L

① SNAT 규칙 추가

설명: Source IP가 172.17.0.0/16 대역 패킷의 Source IP를 Proxy VM IP로 변경

sudo iptables -t nat -A POSTROUTING -s 172.17.0.0/255.255.0.0 -j SNAT --to <Proxy VM Private IP>

② SNAT 규칙 추가 - PAT (N:1 SNAT)

설명: 172.17.0.0/16 대역에서 출발한 패킷의 Source IP를 자신의 IP로 변경 (--to 옵션 불필요)

sudo iptables -t nat -A POSTROUTING -s 172.17.0.0/16 -j MASQUERADE

iptables 상태확인

sudo iptables -t nat -L

규칙 제거 필요 시

sudo iptables -t nat -D [추가 시 설정한 옵션값 입력]

ex) sudo iptables -t nat -D POSTROUTING -s 172.17.0.0/16 -j MASQUERADE

규칙 저장

sudo service iptables save

3. VPC Routes 등록

Name: <ROUTES_NAME>

Network: <NETWORK_NAME>

Destination IP range: <Cloud SQL Private IP>

Priority:

Instance tags:

Next hop: specify an instance

Next hop instance: <Proxy VM>

4. On-prem NW/FW 설정 확인

Firewall rule, Routes 설정 정상 확인 필요