Múltiples NICs, ruta equivocada: arreglar el enrutamiento de Windows sin reinstalar

El modelo mental: cómo Windows realmente elige una ruta

Las decisiones de enrutamiento de Windows parecen caóticas hasta que las tratas como un sistema de puntuación. Para cada destino, Windows elige la «mejor» ruta basándose en:

1. Coincidencia de prefijo más larga: un /32 gana a un /24 que gana a un /0. Las rutas específicas ganan.
2. Métrica de la ruta: el valor más bajo se prefiere.
3. Métrica de la interfaz: si varias rutas empatan, la métrica de interfaz puede desempatar.
4. Alcanzabilidad del siguiente salto: si la puerta de enlace no es alcanzable, Windows puede pasar a otra (a veces después de timeouts que se sienten como una pequeña eternidad).

El fallo multi-NIC más común es aburrido: alguien puso un gateway por defecto en dos adaptadores. Ahora hay dos rutas 0.0.0.0/0, y Windows elige una basada en métricas. Si esas métricas son automáticas, Windows puede cambiar de opinión tras cambios en la velocidad del enlace, actualizaciones de drivers, postura de VPN o un rayo cósmico cambiando un bit en la interfaz. (Vale, quizá no por el rayo cósmico. Probablemente.)

También existe un segundo modo de fallo que parece enrutamiento pero en realidad es resolución de nombres: Windows usa el servidor DNS «equivocado» para una consulta, obtiene una dirección interna y entonces el enrutamiento hace exactamente lo que le dijiste. Así que investigas la tabla de rutas durante dos horas mientras el cliente DNS arruina tu día en silencio.

Qué debería significar «multi-homed» en un diseño sensato

Un servidor Windows multi-homed está bien cuando cada NIC tiene un trabajo claro:

• Una interfaz tiene el gateway por defecto para el tráfico saliente general.
• Las otras interfaces no tienen gateway por defecto y usan rutas estáticas específicas (o enrutamiento dinámico si tu organización es de ese tipo).
• El DNS se configura deliberadamente, no se copia entre adaptadores como un ritual.
• El tráfico se valida con captura y pruebas reales de aplicaciones, no con sensaciones.

Si tu diseño se desvía de eso, aún puedes hacerlo funcionar. Pero pagarás «interés por complejidad» cada patch Tuesday.

Una cita que vale la pena mantener cerca de tus runbooks: «La esperanza no es una estrategia.» — General Gordon R. Sullivan. No es una cita de redes, pero encaja con precisión en operaciones.

Broma #1: El enrutamiento de Windows no está embrujado; solo hace exactamente lo que configuraste, y te está juzgando por ello.

Guion de diagnóstico rápido (primero/segundo/tercero)

Este es el flujo «entras medio dormido a las 2 a.m.». No estás para admirar paquetes. Estás para parar la hemorragia.

Primero: confirma el camino equivocado, no lo asumas

• Comprueba la ruta activa hacia un destino real (tu DC, tu servidor de archivos, tu endpoint de monitoreo).
• Confirma qué interfaz se usa y cuál es la puerta de enlace.
• Confirma si es enrutamiento o DNS (¿a qué resuelve el nombre?).

Segundo: encuentra los defaults en competencia y las métricas

• Busca múltiples rutas 0.0.0.0/0.
• Revisa métricas de interfaz y si están en automático.
• Comprueba si un cliente VPN inyectó rutas o cambió métricas.

Tercero: aplica la solución mínima y segura

• Elimina la puerta de enlace por defecto de las NIC que no son la predeterminada.
• Establece métricas de interfaz explícitas (deja de permitir que «Automático» tome decisiones de política).
• Añade rutas persistentes para las subredes específicas que pertenecen a la otra NIC.
• Vuelve a probar la ruta de la aplicación, no solo ping.

Si haces esos tres pasos, la mayoría de incidentes «Windows eligió la NIC equivocada» terminan rápido. El resto son DNS, WFP/política de firewall o rarezas de virtualización, que cubriremos.

Datos interesantes y contexto (por qué Windows se comporta así)

