☰

Google Cloud Compute legt die /20-Subnetzmaske für die interne Schnittstelle fest

tag-icon • tag-icon google-cloud-platform google-compute-engine
Google Cloud Compute legt die /20-Subnetzmaske für die interne Schnittstelle fest

Google Cloud verwendet DHCP, um einer Instanz IPs zuzuweisen. Aus irgendeinem Grund weisen sie die Adresse mit einer /32-Netzmaske zu, obwohl Sie sich in Ihrem eigenen /20-Netzwerk befinden. Ich habe festgestellt, dass ich, wenn ich die öffentliche IP der Instanz auf statisch setze, in /etc/syconfig/network-scripts/ifcfg-eth0 gehen, BOOTPROTO von DHCP auf STATIC ändern und dann die IP-Einstellungen manuell festlegen und ein /20- oder /24-Subnetz verwenden kann, und es wird Neustarts überstehen. Danach verliere ich jedoch die Möglichkeit, mit diesem Host im internen Netzwerk zu kommunizieren. Wenn die Instanz DHCP-Parameter verwendet, kann ich problemlos zwischen Hosts im LAN kommunizieren.

Nachdem ich online herumgelesen hatte, fand ich diesen Artikelhttps://cloud.google.com/compute/docs/networkingenthält einen Abschnitt, in dem es um Änderungen an DNS und resolv.conf und die Verwendung der dhcp.lease-Konfiguration dazu geht. Wenn ich in diese Datei schaue, sehe ich, dass sie die Einstellung „Option Subnetzmaske 255.255.255.255;“ hat. Wenn ich die Netzmaske ändere und das Netzwerk neu starte, werden die Änderungen rückgängig gemacht.

Nur als Referenz:

instance-2 is using default DHCP and has the IP 10.128.0.5
instance-4 is using my custom static config and has the IP 10.128.0.6

Ich habe auch die Routentabelle zwischen einer Instanz mit einer Standard-DHCP-Adresse und einer Instanz mit meinen statischen IP-Einstellungen verglichen.

Instanz-2 (DHCP):

[root@instance-2 network-scripts]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.128.0.1      0.0.0.0         UG    100    0        0 eth0
10.128.0.1      0.0.0.0         255.255.255.255 UH    100    0        0 eth0
10.128.0.5      0.0.0.0         255.255.255.255 UH    100    0        0 eth0
169.254.169.254 10.128.0.1      255.255.255.255 UGH   100    0        0 eth0

Instanz 4 (benutzerdefiniertes statisches Verhalten):

[root@instance-4 NetworkManager]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.128.0.1      0.0.0.0         UG    100    0        0 eth0
10.128.0.0      0.0.0.0         255.255.240.0   U     100    0        0 eth0

Anschließend habe ich die verschiedenen Routen manuell zu Instanz 4 hinzugefügt:

[root@instance-4 NetworkManager]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.128.0.1      0.0.0.0         UG    100    0        0 eth0
10.128.0.0      0.0.0.0         255.255.240.0   U     100    0        0 eth0
10.128.0.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
10.128.0.6      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
169.254.169.254 10.128.0.1      255.255.255.255 UGH   0      0        0 eth0

Aber das hat das Problem auch nicht gelöst.

Netzwerkskript Instanz 4:

TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=eth0
UUID=cde7258f-6857-4015-86de-6bb520fcd550
ONBOOT=yes
PEERDNS=yes
PEERROUTES=yes
MTU=1460
PERSISTENT_DHCLIENT="y"
NETMASK=255.255.240.0
IPADDR=10.128.0.6
DNS1=169.254.169.254
GATEWAY=10.128.0.1

Instanz-2-Netzwerkskript

TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=eth0
UUID=cde7258f-6857-4015-86de-6bb520fcd550
ONBOOT=yes
PEERDNS=yes
PEERROUTES=yes
MTU=1460
PERSISTENT_DHCLIENT="y"

Wie kann ich die Schnittstelle dazu bringen, eine andere Netzmaske als /32 zu verwenden und trotzdem mit anderen Instanzen im LAN kommunizieren zu können?

Das Betriebssystem ist CentOS 7

Ich benötige eine andere Netzmaske als /32, damit ich FreeIPA installieren kann. Die Installation funktioniert nicht, wenn die Netzmaske /32 ist.

Antwort1

Ich habe keine Möglichkeit gefunden, das Netzmaskenproblem in der Google Cloud zu umgehen, habe aber herausgefunden, dass das IPA-Projekt sich dieses Problems angenommen und ein Update veröffentlicht hat, um die Kompatibilität mit GCloud herzustellen. Bei IPA-Version 4.4.2 und höher tritt dieses Problem nicht auf. Derzeit ist diese Version jedoch noch nicht auf CentOS zurückportiert.

Hier sind die Patchinformationen zur manuellen Behebung.

https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=dee950d88ec969b36c1271a3ef9fe4e4f5b48b01

Hier ist der eigentliche Fehlerbericht auf der IPA-Projektwebsite.

https://fedorahosted.org/freeipa/ticket/5814

Hier ist der Fehler, den ich bezüglich der Netzwerkkonnektivität bei Google gemeldet habe.

https://code.google.com/p/google-compute-engine/issues/detail?id=522&sort=stars&colspec=ID%20Type%20Component%20Resource%20Service%20Status%20Stars%20Summary%20Log

Ich möchte das alles nur an die Öffentlichkeit bringen, damit jeder, der dieses Problem hat, Antworten finden kann.

Antwort2

Für alle, die über eine Google-Suche hierher gelangen, hier ist, was ich in der GCE-Dokumentation gefunden habe. Wörtliches Zitat:

Um Schnittstellen mit einer anderen Netzmaske als /32 zu konfigurieren, sollten Sie ein Image mit dem Flag --guest-os-features MULTI_IP_SUBNET erstellen und es zum Erstellen Ihrer Instanz verwenden. Wenn Sie beispielsweise ein auf Debian 9 basierendes Image verwenden, können Sie ein Image mit dem folgenden Befehl erstellen:

gcloud compute images create debian-9-multi-ip-subnet \
     --source-disk debian-9-disk \
     --source-disk-zone us-west1-a \
     --guest-os-features MULTI_IP_SUBNET

verwandte Informationen