VPN de convidado en ESXi: encamiñar ou pontes, decida antes do grupo de portos
Un TUN encamiñado necesita rutas de retorno; un TAP en ponte necesita alcance de capa 2 e unha política de grupo de portos máis ampla. Fixe o papel antes de ampliar o modo promiscuo.
Encamiñe os paquetes ou amplíe o dominio Ethernet: o cambio do grupo de portos vén despois desa elección. Desde unha aplicación cun enderezo privado os resultados poden parecer idénticos, mentres que os requisitos do hipervisor non se parecen en nada. Por iso primeiro amplíase o grupo de portos e a pregunta de deseño respóndese despois, normalmente tras unha tormenta de broadcast. Percorra estas comprobacións en orde e detéñase mentres o requisito siga sendo vago, porque ningún axuste do grupo de portos arranxa un deseño que nunca se escolleu.
A decisión pertence ao propietario do servizo; a configuración do hipervisor debe implementala, non determinala por accidente.
Comprobe que necesita realmente o extremo remoto
Enumere os servizos aos que deben chegar os clientes remotos e os protocolos que usan. Se a lista é un feixe de servizos TCP sobre prefixos coñecidos, o encamiñamento abonda. Se algo necesita de verdade adxacencia de capa 2 — descuberta dependente de broadcast, protocolos que non son IP, un dispositivo que non acepta unha pasarela — o encamiñamento non pode imitalo e convén dicilo pronto. Sexa sincero coas entradas non IP desa lista, porque é onde un deseño encamiñado falla en silencio unha semana despois.
Despois comprobe o grupo de clientes. Un deseño encamiñado necesita un rango de enderezos e unha ruta de retorno explícita no extremo remoto; un deseño en ponte necesita que o dominio Ethernet ampliado posúa a asignación de enderezos e o illamento. Escolla o que escolla, alguén fóra desta VM ten que aceptalo.
Que esixe cada deseño á rede virtual
Os dous deseños difiren no que a rede virtual debe tolerar, e a táboa é a forma máis curta de velo:
| Deseño | Papel no lado do convidado | Que debe absorber a rede virtual | Modo de fallo se escolle mal |
|---|---|---|---|
| TUN encamiñado | Encamiñador entre prefixos separados | Un grupo de clientes encamiñado máis rutas de retorno no extremo remoto | Os clientes chegan á pasarela e nunca chegan ao servizo que hai detrás |
| TAP en ponte | Ponte de capa 2 para os clientes que se unen | Identidades Ethernet adicionais, tráfico de broadcast e regras VLAN | O vSwitch descarta tramas, ou o deseño necesita un modo promiscuo que ninguén aprobou |
O encamiñamento deixa o dominio de broadcast onde está e dá un lugar natural para limitar que servizos cruzan a pasarela. A ponte move a fronteira: os clientes pasan a ser participantes do dominio Ethernet ampliado, e a asignación de enderezos, o illamento e calquera política de capa 2 xa lles afectan. Escriba a fila escollida no rexistro de cambios. Unha frase como «TUN encamiñado, grupo de clientes 10.90.0.0/24, ruta de retorno no núcleo» evita que o seguinte enxeñeiro volva discutir o deseño desde os axustes do grupo de portos.
Quen debe poder ver as tramas de quen
Faga unha pregunta ao propietario da plataforma antes de tocar o grupo de portos: o deseño esixe que esta VM reciba tramas dirixidas a outros participantes? Se a resposta é non, nada desta sección se aplica, porque un TUN encamiñado nunca necesita esa visibilidade. Se a resposta é si, a guía de Broadcom sobre o modo promiscuo é a lectura que importa: expón canto máis do vSwitch pode ver a VM e recomenda confinar esa política a un só grupo de portos.
Tráteo como unha comprobación de requisito, non como un permiso. Active o axuste para unha adhesión dedicada cando a necesidade de ponte estea escrita, e déixeo desactivado en todo o demais. Un trunk VLAN amplo copiado doutro exemplo de ponte é a parte que ninguén lembra quitar, e un deseño dunha soa VLAN debe seguir sendo dunha soa VLAN.
Rexiste que grupo de portos cambiou e por que, no mesmo lugar onde anotou a fila de deseño. Ese emparellamento é o que fai posible a seguinte auditoría.
Manteña explícitos os obxectos do convidado
Dentro de Linux, a pertenza á ponte e a propiedade do enderezo son obxectos separados, e mesturalos provoca o confuso estado de medio funcionamento. Asigne enderezos á interface da ponte ou ao túnel encamiñado, non aos dous lados do mesmo camiño, e manteña os portos membros sen configuración IP.
Evite pór unha subrede de forma independente nun TUN encamiñado e nunha interface Ethernet non relacionada. Esa configuración produce dous camiños ao mesmo prefixo, respostas asimétricas e un fío de soporte sobre flapping que non menciona ningún dos dous camiños. Se o convidado tamén aloxa contedores ou un hipervisor local, comprobe que non estean xa facendo ponte cara ao mesmo uplink. Dúas pontes nunha NIC son un deseño, non un accidente que queira descubrir durante unha xanela de cambio.
Confirme cun camiño de paquete, non cun ping
Verifique o camiño real, non só a alcanzabilidade. Desde un cliente, confirme que enderezo de orixe chega ao servizo remoto e despois que a resposta volve polo mesmo camiño. No convidado, revise os contadores de reenvío para o fluxo concreto, e no grupo de portos confirme que non se habilitou visibilidade adicional máis alá da que necesita o deseño escollido.
Por último, probe a dirección de fallo. Deteña o túnel ou desconecte o cliente e comprobe que o tráfico non cae en silencio a un camiño encamiñado que cría sen usar, porque esa caída é como un deseño en ponte se converte en silencio nun encamiñador non desexado.