• Dato 1: Windows soporta métricas automáticas de interfaz desde hace mucho; a menudo correlaciona «enlace más rápido» con «mejor ruta», lo cual no siempre es lo que quieres para enrutamiento por política.
• Dato 2: El «orden de enlace» solía ser un gran tema en stacks de red antiguos de Windows; hoy importa menos para enrutamiento puro, pero aún puede afectar comportamientos heredados y preferencias de resolución de nombres.
• Dato 3: Windows puede mantener múltiples rutas por defecto; la ganadora es la que tiene la métrica combinada más baja, no la que pretendías.
• Dato 4: Los clientes VPN frecuentemente añaden rutas y ajustan métricas para hacer preferente el túnel. Algunos lo hacen educadamente, otros como si pagaran la renta.
• Dato 5: SMB Multichannel existe y puede usar múltiples NICs simultáneamente cuando está configurado y la red lo soporta. Eso es genial—hasta que por accidente fuerzas SMB a la NIC de gestión con DNS desparejado.
• Dato 6: «Detección de gateway muerto» puede hacer que Windows cambie de gateway tras fallos, lo que puede parecer un flapping aleatorio de rutas cuando un camino está intermitentemente roto.
• Dato 7: Hyper-V vSwitch y adaptadores vEthernet pueden introducir interfaces adicionales que compiten por métricas y registro DNS si se dejan con valores por defecto.
• Dato 8: La guía de iSCSI lleva tiempo recomendando no tener gateway por defecto en NICs de almacenamiento, con rutas explícitas si es necesario. La gente sigue ignorando esto, usualmente justo antes de un outage.
• Dato 9: En Windows empresarial, Group Policy y agentes de endpoint pueden cambiar firewall y ajustes de red después de que los «arregles» localmente, así que la persistencia implica entender el plano de gestión.

Tareas prácticas: comandos, salidas y decisiones (12+)

Cada tarea abajo incluye: un comando, qué significa la salida y la decisión que tomas a partir de ello. Los comandos se muestran desde un shell. En la práctica los ejecutarás en Windows en PowerShell o CMD; lo que importa es la semántica. Si lo haces de forma remota, hazte un favor y conserva una vía de acceso fuera de banda.

Tarea 1: Lista interfaces y ve cuáles están arriba

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,LinkSpeed -Descending | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name                  Status LinkSpeed MacAddress
----                  ------ --------- ----------
Ethernet0             Up     1 Gbps    00-15-5D-01-02-03
Ethernet1             Up     10 Gbps   3C-EC-EF-10-20-30
vEthernet (Default)   Up     10 Gbps   00-15-5D-AA-BB-CC

Significado: Tienes al menos tres interfaces. La velocidad de enlace puede influir en métricas automáticas y en tus suposiciones sobre «rutas preferidas».

Decisión: Identifica cuál NIC debe ser la predeterminada (normalmente gestión) y cuáles son de propósito especial (almacenamiento, replicación, clúster).

Tarea 2: Muestra la configuración IP incluyendo gateways por defecto y DNS

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,Ipv4Address,Ipv4DefaultGateway,DnsServer"
InterfaceAlias     : Ethernet0
Ipv4Address        : 10.20.30.40
Ipv4DefaultGateway : 10.20.30.1
DnsServer          : {10.20.30.10, 10.20.30.11}

InterfaceAlias     : Ethernet1
Ipv4Address        : 172.16.50.40
Ipv4DefaultGateway : 172.16.50.1
DnsServer          : {172.16.50.10}

Significado: Dos NICs tienen gateways por defecto. Ese es el generador clásico de «ruta equivocada».

Decisión: A menos que quieras ECMP intencional (no lo quieres), elimina el gateway por defecto de la NIC no predeterminada y reemplázalo por rutas específicas.

Tarea 3: Inspecciona la tabla de rutas buscando defaults en competencia

cr0x@server:~$ powershell -NoProfile -Command "route print -4"
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.20.30.1     10.20.30.40     25
          0.0.0.0          0.0.0.0      172.16.50.1    172.16.50.40      5
        10.20.30.0    255.255.255.0         On-link     10.20.30.40    281
       172.16.50.0    255.255.255.0         On-link    172.16.50.40    281
