AG disponível a partir do 1º nó, mas não do 2º nó

Estou no processo de configuração de um Grupo de Disponibilidade no SQL Server 2019 no Windows Server 2019.

Temos dois servidores Windows, UT01 e UT02, configurados com um único adaptador de rede, usando endereços IP estáticos em um domínio do Active Directory.

O grupo de rede atribuiu um endereço IP estático para o Cluster Virtual Computer Object, UTCL, 192.168.0.12. Eles também atribuíram um endereço IP estático para o Availability Group Listener, UTAG, 192.168.0.13.

A equipe do servidor configurou o Windows Server Failover Cluster e eu configurei os SQL Servers e o Availability Group. Ambos os SQL Servers são configurados como instâncias nomeadas; assim UT01\INSe UT02\INSsão os nomes retornados por@@SERVERNAME;

De qualquer máquina na sub-rede local (192.168.0.0/24), posso me conectar ao Grupo de Disponibilidade usando o sqlcmd como tal:

sqlcmd -S UTAG\INS

Quando eu executo PRINT @@SERVERNAME;, UT01\INSou UT02\INSé retornado, dependendo de qual nó está executando o nó primário do Grupo de Disponibilidade.

Posso me conectar aos SQL Servers individuais de uma rede fora da sub-rede local, por meio de um roteador, usando sqlcmd, ou seja, sqlcmd -S UT01\INSe sqlcmd -S UT02\INSfuncionar corretamente, retornando o nome de instância apropriado para @@SERVERNAME.

Tudo bem até agora, e completamente como esperado.

No entanto, quando tento me conectar ao nome AG por meio de uma sub-rede não local, o AG responde apenas quando UT01 está executando o nó primário. Quando UT02 está executando o nó primário, obtemos o erro típico de conectividade:

Ocorreu um erro relacionado à rede ou específico da instância ao estabelecer uma conexão com o SQL Server. Servidor não encontrado ou não acessível. Verifique se o nome da instância está correto e se o SQL Server está configurado para permitir conexões remotas.

O log de erro do SQL Server em UT02 não mostra logins com falha (ele é configurado com o padrão para auditar logins com falha).

ping UTAGretorna o endereço IP correto, 192.168.0.13, independentemente de onde eu o executo. ping UTAGfunciona corretamente na sub-rede local e funciona nas sub-redes remotas quando o AG está sendo executado em UT01, mas não quando UT02 é o primário.

Instalei o WireShark no UT01 e no UT02 para ver se consigo determinar o que está acontecendo. Eu filtrei a saída do WireShark:

((tcp.port == 2136) || (udp.port == 1434)) && ((ip.dst == 192.168.0.13 || ip.src == 192.168.0.13))

A porta de escuta do SQL Server AG está configurada para escutar na porta 2136 e ambas as instâncias também estão configuradas para escutar na porta 2136. O SQL Server Configuration Manager mostra que a configuração de rede está configurada para escutar em todos os endereços IP.

Assistir ao WireShark no UT01, ao tentar se conectar ao AG de um cliente localizado em outra sub-rede, mostra o tráfego TCP de entrada na porta 2136 e o ​​tráfego UDP na porta 1434, independentemente de qual nó é o AG primário. Quando o AG primário está sendo executado em UT01, a conexão com o AG funciona, quando o AG primário está em UT02, a conexão com o AG falha.

Ambos os servidores são máquinas virtuais, rodando em hosts físicos separados. O switch (virtual ou não) está claramente ciente de qual nó está executando o primário, pois ping UTAGa partir da sub-rede local funciona independentemente de qual nó possui o endereço IP UTAG. ping UTAGde qualquer outra sub-rede só responde quando o AG está rodando em UT01.

Alguma ideia?