Novas conexões em uma nova saída VPN, fluxos antigos ficam como estão

Um dreno planejado move apenas fluxos não classificados. Compare isso com uma troca de rota e veja as marcas, tabelas e o estado do conntrack que o mantêm.

Duas saídas VPN saudáveis, um upload longo já em andamento e o requisito de que a próxima conexão use o outro túnel. Há duas maneiras de atender a isso, e apenas uma é segura em um gateway em produção. Trocar a rota padrão move cada pacote, inclusive os que pertencem ao upload. Um dreno planejado muda a escolha para novas conexões e deixa os fluxos rastreados no caminho em que começaram.

Duas maneiras de trocar uma saída

A troca de rota é um único comando e é reversível em segundos, por isso é usada durante incidentes. Ela também é indiscriminada: os pacotes do upload existente saem de repente por outro túnel, com outro endereço de origem público e estado de tradução separado.

Se o extremo remoto rastreia fluxos por endereço de origem, o upload pode simplesmente deixar de ser reconhecido. O dreno evita isso tomando a decisão uma vez por conexão e armazenando-a, de modo que o upload antigo mantém sua saída até terminar. Esse é todo o valor do exercício: o extremo remoto não vê nenhuma mudança que precise interpretar. Ele continua recebendo pacotes que correspondem à conexão que já conhece.

O custo é a complexidade: duas tabelas de roteamento, um classificador que roda no gancho correto e marcas que precisam ser coordenadas com tudo o mais na máquina que as usa.

Dê a cada saída sua própria tabela

Reserve uma tabela de roteamento por saída e valores de marca ou bits distintos para as duas escolhas. Cada tabela precisa das rotas adequadas ao seu papel, não apenas de um nome, e precisa de um resultado de falha deliberado para o caso ausente. Uma tabela vazia que cai silenciosamente na tabela principal — é assim que o tráfego sai por uma saída que ninguém escolheu.

ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102

Adicione uma rota blackhole ao final de cada tabela para que uma busca sem correspondência falhe ruidosamente em vez de escapar para um padrão que você não escolheu.

Escolha uma vez, no primeiro pacote

Classifique depois que o rastreamento de conexões existir e antes da busca de rota que importa. Para uma conexão LAN nova e não classificada, escolha a saída e guarde-a no estado da conexão. Nos pacotes seguintes, restaure o valor guardado na marca de pacote que o roteamento por política lê.

A parte sutil é o que significa novo. O conntrack ainda pode reportar NEW para pacotes iniciais e retransmissões antes de ver uma resposta, então um classificador que se baseia apenas nesse estado pode sobrescrever uma escolha que já fez. Verifique que não há saída guardada para a conexão antes de atribuir uma.

O nftables mantém as marcas de pacote e de conexão separadas, e o guia de metainformação documenta a cópia explícita entre elas. Uma marca de conexão não se torna por si só a marca de pacote com a qual sua regra coincide, e essa é a razão mais comum de um classificador cuidadosamente escrito não ter efeito.

Limite a restauração à direção e ao tráfego que você pretende. Aplicar uma marca de saída de internet aos pacotes de retorno pode enviar as respostas para a saída em vez da LAN, e o sintoma é uma conexão unidirecional que parece um problema de firewall. Leia o caminho de resposta antes de tocar em uma regra de firewall, porque o pacote está sendo roteado, só não de volta ao remetente.

Quatro fases de um dreno

  1. Prepare B sem tocar em A: roteamento, encaminhamento, autorização, NAT e o caminho de volta. Instale sua tabela e sua política de seleção pelo proprietário de configuração existente do gateway.

  2. Troque o classificador para que conexões novas e não classificadas escolham B, preservando as escolhas guardadas. Uma transação nftables atômica evita uma janela em que o estado antigo precise ser limpo.

  3. Deixe A ligado enquanto seus fluxos terminam. Sua interface, tabela, saída remota e mapeamentos NAT ainda fazem parte desses fluxos, e editar uma regra NAT não reconstrói vínculos que já existem.

  4. Aposente A quando a condição de dreno for cumprida, avaliada pelo estado das conexões e pelo comportamento da aplicação, não por um único intervalo silencioso.

O que um dreno não pode prometer

Uma requisição do navegador não é uma nova conexão de transporte; o agrupamento continua enviando requisições pela antiga. Por outro lado, um fluxo UDP pode envelhecer fora do conntrack e um pacote posterior é classificado de novo. O dreno segue os fluxos rastreados, não a ideia que uma aplicação tem de uma sessão.

Se A falhar antes de seus fluxos terminarem, a marca guardada não os salva. Eles se reconectam por B, ou não se reconectam de forma alguma. Um dreno planejado compra continuidade enquanto o caminho original está saudável; não é replicação de estado entre saídas independentes.

Verifique as duas metades

Inicie uma conexão permitida de longa duração antes da mudança e uma genuinamente nova depois. Confirme qual túnel cada uma usa e qual endereço de origem público o extremo remoto vê, e então verifique se o tráfego de retorno volta.

Não limpe a tabela de conntrack para fazer a nova escolha aparecer. Isso destrói exatamente o estado que o dreno deve preservar, e transforma uma migração controlada em uma interrupção com um teste de aparência limpa.

Artigos relacionados