===========================================================================

Significado: Windows preferirá la ruta por defecto 172.16.50.1 porque la métrica 5 gana a 25. Esa podría ser tu VLAN de almacenamiento, no la VLAN de internet/gestión.

Decisión: Arregla métricas o elimina el gateway extra. No «esperes» a que Windows elija el otro.

Tarea 4: Pregunta a Windows qué ruta usaría para un destino específico

cr0x@server:~$ powershell -NoProfile -Command "Find-NetRoute -RemoteIPAddress 8.8.8.8 | Format-Table -Auto"
ifIndex DestinationPrefix NextHop       RouteMetric InterfaceMetric
------ ----------------- ------       ----------- ---------------
    12 0.0.0.0/0         172.16.50.1              5              5

Significado: Para ese destino, el siguiente salto elegido está en Ethernet1.

Decisión: Si Ethernet1 no está destinada al tráfico general saliente, evita que gane (quita el gateway o sube su métrica).

Tarea 5: Revisa métricas de interfaz y si están en automático

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric | Format-Table -Auto InterfaceAlias,InterfaceMetric,AutomaticMetric,ConnectionState"
InterfaceAlias        InterfaceMetric AutomaticMetric ConnectionState
--------------        -------------- --------------- ---------------
Ethernet1                          5            True Connected
Ethernet0                         25            True Connected

Significado: AutomaticMetric está activado; Windows calculó estas métricas y decidió que Ethernet1 es «mejor».

Decisión: Desactiva métricas automáticas y asigna valores explícitos que reflejen la intención (no la velocidad del enlace).

Tarea 6: Establece métricas de interfaz explícitas (la política vence a la conjetura)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'Ethernet0' -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10; Set-NetIPInterface -InterfaceAlias 'Ethernet1' -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 50; Get-NetIPInterface -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,InterfaceMetric,AutomaticMetric"
InterfaceAlias InterfaceMetric AutomaticMetric
-------------- -------------- ---------------
Ethernet0                  10           False
Ethernet1                  50           False

Significado: Ethernet0 ahora ganará empates en general. Esto no elimina la segunda ruta por defecto, pero cambia la selección si las métricas de ruta coinciden.

Decisión: Aún elimina el gateway extra a menos que tengas un diseño real multi-exit y la madurez operativa para sostenerlo.

Tarea 7: Quita el gateway por defecto de una NIC no predeterminada

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -InterfaceAlias 'Ethernet1' -DestinationPrefix '0.0.0.0/0' | Remove-NetRoute -Confirm:\$false; Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table -Auto"
ifIndex DestinationPrefix NextHop     RouteMetric PolicyStore
------ ----------------- ------     ----------- -----------
     8 0.0.0.0/0         10.20.30.1          25 ActiveStore

Significado: Solo queda una ruta por defecto. Eso es lo que quieres el 95% del tiempo.

Decisión: Si Ethernet1 aún necesita alcanzar subredes remotas específicas, añade rutas específicas a continuación.

Tarea 8: Añade una ruta estática persistente para una subred específica vía la NIC secundaria

cr0x@server:~$ powershell -NoProfile -Command "New-NetRoute -DestinationPrefix '172.16.60.0/24' -InterfaceAlias 'Ethernet1' -NextHop '172.16.50.1' -PolicyStore PersistentStore -RouteMetric 5; Get-NetRoute -DestinationPrefix '172.16.60.0/24' | Format-Table -Auto"
ifIndex DestinationPrefix  NextHop       RouteMetric PolicyStore
------ ------------------  ------       ----------- -----------
    12 172.16.60.0/24      172.16.50.1           5 PersistentStore

Significado: El tráfico a 172.16.60.0/24 saldrá por Ethernet1, independientemente de la ruta por defecto.

Decisión: Así mantienes caminos de almacenamiento/replicación estrictos sin tocar el gateway global.

Tarea 9: Verifica la selección de servidores DNS por interfaz y evita el registro «útil»

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet0      {10.20.30.10, 10.20.30.11}
Ethernet1      {172.16.50.10}

