
У меня есть 2 VPC
- VPC1 — подсети Google по умолчанию
- VPC2 — отдельная дополнительная подсеть, не входящая в VPC1
Настройка сервера (instdual) с nic0 из VPC1 и nic1 из VPC2
Статический публичный IP на обоих сетевых картах
- Пинг извне на публичный IP -> VPC1 работает
- Пинг извне на публичный IP -> VPC2 не работает
Настройте еще 2 экземпляра insta и instb, один только на VPC1, а другой только на VPC2.
- Пинг извне на публичный IP -> VPC1 работает (insta)
Пинг извне на публичный IP -> VPC2 работает (instb)
из insta я могу пинговать instdual nic0
из instb я могу пинговать instdual nic1
из insta я НЕ МОГУ пинговать частный IP nic1
- из instb я НЕ МОГУ пропинговать частный IP nic0
VPC являются сетевыми пиринговыми — маршруты отображаются правильно
Брандмауэр устанавливает правило по умолчанию «разрешить все», чтобы исключить проблемы с брандмауэром.
По сути, в instdual я могу получить к нему доступ только по публичному IP-адресу nic0, а не по публичному IP-адресу nic1.
Есть идеи? Я выпил 12 чашек кофе и в данный момент у меня двоится в глазах.
решение1
Вот чего не хватало (теперь работает на 100%):
Чтобы настроить маршрутизацию политик для экземпляра на базе Linux с несколькими интерфейсами, выполните следующие действия:
- Подключитесь к экземпляру, настроенному с несколькими сетевыми интерфейсами:
gcloud compute ssh multinic-vm
- Настройте маршрутизацию политики с помощью ifconfig для nic1. В примере ниже предполагается, что 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 from 192.168.0.2/32 table rt1
sudo ip rule add to 192.168.0.2/32 table rt1
- Повторите команды из шага 2 для дополнительных интерфейсов на экземпляре (nic2, nic3.... nic7).
решение2
В облаке Google есть документация о том, как это сделать: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