VPN de invitado en ESXi: enrutar o puentear, decida antes del grupo de puertos
Un TUN enrutado necesita rutas de retorno; un TAP puenteado necesita alcance de capa 2 y una política de grupo de puertos más amplia. Fije el papel antes de ampliar el modo promiscuo.
Enrute los paquetes o amplíe el dominio Ethernet: el cambio del grupo de puertos va después de esa elección. Desde una aplicación con una dirección privada los resultados pueden parecer idénticos, mientras que los requisitos del hipervisor no se parecen en nada. Por eso primero se amplía el grupo de puertos y la pregunta de diseño se responde después, normalmente tras una tormenta de broadcast. Recorra estas comprobaciones en orden y deténgase mientras el requisito siga siendo vago, porque ningún ajuste del grupo de puertos arregla un diseño que nunca se eligió.
La decisión corresponde al propietario del servicio; la configuración del hipervisor debe implementarla, no determinarla por accidente.
Compruebe qué necesita realmente el extremo remoto
Enumere los servicios a los que deben llegar los clientes remotos y los protocolos que usan. Si la lista es un puñado de servicios TCP sobre prefijos conocidos, el enrutamiento basta. Si algo necesita de verdad adyacencia de capa 2 — descubrimiento dependiente de broadcast, protocolos que no son IP, un dispositivo que no acepta una puerta de enlace — el enrutamiento no puede imitarlo y conviene decirlo pronto. Sea sincero con las entradas no IP de esa lista, porque es donde un diseño enrutado falla en silencio una semana después.
Después compruebe el grupo de clientes. Un diseño enrutado necesita un rango de direcciones y una ruta de retorno explícita en el extremo remoto; un diseño puenteado necesita que el dominio Ethernet ampliado posea la asignación de direcciones y el aislamiento. Elija lo que elija, alguien fuera de esta VM tiene que aceptarlo.
Qué exige cada diseño a la red virtual
Los dos diseños difieren en lo que la red virtual debe tolerar, y la tabla es la forma más corta de verlo:
| Diseño | Papel en el lado del invitado | Qué debe absorber la red virtual | Modo de fallo si elige mal |
|---|---|---|---|
| TUN enrutado | Enrutador entre prefijos separados | Un grupo de clientes enrutado más rutas de retorno en el extremo remoto | Los clientes llegan a la puerta de enlace y nunca llegan al servicio que hay detrás |
| TAP puenteado | Puente de capa 2 para los clientes que se unen | Identidades Ethernet adicionales, tráfico de broadcast y reglas VLAN | El vSwitch descarta tramas, o el diseño necesita un modo promiscuo que nadie aprobó |
El enrutamiento deja el dominio de broadcast donde está y da un lugar natural para limitar qué servicios cruzan la puerta de enlace. El puenteo mueve la frontera: los clientes pasan a ser participantes del dominio Ethernet ampliado, y la asignación de direcciones, el aislamiento y cualquier política de capa 2 ahora les afectan. Escriba la fila elegida en el registro de cambios. Una frase como «TUN enrutado, grupo de clientes 10.90.0.0/24, ruta de retorno en el núcleo» evita que el siguiente ingeniero vuelva a discutir el diseño desde los ajustes del grupo de puertos.
Quién debe poder ver las tramas de quién
Haga una pregunta al propietario de la plataforma antes de tocar el grupo de puertos: ¿el diseño exige que esta VM reciba tramas dirigidas a otros participantes? Si la respuesta es no, nada de esta sección se aplica, porque un TUN enrutado nunca necesita esa visibilidad. Si la respuesta es sí, la guía de Broadcom sobre el modo promiscuo es la lectura que importa: expone cuánto más del vSwitch puede ver la VM y recomienda confinar esa política a un solo grupo de puertos.
Trátelo como una comprobación de requisito, no como un permiso. Active el ajuste para un adjunto dedicado cuando la necesidad de puente esté escrita, y déjelo desactivado en todo lo demás. Un trunk VLAN amplio copiado de otro ejemplo de puente es la parte que nadie recuerda quitar, y un diseño de una sola VLAN debe seguir siendo de una sola VLAN.
Registre qué grupo de puertos cambió y por qué, en el mismo lugar donde anotó la fila de diseño. Ese emparejamiento es lo que hace posible la siguiente auditoría.
Mantenga explícitos los objetos del invitado
Dentro de Linux, la pertenencia al puente y la propiedad de la dirección son objetos separados, y mezclarlos provoca el confuso estado de medio funcionamiento. Asigne direcciones a la interfaz del puente o al túnel enrutado, no a ambos lados del mismo camino, y mantenga los puertos miembros sin configuración IP.
Evite poner una subred de forma independiente en un TUN enrutado y en una interfaz Ethernet no relacionada. Esa configuración produce dos caminos al mismo prefijo, respuestas asimétricas y un hilo de soporte sobre flapping que no menciona ninguno de los dos caminos. Si el invitado también aloja contenedores o un hipervisor local, compruebe que no estén ya puenteando hacia el mismo uplink. Dos puentes en una NIC son un diseño, no un accidente que quiera descubrir durante una ventana de cambio.
Confirme con un camino de paquete, no con un ping
Verifique el camino real, no solo la alcanzabilidad. Desde un cliente, confirme qué dirección de origen llega al servicio remoto y luego que la respuesta vuelve por el mismo camino. En el invitado, revise los contadores de reenvío para el flujo concreto, y en el grupo de puertos confirme que no se habilitó visibilidad adicional más allá de la que necesita el diseño elegido.
Por último, pruebe la dirección de fallo. Detenga el túnel o desconecte el cliente y compruebe que el tráfico no cae en silencio a un camino enrutado que creía sin usar, porque esa caída es cómo un diseño puenteado se convierte en silencio en un enrutador no deseado.