☰

CentOS 7 mit 2 Netzwerkkarten in der Google Cloud

tag-icon • tag-icon google-cloud-platform google-compute-engine
CentOS 7 mit 2 Netzwerkkarten in der Google Cloud

Ich habe 2 VPCs

  • VPC1 – Standard-Google-Subnetze
  • VPC2 – einzelnes zusätzliches Subnetz nicht in VPC1

Server-Setup (instdual) mit nic0 von VPC1 und nic1 von VPC2

Statische öffentliche IP auf beiden Netzwerkkarten

  • Ping von außen an öffentliche IP -> VPC1 funktioniert
  • Ping von außen an öffentliche IP -> VPC2 funktioniert nicht

Richten Sie zwei weitere Instanzen ein: insta und instb, eine nur auf VPC1 und die andere nur auf VPC2

  • Ping von außen an öffentliche IP -> VPC1 funktioniert (sofort)

  • Ping von außen an öffentliche IP -> VPC2 funktioniert (instb)

  • von insta kann ich instdual nic0 anpingen

  • von instb aus kann ich instdual nic1 anpingen

  • von insta kann ich die private IP von nic1 NICHT anpingen

  • von instb kann ich die private IP von nic0 nicht anpingen

VPCs sind über das Netzwerk verbunden - Routen werden korrekt angezeigt

Um Firewall-Probleme zu vermeiden, legen Sie in der Firewall eine Standardregel zum Zulassen aller Regeln fest.

Grundsätzlich kann ich unter instdual nur über die öffentliche IP von nic0 darauf zugreifen, nicht über die öffentliche IP von nic1.

Irgendwelche Ideen? Ich bin 12 Kaffees im Rückstand und sehe im Moment doppelt.

Antwort1

Das hier hat gefehlt (funktioniert jetzt 100 %):

Befolgen Sie diese Schritte, um das Richtlinienrouting für eine Linux-basierte Instanz mit mehreren Schnittstellen zu konfigurieren:

  1. Stellen Sie eine Verbindung zu einer Instanz her, die mit mehreren Netzwerkschnittstellen konfiguriert ist:

gcloud compute ssh multinic-vm

  1. Konfigurieren Sie das Richtlinienrouting mit ifconfig für nic1. Das folgende Beispiel geht davon aus, dass GCP nic1 die interne IP-Adresse 192.168.0.2 zugewiesen hat und das Gateway 192.168.0.1 ist.

sudo ifconfig eth1 192.168.0.2 Netzmaske 255.255.255.255 Broadcast 192.168.0.2 MTU 1430
sudo echo "1 rt1" | sudo tee -a /etc/iproute2/rt_tables # (sudo su - zuerst, wenn Berechtigung verweigert wurde)
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. Wiederholen Sie die Befehle in Schritt 2 für zusätzliche Schnittstellen auf der Instanz (nic2, nic3 … nic7).

Antwort2

In der Google Cloud finden Sie hier eine Dokumentation dazu:https://cloud.google.com/vpc/docs/create-use-multiple-interfaces Allerdings fehlen hier Informationen, wie sichergestellt werden kann, dass die zusätzlichen Schnittstellen auch nach einem Neustart wieder funktionieren.

Damit die zusätzlichen externen IPs dauerhaft bestehen bleiben, müssen Sie sicherstellen, dass die Befehle zum Aktivieren des Policy-Routings nach einem Neustart ausgeführt werden, jedoch erst, wenn die zusätzlichen Schnittstellen aktiviert wurden. Dies wird vom DHCP-Client erledigt. Die beste Methode, die ich finden konnte, besteht darin, ein Skript in /etc/dhcp/dhclient-exit-hooks.d/ einzufügen, das Folgendes enthält:

#!/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

(ändern Sie die IPs in die IPs Ihres internen Netzwerks)

Wenn Sie außerdem in der Lage sein möchten, einen Server (wie nginx oder httpd) beim Booten an eine dieser IPs zu binden, werden Sie feststellen, dass dies fehlschlägt, da der Server gestartet wird, bevor der DHCP-Client seine Aufgabe abgeschlossen hat. Eine Möglichkeit, dies zu umgehen, besteht darin, Software an IPs binden zu lassen, die noch nicht aktiv sind. Dazu geben Sie

net.ipv4.ip_nonlocal_bind=1

in /etc/sysctl.d/10-policyrouting.conf

verwandte Informationen