
Eu tenho 2 VPCs
- VPC1 – sub-redes padrão do Google
- VPC2 - única sub-rede adicional que não está na VPC1
Configuração do servidor (instdual) com nic0 do VPC1 e nic1 do VPC2
IP público estático em ambas as placas de rede
- Ping de fora para IP público -> VPC1 funcionando
- Ping de fora para IP público -> VPC2 não funciona
Configure mais 2 instâncias insta e instb uma somente na VPC1 e outra somente na VPC2
- Ping de fora para IP público -> VPC1 funcionando (insta)
Ping de fora para IP público -> VPC2 funcionando (instb)
do insta eu posso fazer ping instdual nic0
do instb eu posso executar ping instdual nic1
do insta NÃO POSSO executar ping no IP privado de nic1
- do instb NÃO POSSO executar ping no IP privado de nic0
Os VPCs têm peering de rede - as rotas mostram-se corretas
O firewall define um padrão para permitir que todas as regras neguem problemas de firewall.
Basicamente no instdual só consigo acessá-lo no IP público nic0. não o IP público nic1.
Alguma ideia ? Estou 12 cafés atrasado e vendo o dobro no momento.
Responder1
Isso é o que estava faltando (agora funcionando 100%):
Siga estas etapas para configurar o roteamento de políticas para uma instância baseada em Linux com diversas interfaces:
- Conecte-se a uma instância configurada com várias interfaces de rede:
gcloud computar ssh multinic-vm
- Configure o roteamento de política com ifconfig para nic1. O exemplo abaixo pressupõe que o GCP atribuiu o endereço IP interno 192.168.0.2 a nic1 e o gateway é 192.168.0.1.
sudo ifconfig eth1 192.168.0.2 máscara de rede 255.255.255.255 transmissão 192.168.0.2 mtu 1430
sudo echo "1 rt1" | sudo tee -a /etc/iproute2/rt_tables # (sudo su - primeiro se permissão negada)
sudo ip route add 192.168.0.1 src 192.168.0.2 dev eth1
sudo ip route add padrão via 192.168.0.1 dev eth1 table rt1
sudo ip rule add da tabela 192.168.0.2/32 rt1
sudo ip regra adicionar à tabela 192.168.0.2/32 rt1
- Repita os comandos na etapa 2 para interfaces adicionais na instância (nic2, nic3.... nic7).
Responder2
A nuvem do Google tem alguma documentação sobre como fazer isso aqui:https://cloud.google.com/vpc/docs/create-use-multiple-interfaces Mas faltam informações sobre como garantir que as interfaces adicionais também funcionarão novamente após uma reinicialização.
Para que os IPs externos adicionais sejam persistentes, você precisa garantir que os comandos para ativar a política de roteamento sejam executados após uma reinicialização, mas somente depois que as interfaces adicionais forem ativadas. Isso é feito pelo cliente dhcp. Portanto, a melhor maneira que encontrei de fazer é colocar um script dentro de /etc/dhcp/dhclient-exit-hooks.d/ com isto:
#!/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
(mude os IP's para os IP's da sua rede interna)
Se você também deseja vincular um servidor (como nginx ou httpd) a um desses IPs no momento da inicialização, você notará que isso falha porque o servidor é iniciado antes do dhcp-client concluir sua tarefa. Uma maneira de superar isso é permitir que o software se vincule a IPs que ainda não estão ativos. Para isso coloque
net.ipv4.ip_nonlocal_bind=1
em /etc/sysctl.d/10-policyrouting.conf