VPN convidado no ESXi: rotear ou pontuar — decida antes do grupo de portas
Um TUN roteado precisa de rotas de retorno; um TAP em ponte precisa de alcance de camada 2 e de uma política de grupo de portas mais ampla. Defina o papel antes de ampliar o modo promíscuo.
Encaminhe os pacotes ou amplie o domínio Ethernet: a alteração do grupo de portas vem depois dessa escolha. Do ponto de vista de uma aplicação com endereço privado, os resultados podem parecer idênticos, enquanto os requisitos do hipervisor não se parecem em nada. Por isso o grupo de portas é ampliado primeiro e a questão de projeto é respondida depois, normalmente após uma tempestade de broadcast. Percorra estas verificações em ordem e pare enquanto o requisito ainda estiver vago, porque nenhum ajuste do grupo de portas corrige um projeto que nunca foi escolhido.
A decisão pertence ao proprietário do serviço; a configuração do hipervisor deve implementá-la, não determiná-la por acidente.
Verifique do que o extremo remoto realmente precisa
Liste os serviços que os clientes remotos precisam alcançar e os protocolos que usam. Se a lista for um punhado de serviços TCP em prefixos conhecidos, o roteamento cobre. Se algo realmente precisa de adjacência de camada 2 — descoberta dependente de broadcast, protocolos não IP, um dispositivo que não aceita gateway — o roteamento não consegue imitar e é preciso dizer isso cedo. Seja honesto quanto às entradas não IP dessa lista, porque é ali que um projeto roteado falha em silêncio uma semana depois.
Depois verifique o pool de clientes. Um projeto roteado precisa de uma faixa de endereços e de uma rota de retorno explícita no lado remoto; um projeto em ponte precisa que o domínio Ethernet estendido detenha a atribuição de endereços e o isolamento. Escolha o que escolher, alguém fora desta VM tem de concordar.
O que cada projeto exige da rede virtual
Os dois projetos diferem no que a rede virtual precisa tolerar, e a tabela é a forma mais curta de ver isso:
| Projeto | Papel no lado do convidado | O que a rede virtual precisa acomodar | Modo de falha se escolher mal |
|---|---|---|---|
| TUN roteado | Roteador entre prefixos separados | Um pool de clientes roteado mais caminhos de retorno no lado remoto | Os clientes chegam ao gateway e nunca chegam ao serviço por trás dele |
| TAP em ponte | Ponte de camada 2 para os clientes que se juntam | Identidades Ethernet adicionais, tráfego de broadcast e regras de VLAN | O vSwitch descarta quadros, ou o projeto exige um modo promíscuo que ninguém aprovou |
O roteamento deixa o domínio de broadcast onde está e dá um lugar natural para limitar quais serviços atravessam o gateway. A ponte move a fronteira: os clientes tornam-se participantes do domínio Ethernet estendido, e a atribuição de endereços, o isolamento e qualquer política de camada 2 agora aplicam-se a eles. Escreva a linha escolhida no registo de alterações. Uma frase como «TUN roteado, pool de clientes 10.90.0.0/24, rota de retorno no núcleo» impede o próximo engenheiro de reabrir o debate sobre o projeto a partir das definições do grupo de portas.
Quem deve poder ver os quadros de quem
Faça uma pergunta ao proprietário da plataforma antes de tocar no grupo de portas: o projeto exige que esta VM receba quadros endereçados a outros participantes? Se a resposta for não, nada nesta secção se aplica, porque um TUN roteado nunca precisa dessa visibilidade. Se a resposta for sim, o guia da Broadcom sobre o modo promíscuo é a leitura que importa: expõe quanto mais do vSwitch a VM consegue ver e recomenda confinar essa política a um único grupo de portas.
Trate isto como uma verificação de requisito, não como uma autorização. Ative a definição para um anexo dedicado quando a necessidade de ponte estiver escrita, e deixe-a desativada em todos os outros lugares. Um trunk VLAN largo copiado de outro exemplo de ponte é a parte que ninguém se lembra de remover, e um projeto de VLAN única deve continuar de VLAN única.
Registe qual grupo de portas mudou e porquê, no mesmo local onde anotou a linha do projeto. Esse par é o que torna a próxima auditoria possível.
Mantenha explícitos os objetos do convidado
Dentro do Linux, a pertença à ponte e a propriedade do endereço são objetos separados, e misturá-los provoca o confuso estado de meio funcionamento. Atribua endereços à interface da ponte ou ao túnel roteado, não aos dois lados do mesmo caminho, e mantenha as portas membros sem configuração IP.
Evite colocar uma sub-rede de forma independente num TUN roteado e numa interface Ethernet não relacionada. Essa configuração produz dois caminhos para o mesmo prefixo, respostas assimétricas e um fio de suporte sobre flapping que não menciona nenhum dos caminhos. Se o convidado também alojar contentores ou um hipervisor local, verifique que não estão já a fazer ponte para o mesmo uplink. Duas pontes numa NIC são um projeto, não um acidente que queira descobrir durante uma janela de alteração.
Confirme com um caminho de pacote, não com um ping
Verifique o caminho real, não apenas a alcançabilidade. A partir de um cliente, confirme que endereço de origem chega ao serviço remoto, e depois que a resposta volta pelo mesmo caminho. No convidado, verifique os contadores de reencaminhamento para o fluxo concreto, e no grupo de portas confirme que não foi ativada visibilidade adicional além da que o projeto escolhido exige.
Por fim, teste a direção da falha. Pare o túnel ou desligue o cliente e verifique que o tráfego não cai em silêncio para um caminho roteado que julgava não utilizado, porque essa queda é a forma como um projeto em ponte se torna em silêncio num router não intencional.