VM de GCP com várias NIC: por que as respostas saem pela interface errada

Anexar uma segunda interface a uma VM do Compute Engine dá a ela outro anexo de rede, não um caminho de retorno simétrico. O convidado ainda escolhe uma interface e um endereço de origem a partir de suas próprias rotas e regras. O Google Cloud então aplica o roteamento de VPC e a política de firewall ao redor da interface pela qual o pacote saiu. Quando essas duas decisões discordam, as solicitações chegam por uma NIC e as respostas saem pela outra, e a filial vê uma conversa meio aberta.

Percorra o caminho em cinco etapas e a divergência aparecerá antes de você escrever uma regra de política.

Etapa 1: mapeie as NIC da nuvem para os dispositivos do convidado

A nuvem nomeia as interfaces nic0, nic1 e assim por diante, e o convidado vê nomes de dispositivo que não precisam coincidir. Resolva o mapeamento a partir dos metadados da instância ou do endereço da própria interface antes de qualquer outra coisa. A rota padrão comum fornecida pelo DHCP está associada a nic0, e por isso o caminho para a internet vence tantas vezes por acidente. Escrever política contra um nome de dispositivo suposto é como uma regra correta acaba na interface errada.

Anote os endereços, os nomes de dispositivo e a VPC à qual cada um pertence. Esse mapa de três colunas é a entrada de cada etapa seguinte.

Etapa 2: nomeie as duas decisões de roteamento

A primeira decisão pertence ao convidado: qual interface e qual endereço de origem para este pacote. A segunda pertence à nuvem: o que as rotas da VPC e a política de firewall permitem ao redor dessa interface.

Uma rota visível na VPC voltada para a VPN não se torna uma rota do convidado que escolha essa NIC. A rota da nuvem descreve o que a rede pode entregar, enquanto a rota do convidado decide o que o pacote faz.

Etapa 3: escolha uma política de caminho de retorno

Para um conjunto pequeno e estável de prefixos de filial, as rotas de destino explícitas no convidado são a expressão mais simples: as respostas a esses prefixos saem pela interface voltada para a VPN. Quando vários serviços usam de propósito endereços de origem locais diferentes, as regras baseadas na origem que escolhem uma tabela por interface mantêm cada resposta no contexto correto. A documentação sobre várias interfaces descreve a nomeação das NIC e o comportamento da rota padrão em que esses projetos se baseiam.

Cada tabela precisa de rotas conectadas válidas e próximos saltos, além dos destinos que lhe serão perguntados. Uma regra que aponta para uma tabela incompleta não é um projeto de caminho de retorno. Use o gateway documentado para essa NIC em vez de inventar um gateway Ethernet a partir da aparência da sub-rede.

Etapa 4: revise os filtros do próprio convidado

Verifique onde o servidor escuta e qual origem local a resposta carrega. Um ouvinte em todos os endereços não anula a política de roteamento, então vincular-se a todos os endereços não muda nada sobre a interface pela qual a resposta sai.

No Linux, revise a validação de caminho reverso em relação ao projeto pretendido. Desativá-la globalmente como primeiro passo troca um bug de roteamento por uma exposição a falsificação, e esconde a assimetria que você tentava encontrar.

Etapa 5: teste um fluxo por caminho

Verifique separadamente uma solicitação de filial permitida e uma solicitação de internet não relacionada, cada uma com sua origem e destino reais. Capture nas duas interfaces quando puder, porque a evidência útil é qual interface levou a resposta. Depois confirme que a política do lado da nuvem respeitou o caminho que você projetou. Uma solicitação bem-sucedida prova um fluxo, não um projeto simétrico.

Mantenha os dois testes separados nas suas notas, pois eles exercitam rotas diferentes e regras de firewall diferentes.

O que uma segunda NIC não lhe dá

Uma segunda interface acrescenta um anexo de rede e outro endereço. Ela não acrescenta roteamento simétrico automático e não contorna a política de firewall. Tratá-la como uma correção de roteamento é a razão pela qual projetos com várias NIC acumulam regras que depois ninguém consegue explicar.

Se a VM precisar encaminhar o tráfego de outras máquinas, planeje esse papel de roteador explicitamente, incluindo a configuração da nuvem que permite o encaminhamento e os filtros do convidado que a acompanham.