☰

CentOS 7 с 2 сетевыми картами в Google Cloud

tag-icon • tag-icon google-cloud-platform google-compute-engine
CentOS 7 с 2 сетевыми картами в Google Cloud

У меня есть 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 с несколькими интерфейсами, выполните следующие действия:

  1. Подключитесь к экземпляру, настроенному с несколькими сетевыми интерфейсами:

gcloud compute ssh multinic-vm

  1. Настройте маршрутизацию политики с помощью 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

  1. Повторите команды из шага 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

Связанный контент