10.0.0.0/8 및 192.168.0.0/16의 AWS VPC CIDR

10.0.0.0/8 및 192.168.0.0/16의 AWS VPC CIDR

10.A.0.0/16CIDR이 있는 VPC A 와 CIDR이 있는 VPC B 가 있습니다 10.B.0.0/16. VPC A와 B가 피어링되어 라우팅 테이블을 업데이트했으며, 있는 서버에서 10.B.0.0/16서버를 핑할 수 10.A.0.0/16있고 그 반대의 경우도 마찬가지입니다.

VPC A의 애플리케이션도 해당 192.168.0.0/16범위의 일부 IP를 사용합니다. 쉽게 변경할 수는 없지만 VPC B에서 VPC A에 연결할 수 있어야 합니다 192.168.0.0/16. VPC A는 project-calico를 사용하는 이전 kubernetes 클러스터에 사용됩니다. 작업자 노드(ec2 인스턴스)는 VPC CIDR 블록에서 IP를 얻지 10.A.0.0/16만 Calico 네트워킹은 클러스터 CIDR 설정으로 설정되고 192.168.0.0/16해당 작업자 노드의 Pod IP는 해당 범위에 할당됩니다. 최신 클러스터는 EKS 클러스터이고 포드 IP는 VPC의 CIDR 범위인 에서 할당됩니다 10.B.0.0/16. 전환 기간 동안 두 클러스터의 VPC가 함께 피어링되었습니다. 분산된 Elixir 애플리케이션이 실행되고 있으며 포드는 포드 IP 주소를 통해 서로 연결하여 Erlang 클러스터를 형성합니다. 현재 피어링을 사용하면 클러스터 A 포드는 A 포드와 B 포드 모두에 연결할 수 있지만 클러스터 B 포드는 192.168.0.0/16IP에 연결할 수 없기 때문에 B에만 연결할 수 있습니다 .

192.168.0.0/16VPC B에 사용되는 라우팅 테이블에 추가하고 피어링 연결 대상을 설정해 보았습니다 . 작동하지 않는 것 같습니다. 192.168.0.0/16VPC A의 CIDR 블록에 없기 때문입니다.

192.168.0.0/16VPC A는 제한되어 있으므로 보조 CIDR로 추가할 수 없습니다 . 보다CIDR 블록 연결 제한그리고관련 질문. 제한되어 있음을 이해합니다. 그런데 왜 제한됩니까? RFC1918은 둘 이상의 개인 주소 공간을 사용하는 것에 대해 아무 말도하지 않는 것 같습니다.

192.168.0.0/16또한 Transit Gateway를 만들고, 두 VPC를 모두 연결하고, VPC A 연결을 대상 으로 하는 Transit Gateway 라우팅 테이블에 고정 경로를 추가해 보았습니다 . 그러나 여전히 VPC B 내에서는 해당 범위에 도달할 수 없습니다.

경로 테이블

VPC A의 프라이빗 서브넷에 대한 라우팅 테이블

10.A.0.0/16    local
10.B.0.0/16    pcx-[VPC A - VPC B peering connection]
0.0.0.0/0      nat-[gateway for cluster A]

VPC B의 프라이빗 서브넷에 대한 라우팅 테이블

10.B.0.0/16    local
10.A.0.0/16    pcx-[VPC A - VPC B peering connection]
192.168.0.0/16 pcx-[VPC A - VPC B peering connection]
0.0.0.0/0      nat-[gateway for cluster B]

물론 이는 192.168.0.0/16VPC A의 CIDR 블록에 없거나 추가할 수 없기 때문에 작동하지 않습니다.

Node에서 쉘이 작동하면 AI가 192.168...포드에 ping을 보내고 나도 10.B.0.0포드에 ping을 보낼 수 있습니다. 그러나 Node BI의 셸에서는 10.B.0.0Pod만 ping할 수 있습니다.

동일한 VPC의 CIDR 블록 10.0.0.0/8과 CIDR 블록 모두에 피어링할 수 있는 다른 방법이 있습니까 ?192.168.0.0/16

관련 정보