Significado: Ethernet1 tiene DNS configurado. Si ese namespace DNS no está pensado para resolución general, puedes obtener problemas de «destino equivocado» que parecen enrutamiento.

Decisión: Por lo general: solo la NIC de gestión recibe servidores DNS. Para redes aisladas (iSCSI, backup), pon DNS en blanco y desactiva el registro DNS dinámico en ese adaptador.

Tarea 10: Valida la resolución de nombres y de dónde viene

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName fileserver.corp.local | Select-Object -First 1 Name,IPAddress,Server | Format-List"
Name      : fileserver.corp.local
IPAddress : 172.16.60.25
Server    : 172.16.50.10

Significado: El servidor DNS del lado de almacenamiento respondió y devolvió una dirección en el rango de almacenamiento/replicación. Ahora SMB/RDP podría intentar usar esa red aun si «arreglaste» el enrutamiento.

Decisión: Arregla DNS: quita DNS de Ethernet1 o corrige reglas de split-horizon para que los clientes reciban la dirección correcta según su rol.

Tarea 11: Prueba la interfaz de salida real con una traza (no solo ping)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.30.10 -Port 445 -InformationLevel Detailed"
ComputerName           : 10.20.30.10
RemoteAddress          : 10.20.30.10
RemotePort             : 445
InterfaceAlias         : Ethernet0
SourceAddress          : 10.20.30.40
TcpTestSucceeded       : True

Significado: Para SMB hacia el endpoint DC/archivo, el tráfico sale por Ethernet0 con la IP fuente correcta.

Decisión: Si InterfaceAlias o SourceAddress es incorrecto, el enrutamiento y/o DNS aún no está alineado con tu intención.

Tarea 12: Revisa la inyección de rutas por VPN (el candidato silencioso)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table -Auto ifIndex,InterfaceAlias,NextHop,RouteMetric,PolicyStore"
ifIndex InterfaceAlias          NextHop      RouteMetric PolicyStore
------ --------------          ------      ----------- -----------
    22 MyCorpVPN               0.0.0.0               1 ActiveStore
     8 Ethernet0               10.20.30.1           25 ActiveStore

Significado: Tu adaptador VPN insertó una ruta por defecto con métrica 1. Eso es intencional para túnel completo; desastroso si no lo esperabas en un servidor.

Decisión: Decide la política: túnel completo o split-tunnel. Luego aplícalo en la configuración del cliente VPN, no editando rutas a mano tras cada reconexión.

Tarea 13: Identifica rutas persistentes que sobreviven al reinicio (y te sorprenden luego)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -PolicyStore PersistentStore | Sort-Object DestinationPrefix | Select-Object -First 12 | Format-Table -Auto DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix NextHop       InterfaceAlias RouteMetric
----------------- ------       -------------- -----------
172.16.60.0/24    172.16.50.1  Ethernet1                5

Significado: Existen rutas persistentes. Buenas cuando son intencionales, terribles cuando se olvidan durante una migración.

Decisión: Audita rutas persistentes durante cambios de NIC, cambios de VLAN y renumeración IP. Trátalas como configuración, no como folklore.

Tarea 14: Revisa si hay reenvío IP (podrías haber construido un router por accidente)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Select-Object -First 5 InterfaceAlias,Forwarding | Format-Table -Auto"
InterfaceAlias Forwarding
-------------- ----------
Ethernet0      Disabled
Ethernet1      Disabled

Significado: El reenvío está deshabilitado, así que este host no está ruteando entre redes. Esa es la postura usual en servidores.

Decisión: Si Forwarding está activado inesperadamente, averigua por qué. El ruteo accidental entre VLANs puede crear rutas asimétricas e incidentes de seguridad.

Tarea 15: Confirma que el enlace débil no sea el firewall o la política

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Format-Table -Auto Name,Enabled,DefaultInboundAction,DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

Significado: Inbound por defecto está bloqueado, outbound permitido. Si tu tráfico falla solo en una interfaz, la clasificación de perfil y los tipos de red importan.

Decisión: Si la NIC «equivocada» está clasificada como Public y la política la bloquea, tu «problema de enrutamiento» es en realidad de política. Arregla la asignación de categoría de red y las reglas de firewall deliberadamente.

