
VPC가 2개 있습니다.
- VPC1 - 기본 Google 서브넷
- VPC2 - VPC1에 없는 단일 추가 서브넷
VPC1의 nic0 및 VPC2의 nic1을 사용한 서버(설치) 설정
두 NIC의 고정 공용 IP
- 외부에서 공용 IP로 핑 -> VPC1 작동
- 외부에서 공용 IP로 핑 -> VPC2가 작동하지 않음
2개의 추가 인스턴스 insta 및 instb를 VPC1에만 설정하고 다른 인스턴스는 VPC2에만 설정
- 외부에서 공용 IP로 핑 -> VPC1 작동 중(인스타)
외부에서 공용 IP로 Ping -> VPC2 작동(instb)
Insta에서 instdual nic0에 ping을 보낼 수 있어요
instb에서 instdual nic1을 ping할 수 있습니다.
인스타에서는 nic1의 개인 IP를 핑할 수 없습니다
- instb에서 nic0의 개인 IP를 핑할 수 없습니다.
VPC가 네트워크 피어링됨 - 경로가 올바르게 표시됨
방화벽은 기본값을 설정하여 모든 규칙이 방화벽 문제를 무효화하도록 허용합니다.
기본적으로 instdual에서는 nic0 공용 IP에서만 액세스할 수 있습니다. nic1 공용 IP가 아닙니다.
어떤 아이디어가 있나요? 나는 12잔의 커피 뒤에 있고 지금은 두 배가 보입니다.
답변1
누락된 내용은 다음과 같습니다(현재 100% 작동 중).
여러 인터페이스가 있는 Linux 기반 인스턴스에 대한 정책 라우팅을 구성하려면 다음 단계를 따르세요.
- 여러 네트워크 인터페이스로 구성된 인스턴스에 연결합니다.
gcloud 컴퓨팅 SSH multinic-vm
- nic1에 대해 ifconfig를 사용하여 정책 라우팅을 구성합니다. 아래 예에서는 GCP가 내부 IP 주소 192.168.0.2를 nic1에 할당했고 게이트웨이는 192.168.0.1이라고 가정합니다.
sudo ifconfig eth1 192.168.0.2 넷마스크 255.255.255.255 브로드캐스트 192.168.0.2 mtu 1430
sudo echo "1 rt1" | sudo tee -a /etc/iproute2/rt_tables # (sudo su - 권한이 거부된 경우 첫 번째)
sudo ip Route add 192.168.0.1 src 192.168.0.2 dev eth1
sudo ip Route add default via 192.168.0.1 dev eth1 table rt1
sudo ip rule add 192.168.0.2/32 테이블 rt1에서
sudo ip 규칙 192.168.0.2/32 테이블 rt1에 추가
- 인스턴스의 추가 인터페이스(nic2, nic3....nic7)에 대해 2단계의 명령을 반복합니다.
답변2
Google Cloud에는 이 작업을 수행하는 방법에 대한 몇 가지 문서가 있습니다.https://cloud.google.com/vpc/docs/create-use-multiple-interfaces 그러나 여기에는 재부팅 후에도 추가 인터페이스가 다시 작동하는지 확인하는 방법에 대한 정보가 부족합니다.
추가 외부 IP가 지속되도록 하려면 정책 라우팅을 활성화하는 명령이 재부팅 후 실행되는지 확인해야 합니다. 단, 추가 인터페이스가 활성화된 후에만 실행됩니다. 이는 dhcp-client에 의해 수행됩니다. 그래서 제가 찾을 수 있는 가장 좋은 방법은 다음과 같은 스크립트를 /etc/dhcp/dhclient-exit-hooks.d/에 넣는 것입니다.
#!/bin/sh
#
if [[ $reason == "REBOOT" || $reason == "BOUND" ]] ; then
sudo ip route add 192.168.0.1 src 192.168.0.2 dev eth1
sudo ip route add default via 192.168.0.1 dev eth1 table rt1
sudo ip rule add from 192.168.0.2/32 table rt1
sudo ip rule add to 192.168.0.2/32 table rt1
fi
(IP를 내부 네트워크의 IP로 변경)
부팅 시 서버(nginx 또는 httpd 등)를 해당 IP 중 하나에 바인딩할 수 있기를 원하는 경우 dhcp-client가 작업을 완료하기 전에 서버가 시작되기 때문에 이것이 실패한다는 것을 알 수 있습니다. 이를 극복하는 한 가지 방법은 소프트웨어가 실제로 아직 활성화되지 않은 IP에 바인딩되도록 허용하는 것입니다. 이 넣어
net.ipv4.ip_nonlocal_bind=1
/etc/sysctl.d/10-policyrouting.conf에