![Google Cloud Compute は内部インターフェースに /20 サブネット マスクを設定しました](https://rvso.com/image/697022/Google%20Cloud%20Compute%20%E3%81%AF%E5%86%85%E9%83%A8%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9%E3%81%AB%20%2F20%20%E3%82%B5%E3%83%96%E3%83%8D%E3%83%83%E3%83%88%20%E3%83%9E%E3%82%B9%E3%82%AF%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F.png)
Google Cloud は、インスタンスに IP を割り当てるために DHCP を使用します。何らかの理由で、独自の /20 ネットワーク上にいる場合でも、/32 ネットマスクでアドレスが割り当てられます。インスタンスのパブリック IP を静的に設定すると、/etc/syconfig/network-scripts/ifcfg-eth0 に移動し、BOOTPROTO を DHCP から STATIC に変更し、手動で IP 設定を行って /20 または /24 サブネットを使用すると、再起動しても問題ないことがわかりました。ただし、これを行うと、内部ネットワーク上のそのホストと通信できなくなります。インスタンスが DHCP パラメータを使用している場合は、LAN 上のホスト間で問題なく通信できます。
ネットでいろいろ読んでいたらこの記事を見つけた参考:DNS と resolv.conf に変更を加え、dhcp.lease 構成を使用して変更する方法を説明するセクションがあります。このファイルを確認すると、「option subnet-mask 255.255.255.255;」設定があることがわかります。ネットマスクを変更してネットワークを再起動すると、変更は元に戻ります。
参考までに:
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
また、デフォルトの DHCP アドレスを持つインスタンスと静的 IP 設定を持つインスタンスのルート テーブルを比較しました。
インスタンス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
インスタンス4 (カスタム静的):
[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
次に、instance-4 にさまざまなルートを手動で追加しました。
[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
しかし、それでも問題は解決しませんでした。
インスタンス 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
インスタンス 2 ネットワーク スクリプト
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"
インターフェースが /32 以外のネットマスクを適切に使用し、LAN 上の他のインスタンスと通信できるようにするにはどうすればよいでしょうか?
OSはCentOS 7です
FreeIPA をインストールするには、/32 以外のネットマスクが必要です。ネットマスクが /32 の場合はインストールされません。
答え1
Google Cloud のネットマスク問題を回避する方法はまだ見つかっていませんが、IPA プロジェクトがこの課題に対処し、GCloud との互換性を保つためのアップデートをリリースしたことはわかりました。ipa バージョン 4.4.2 以降ではこの問題は発生しません。ただし、現時点では、そのバージョンは CentOS にバックポートされていません。
手動で解決するためのパッチ情報は次のとおりです。
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=dee950d88ec969b36c1271a3ef9fe4e4f5b48b01
以下は、ipa プロジェクトの Web サイトにある実際のバグ レポートです。
https://fedorahosted.org/freeipa/ticket/5814
以下は、ネットワーク接続の側面に関して Google に報告したバグです。
この問題を抱えている他の人が答えを見つけられるように、これをすべて公開します。
答え2
Google 検索からここにたどり着いた人のために、GCE ドキュメントで見つけたものをここに示します。そのまま引用します:
/32 以外のネットマスクでインターフェースを構成するには、フラグ --guest-os-features MULTI_IP_SUBNET を使用してイメージを作成し、それを使用してインスタンスを作成する必要があります。たとえば、debian-9 ベースのイメージを使用している場合は、次のコマンドを使用してイメージを作成できます。
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