Reglas de diseño para Windows multi-NIC que no envejezcan mal

Regla 1: Exactamente un gateway por defecto por dominio de enrutamiento

Si tu servidor Windows tiene dos gateways por defecto, no es «redundante». Es ambiguo. Si necesitas comportamiento multi-exit real, hazlo con un router, enrutamiento dinámico o un diseño soportado. Windows no es tu router de borde. Lo intentará, pero no será educado al respecto.

Regla 2: Trata las métricas de interfaz como configuración, no como sugerencia

Las métricas automáticas están bien en portátiles y desktops de usuario. En servidores, son una caída esperando al próximo update de driver o cambio en la negociación del enlace. Métricas explícitas son estabilidad barata.

Regla 3: Las NICs de almacenamiento no son «solo otra NIC»

iSCSI, SMB Direct (RDMA), replicación de backup, latidos de clúster: estos quieren caminos previsibles y direcciones IP fuente previsibles. Eso significa:

• Sin gateway por defecto
• Sin servidores DNS (usualmente)
• Desactivar el registro DNS dinámico si causa confusión a clientes
• Rutas estáticas solo para las subredes que pertenecen a esa red

Regla 4: DNS es parte del enrutamiento, te guste o no

Cuando un hostname resuelve a una dirección en la «otra» red, Windows enviará el tráfico allí con gusto. Luego miras la tabla de rutas preguntándote por qué se usa la NIC equivocada, cuando la verdad es: el mismo destino está mal para ese workload.

Regla 5: Los adaptadores virtuales merecen el mismo escrutinio que los físicos

Adaptadores vEthernet de Hyper-V, redes de contenedores y adaptadores VPN pueden insertar rutas, servidores DNS y métricas extrañas. No los ignores porque «son virtuales». Los problemas virtuales siguen siendo outages reales.

Broma #2: Un segundo gateway por defecto es como darle al servidor dos volantes—técnicamente posible, emocionalmente lamentable.

Tres micro-historias corporativas desde las trincheras del enrutamiento

Micro-historia 1: El incidente causado por una suposición equivocada

Un servidor de archivos del departamento de finanzas recibió una segunda NIC para una nueva red de backup. El ingeniero que hizo el cambio asumió «gateways en ambas NICs significa más resiliencia», porque así funciona su malla Wi‑Fi doméstica. No intentaban ser imprudentes; intentaban ayudar bajo presión de tiempo.

Funcionó bien durante la ventana de mantenimiento. Las copias empezaron. Todos se fueron a casa. De madrugada, el upstream en la VLAN de backup tuvo un problema intermitente en la puerta de enlace—pérdida de paquetes breve, suficiente para provocar reintentos, no suficiente para caerse por completo.

A la mañana, el acceso SMB al servidor de archivos iba lento para algunos usuarios y bien para otros. RDP al servidor estaba lento. El monitoreo mostró pérdida de paquetes a destinos aleatorios. El equipo persiguió almacenamiento, luego antivirus, luego «quizá es el switch». La tabla de rutas tenía dos defaults y Windows prefería la VLAN de backup debido a métricas automáticas. Cada vez que la puerta de enlace fallaba, Windows experimentaba timeouts y finalmente cambiaba al otro default… hasta que cambiaba de nuevo.

La solución fue simple: quitar el gateway por defecto de la NIC de backup, añadir una ruta solo a la subred objetivo de backup y establecer métricas de interfaz explícitas. El postmortem fue menos simple: actualizaron el estándar de build para que «un solo gateway por defecto» no fuera conocimiento tribal sino un requisito auditable.

Micro-historia 2: La optimización que salió mal

Un equipo con hosts Hyper-V quería migraciones en vivo más rápidas. Añadieron NICs dedicadas de 25Gb y establecieron métricas de interfaz muy bajas para «asegurar que la migración use los enlaces rápidos». En aislamiento, la idea suena razonable.

