Uma rota VPN fixada a um índice de interface quebra ao reconectar

A rota funcionou durante semanas e depois começou a enviar tráfego para lugar nenhum, com o destino inalterado e nada editado. O que mudou foi o número: uma rota criada contra um índice de interface específico refere um adaptador que já não existe após uma reconexão, e o prefixo de destino continua a apontar para uma infraestrutura que foi substituída. Acrescentar persistência a esse comando não ajuda, porque o problema nunca foi se a rota sobrevivia a um reinício. A solução é ligar a intenção à ligação, que por desenho sobrevive às trocas de adaptador.

Verifique para onde a rota aponta de facto

Comece por ler a entrada da rota e os adaptadores lado a lado. Uma rota com o próximo salto na interface VPN e um índice que não corresponde a nenhum adaptador atual é a assinatura desta falha; o mesmo prefixo noutro índice é ou um resto ou a rota que realmente quer. Leia as duas listas antes de alterar qualquer uma, porque a comparação interessante é entre o número da rota e os números que existem agora. Se o índice da rota aparecer na lista de adaptadores, o índice não é o seu problema e a procura passa para métricas, política ou o extremo remoto. Se não aparecer, não há mais nada a diagnosticar: a rota está ligada a uma infraestrutura que já não existe.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

A coluna Store distingue uma entrada que persiste entre reinícios de uma que desaparece com o adaptador, e essa diferença determina se a falha volta amanhã. Uma entrada no armazenamento persistente que aponta para um índice desaparecido é o pior caso, porque sobrevive a reinícios sem nunca corresponder a nada.

Ligue o prefixo ao perfil, não ao adaptador

Uma VPN nativa do Windows pode transportar a sua própria lista de rotas, pelo que a ligação reutiliza o adaptador correto sempre que aparece. A rota segue então o perfil em vez de um número que observou uma vez, e nenhum script tem de adivinhar um índice após cada chamada. Acrescentar um prefixo também é reversível através do comando de remoção correspondente, o que mantém a alteração auditável. O prefixo é guardado com a ligação em vez de num script de arranque, pelo que um perfil copiado para outro utilizador leva a intenção consigo.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

A referência de Add-VpnConnectionRoute documenta a associação à ligação, e o âmbito da lista telefónica importa: um perfil por utilizador e um perfil para todos os utilizadores são objetos diferentes. Este mecanismo pertence ao cliente VPN do próprio Windows, pelo que um adaptador de fornecedor gerido pelo seu próprio serviço pode retirar as suas rotas de uma fonte de política completamente diferente.

Limpe as rotas antigas antes de acrescentar a nova

Duas rotas com o mesmo prefixo e donos diferentes são piores do que uma rota errada, porque o vencedor depende de métricas que ninguém registou. Inspecione o que já existe para o prefixo, incluindo entradas no armazenamento persistente, e remova apenas o que pertence à tentativa falhada. Um resto de um desenho anterior é comum nesta área, já que a rota que falha normalmente substituiu algo que funcionava. Anote que entradas pertencem a que ligação antes de remover seja o que for, e guarde a lista no registo de alterações.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Faça corresponder prefixo, próximo salto, armazenamento e dono em conjunto em vez de apagar tudo o que parece semelhante. Outra ligação pode depender legitimamente de parte desse espaço, e uma eliminação abrangente transforma uma reparação arrumada num incidente de suporte.

Reconecte numa ordem diferente

Reproduza a condição em vez de esperar que a primeira tentativa fosse representativa. Desligue, reconecte e confirme o caminho selecionado para o mesmo recurso remoto enquanto o túnel está ativo; com várias VPN em jogo, suba-as numa ordem diferente e observe se o caminho escolhido muda. A ordem é a variável que quase todos saltam, e é a que expõe uma rota ligada à ligação errada.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

O resultado que quer não é que um adaptador conserve o seu número uma vez. É que a rota apareça com qualquer número que a ligação receba, sempre, e desapareça quando a ligação fecha. Reconectar duas vezes é a forma mais barata de distinguir esses resultados.

Saiba o que a rota não pode fazer

Uma rota de perfil fornece um caminho e nada mais. Não abre uma firewall remota, não cria uma rota de retorno no extremo remoto nem resolve dois locais que usam o mesmo intervalo de endereços; cada um desses é uma configuração separada com um dono separado. Confirmar o caminho é, portanto, o início do teste de aceitação e não o teste todo.

Mantenha a lista de prefixos junto ao perfil e anote sob que âmbito foi acrescentado, para que a pessoa seguinte possa ler o desenho pretendido em vez de o deduzir de uma tabela de rotas. As rotas que só existem na memória de alguém são as que são reconstruídas mal após a reconexão seguinte. Um comentário de uma linha nas notas de implementação custa menos do que uma tarde de redescoberta.