Conjunto Google Cloud Compute / 20 máscara de sub-rede para interface interna

1

O Google Cloud usa o DHCP para atribuir IPs a uma instância. Por algum motivo, eles atribuem o endereço com uma máscara de rede / 32, mesmo que você esteja em sua própria rede / 20. Descobri que, se eu definir as instâncias de IP público para estático, posso entrar em / etc / syconfig / network-scripts / ifcfg-eth0, alterar BOOTPROTO de DHCP para STATIC, definir manualmente as configurações de IP e usar um / 20 ou / 24 sub-rede e ele vai sobreviver a reinicializações. No entanto, depois de fazer isso, perco a capacidade de me comunicar com esse host na rede interna. Se a instância estiver usando parâmetros DHCP, posso me comunicar entre hosts na LAN sem problemas.

Depois de ler on-line, achei que este artigo link tem uma seção sobre como fazer alterações no DNS e resolver .conf e usar a configuração dhcp.lease para fazer isso. Quando eu olho neste arquivo, vejo que ele tem a opção 'subnet-mask 255.255.255.255;' configuração. Se eu mudar a máscara de rede e reiniciar a rede, as alterações serão revertidas.

Apenas para referência:

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

Também comparei a tabela de rotas entre uma instância com um endereço DHCP padrão e uma instância com minhas configurações de IP estático.

instance-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

instance-4 (estática personalizada):

[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

Eu então adicionei manualmente as diferentes rotas para a instância-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

Mas isso também não resolveu o problema.

script de rede da instância-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

script de rede da instância 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"

Como posso fazer com que a interface use uma máscara de rede diferente de / 32 e ainda possa se comunicar com outras instâncias na LAN?

O sistema operacional é o CentOS 7

Estou precisando de uma máscara de rede diferente de / 32 para que eu possa instalar o FreeIPA. Não será instalado se a máscara de rede for / 32.

    
por Jeff Clay 16.01.2017 / 01:38

1 resposta

1

Não encontrei uma maneira de contornar o problema da netmask no google cloud, mas descobri que o projeto IPA abordou esse problema e lançou uma atualização apenas para torná-lo compatível com o GCloud. ipa versão 4.4.2 e posterior não terá esse problema. entretanto, a partir deste momento, essa versão não é retornada para o centos.

aqui estão as informações do patch para serem resolvidas manualmente.

link

Aqui está o relatório do bug no site do projeto ipa.

link

Aqui está o bug que eu arquivei no google sobre o aspecto da conectividade de rede.

link

Basta colocar tudo isso lá fora para que qualquer outra pessoa com esse problema possa encontrar algumas respostas.

    
por 16.01.2017 / 19:38