Lo que omitieron: esos mismos hosts también hacían autenticación de dominio, parches y coordinación de backups, todo en la red de gestión. Durante una semana ocupada, un cambio de switch bajó brevemente la velocidad negociada en un enlace de gestión. Las métricas automáticas se recalcularon; la «NIC rápida de migración» empezó a ganar más rutas de las previstas. Algunos servicios empezaron a anunciarse y a contactar desde la IP fuente equivocada.

El fallo fue sutil. La migración en vivo era rápida. Pero la validación del clúster empezó a mostrar warnings. Una herramienta de gestión perdía contacto intermitentemente con hosts. Un job de backup empezó a conectar a una IP de migración que no era alcanzable desde el segmento del servidor de backup. Parecía inestabilidad aleatoria hasta que alguien correlacionó los tiempos con los cambios de ruta.

Revirtieron la «optimización» y luego la reconstruyeron correctamente: sin gateway por defecto en NICs de migración, rutas estáticas donde era necesario y SMB Multichannel configurado explícitamente para que la migración pudiera usar las interfaces correctas sin secuestrar la identidad de red del host.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa manufacturera tenía una lista de verificación estricta para provisión de servidores. No era glamorosa. Molestaba a la gente que quería «solo desplegar». Incluía métricas de interfaz explícitas, la regla de un gateway por defecto y un pequeño conjunto de rutas persistentes para redes de replicación. También incluía una auditoría rutinaria: volcar tablas de rutas mensualmente y compararlas con una línea base.

Una vez, la auditoría marcó una diferencia: una ruta persistente extra a 0.0.0.0/0 en PersistentStore en un controlador de dominio. Aún no se había roto nada. Ese es el mejor momento para encontrar una falla.

Rastrearon hasta un cliente VPN probado por un vendor durante troubleshooting. El vendor desinstaló el cliente, pero la ruta quedó. El servidor habría empezado a preferir esa ruta en la siguiente reconexión de un adaptador con índice similar o tras un cambio de métrica. En lugar de eso, el equipo removió la ruta persistente obsoleta y documentó el procedimiento del vendor: nunca VPNs en DCs.

La checklist no evitó errores. Evitó sorpresas. En operaciones, eso es la mayor parte de la batalla.

Errores comunes: síntoma → causa raíz → solución

1) RDP funciona, pero va lento y a veces se cae

Síntoma: RDP conecta, pero las pulsaciones tardan; las sesiones se caen durante baches de red.

Causa raíz: Dos rutas por defecto; Windows a veces usa la puerta de enlace «equivocada» con pérdida intermitente.

Solución: Mantén un gateway por defecto. Elimina 0.0.0.0/0 de la NIC secundaria, establece métricas de interfaz explícitas y añade rutas específicas para subredes remotas requeridas.

2) SMB a un servidor de archivos sale por la NIC de almacenamiento

Síntoma: La copia de archivos usa IP fuente inesperada; logs de firewall muestran tráfico bloqueado desde la VLAN de almacenamiento.

Causa raíz: DNS resuelve el nombre del servidor de archivos a una dirección alcanzable vía la NIC de almacenamiento (o SMB Multichannel elige interfaces que no querías).

Solución: Arregla la asignación de DNS; haz que la NIC de gestión sea la autorizada para resolución de nombres. Si usas SMB Multichannel, valida roles de RSS/RDMA y asegura que las subredes cliente/servidor se alineen con los caminos previstos.

3) El acceso a Internet falla tras añadir una NIC de backup

Síntoma: El servidor puede alcanzar subredes internas pero no direcciones externas.

Causa raíz: La ruta por defecto se movió a una red sin NAT/egress; la puerta de enlace existe pero no enruta a Internet.

Solución: Asegura que el único gateway por defecto esté en la interfaz con capacidad de egress. Añade rutas estáticas para targets de backup en lugar de agregar un gateway.

4) «Funcionaba hasta el reinicio»

Síntoma: Las correcciones manuales desaparecen después del reinicio.

Causa raíz: Editaste ActiveStore solo; las rutas/métricas persistentes no se configuraron, o la gestión de configuración las volvió a escribir.

Solución: Usa PersistentStore para rutas estáticas. Establece métricas de interfaz explícitas. Revisa Group Policy, scripts y agentes que reapliquen ajustes de red.

5) El tráfico a una subred remota toma la NIC equivocada aun con un gateway por defecto

Síntoma: Solo destinos específicos fallan.

Causa raíz: Existe una ruta más específica (persistente, inyectada por VPN o añadida por software).

Solución: Encuentra la ruta exacta usada con Find-NetRoute, luego elimina/ajusta la ruta específica en competencia o establece una métrica mejor.

6) Tras habilitar Hyper-V, rutas y DNS se volvieron raros

Síntoma: Aparecen nuevos adaptadores vEthernet; cambia la resolución de nombres; cambia la selección de la ruta por defecto.

Causa raíz: Los adaptadores vSwitch participan en métricas/registro DNS; a veces la NIC física se convierte en uplink virtual y las configuraciones cambian.

Solución: Reaudita métricas y DNS en todos los adaptadores después de Hyper-V. Desactiva el registro DNS donde sea inapropiado. Asegura que la vNIC de gestión sea la que tenga el gateway por defecto.

7) «La gateway es alcanzable, pero las aplicaciones fallan»

Síntoma: El ping funciona, pero SQL/HTTP/SMB hacen timeout.

Causa raíz: Enrutamiento asimétrico: las respuestas salen por una NIC/IP fuente diferente a la que el cliente espera, o el seguimiento de estado del firewall las descarta.

Solución: Asegura IP fuente consistente corrigiendo la selección de rutas y evitando múltiples salidas. Valida con Test-NetConnection y captura de paquetes si hace falta.

Listas de verificación / plan paso a paso (haz esto, no improvises)

Checklist A: Estabilizar un servidor multi-NIC roto en producción

1. Identifica tu interfaz por defecto prevista (gestión/egress). Escríbelo para que el equipo deje de discutir.
2. Captura el estado actual: adaptadores, IPs, gateways, servidores DNS, tabla de rutas, rutas persistentes.
3. Confirma la ruta real hacia endpoints clave: DC, monitoreo, objetivo de backup, objetivo de almacenamiento, probe de internet.
4. Elimina rutas por defecto extra: mantén exactamente una 0.0.0.0/0 (a menos que tengas un diseño formal multi-exit).
5. Establece métricas de interfaz explícitas: desactiva AutomaticMetric en NICs de servidor; elige valores estables (p. ej., mgmt 10, storage 50, migration 60).
6. Arregla la asignación de DNS: la NIC de gestión recibe DNS; las NICs especializadas normalmente no. Evita mezclar namespaces a la ligera.
7. Añade rutas persistentes específicas para subredes remotas que deban usar la NIC secundaria.
8. Valida con pruebas a nivel de aplicación (SMB puerto 445, SQL puerto 1433, cheques de salud HTTP). Ping es necesario, no suficiente.
9. Ventana de reinicio (si es posible) y vuelve a validar. Si no puedes reiniciar, al menos asegúrate de que la configuración sea persistente.
10. Documenta la intención: qué NIC es para qué y qué nunca debe añadirse (como un segundo gateway por defecto).

Checklist B: Estándar de construcción para nuevos servidores Windows con múltiples NICs

1. Define roles: gestión, almacenamiento, backup, replicación, migración, DMZ, etc.
2. Un solo gateway por defecto, en gestión/egress.
3. Métricas de interfaz explícitas; AutomaticMetric desactivado.
4. DNS solo en la NIC de gestión salvo que tengas un diseño multi-namespace deliberado.
5. Desactivar registro DNS en NICs no de gestión si causa confusión en DNS integrado con AD.
6. Rutas estáticas persistentes para redes especiales remotas.
7. Monitoreo que verifique la IP fuente para flujos críticos (captura errores de enrutamiento temprano).
8. Paso de gestión de cambios: después de añadir una NIC, reaudita rutas y DNS.

Checklist C: Cuando realmente necesitas más de un camino de egress

Aquí es donde los equipos se vuelven creativos y luego reciben páginas.

1. Decide si el host debe hacer multi-exit routing; a menudo no debería.
2. Si sí, define requisitos de enrutamiento por política explícitamente (qué destinos usan qué egress).
3. Implementa con rutas específicas (y posiblemente enrutamiento dinámico en la red), no con «dos gateways por defecto y una oración».
4. Prueba el comportamiento de failover bajo pérdida, latencia y outages parciales.
5. Tener un plan operativo: cómo detectar selección de camino, cómo revertir y cómo prevenir deriva.

Preguntas frecuentes

1) ¿Por qué Windows elige la NIC «equivocada» después de añadir un segundo adaptador?

Porque le diste dos rutas viables (a menudo dos gateways por defecto) y las métricas hicieron que la otra sea más barata. Las métricas automáticas pueden cambiar conforme cambian velocidades de enlace y drivers.

2) ¿Está bien configurar dos gateways por defecto en un servidor Windows?

Raramente, y solo con un diseño deliberado y pruebas. Si tu objetivo es resiliencia, hazlo en la red (protocolos de enrutamiento, gateways redundantes), no dando al servidor dos salidas.

3) Si quito el gateway por defecto de la NIC de almacenamiento, ¿cómo alcanza algo?

Alcanza subredes on-link directamente, y cualquier otra cosa vía rutas específicas que añadas (rutas estáticas persistentes). Las redes de almacenamiento típicamente no deberían ser de propósito general.

4) ¿Cuál es la diferencia entre métrica de ruta y métrica de interfaz?

La métrica de ruta está ligada a una entrada de ruta específica. La métrica de interfaz está asociada a la interfaz y puede influir en la preferencia de rutas cuando existen múltiples rutas. El valor más bajo gana.

5) ¿Por qué mi «arreglo» desapareció tras el reinicio?

Probablemente cambiaste solo ActiveStore; no configuraste PersistentStore para rutas o un sistema de gestión re-aplicó ajustes. Usa PersistentStore y fija métricas de interfaz explícitas.

6) ¿Puede el DNS realmente hacer que parezca que el enrutamiento está roto?

Absolutamente. Si un hostname resuelve a una IP en la red secundaria, Windows enrutará allí correctamente. La tabla de rutas es inocente; tu política de resolución de nombres no lo es.

7) ¿Qué hay de SMB Multichannel—no usará todas las NICs de todas formas?

Pueda que sí, si ambos extremos lo soportan y está configurado. Pero no excusa gateways y DNS descuidados. Valida qué interfaces usa SMB y asegura que subredes y reglas de firewall coincidan con tu intención.

8) ¿Debería desactivar AutomaticMetric en todas partes?

En servidores con múltiples NICs: sí, típicamente. En portátiles: está bien. La diferencia es que los servidores son infraestructura; la predictibilidad vence a la conveniencia.

9) Hyper-V añadió adaptadores vEthernet—¿necesitan métricas también?

Sí. Trátalos como interfaces de primera clase. Asegura que solo la interfaz de gestión asignada tenga el gateway por defecto y DNS, y que las métricas de vNIC no ganen inesperadamente.

10) ¿Cómo sé qué interfaz usará Windows antes de romper producción?

Usa comprobaciones de selección de ruta (p. ej., Find-NetRoute) para destinos representativos, luego prueba con Test-NetConnection y valida SourceAddress/InterfaceAlias.

Conclusión: próximos pasos que realmente perduran

Los problemas multi-NIC en Windows no requieren reinstalar. Requieren admitir que el enrutamiento es política, y la política debe ser explícita.

Haz esto a continuación:

1. Audita en busca de múltiples gateways por defecto y elimina los extras.
2. Desactiva métricas automáticas de interfaz y establécelas deliberadamente.
3. Mueve redes de propósito especial a rutas persistentes y específicas.
4. Arregla DNS para que los nombres resuelvan a la red correcta para la función.
5. Después de cualquier cambio en NIC/VLAN/VPN, vuelve a ejecutar las comprobaciones de diagnóstico rápido antes de que los usuarios lo hagan por ti.

Si quieres un hábito operativo que pague para siempre: captura una tabla de rutas y métricas de interfaz base para cada rol de servidor. Cuando ocurra el próximo incidente «Windows eligió violencia», tendrás un diff, no un misterio.