O endereço do par mudou a meio da sessão: o que float faz no OpenVPN

O portátil passa do Wi-Fi do escritório para o hotspot de um telemóvel, o túnel aguenta mais alguns segundos e depois o tráfego pára, enquanto a interface continua a afirmar que está ligada. No servidor, a lista de estado continua a mostrar o endereço público antigo. Esta é a situação para a qual float existe, e é também a situação em que as pessoas esperam dele muito mais do que ele faz. Perceber bem a fronteira transforma uma paragem confusa numa alteração de configuração de uma linha ou numa investigação completamente diferente.

O que float relaxa e o que nunca relaxa

Normalmente uma sessão continua a falar com o endereço e a porta exteriores com que começou, e os pacotes que chegam de outro sítio são ignorados. A opção float remove essa ligação estrita depois de o par já se ter provado, pelo que um mapeamento de origem alterado pode continuar a mesma sessão em vez de ser descartado. Nada muda nas verificações criptográficas: as chaves, os certificados e qualquer proteção HMAC ficam exatamente como foram configurados.

É uma decisão por pacote, não uma política sobre quem se pode ligar. Uma máquina desconhecida que envie um pacote a partir de um novo endereço não provou nada, e o pacote é descartado como qualquer outro tráfego não autenticado. Só o tráfego que passa a autenticação da própria sessão pode mover o endereço do par registado, e é por isso que é seguro deixar float ligado em ambientes onde os clientes se deslocam.

Também não diz nada sobre o túnel interior. Um endereço exterior movido não reatribui um endereço de túnel, não altera o conjunto e não dá ao par acesso a algo novo. Dentro do túnel, a mesma identidade e as mesmas rotas empurradas aplicam-se antes e depois da deslocação. A deslocação também não renegocia o canal de dados, pelo que a cifra e as chaves negociadas continuam.

O pacote que move uma sessão tem de se autenticar

Inicie uma sessão da forma habitual contra o remoto configurado, e float trata do que acontece quando o mapeamento muda. Um operador móvel que renumera a meio do fluxo, um gateway NAT que reescreve o seu mapeamento de porta ou um portátil que troca de ligação ascendente produzem todos a mesma forma: pacotes autenticados de um novo tuplo, que chegam a uma sessão que ainda acredita no antigo.

Quando lhe perguntam se float funciona, a prova útil é um aperto de mão concluído seguido de uma mudança de origem aceite, não uma linha de registo apenas sobre o endereço. Relacione os endereços exteriores antigo e novo com a sessão que se manteve viva, e depois confirme que o tráfego continuou realmente pelo túnel.

Se a sessão morrer em vez de se deslocar, o pacote que chegou do novo endereço provavelmente falhou a autenticação ou nunca chegou. Os dois casos parecem idênticos do lado do cliente. No servidor, uma captura na interface pública diz-lhe qual dos dois tem antes de tocar em qualquer configuração.

A descoberta é um mecanismo totalmente separado

float não resolve nomes com um temporizador nem segue um registo DNS dinâmico. Se o nome de anfitrião do servidor começar a resolver para um novo endereço, um cliente inativo não tem motivo para reparar nisso nem pacote do novo extremo para autenticar. Esse problema pertence à lógica de reconexão, ao comportamento de nova tentativa do próprio cliente e ao DNS, não ao float.

Acrescentar a opção mais uma vez não compensa a ausência de rota para o novo endereço. Também não ajuda quando o par está silencioso, porque um par silencioso nunca envia o pacote autenticado que moveria alguma coisa.

A firewall subjacente também tem voto. Uma regra que só permite o extremo exterior antigo bloqueia o endereço alterado antes de OpenVPN o ver, e nenhuma configuração do lado do cliente resolve isso. Reveja o ciclo de vida dos endereços permitidos como uma tarefa própria; alargar a regra a qualquer origem troca um problema pequeno por um grande.

Quando o NetworkManager é dono do perfil

Um perfil de linha de comandos e uma ligação importada são configurações separadas, e editar uma não toca na outra. Antes de assumir que a opção não é suportada, determine que tipo de extensão o perfil guardado usa realmente e onde vivem os seus valores. O UUID do perfil é o identificador que importa quando inspeciona ou altera alguma coisa.

Inspecione a ligação guardada em vez do ficheiro de importação original. Uma linha que sobrevive num ficheiro .ovpn não prova nada se o gestor ativo nunca a aplicou, e um editor sem caixa de verificação para uma determinada opção também não prova nada sobre as capacidades do protocolo.

Não corrija uma extensão empacotada para acrescentar o comportamento, sobretudo não com um diff escrito para uma versão histórica de um componente não relacionado. Se a integração instalada realmente não consegue expressar a definição, o passo correto é um perfil suportado ou outro caminho de cliente aprovado por quem é dono da implementação.

Prove a transição em vez de a supor

Execute o teste tal como a falha acontece. Ligue-se, verifique o tráfego pelo túnel, force a mudança do endereço exterior e depois verifique três coisas: a sessão ainda existe, o endereço do par registado mudou e um pedido real ainda chega ao destino. Qualquer coisa menos do que as três é uma resposta parcial.

Mantenha o acesso de recuperação disponível enquanto testa, porque as experiências de itinerância têm o hábito de deixar a máquina de onde trabalha encalhada. Uma consola série ou uma rota fora de banda transforma um teste falhado numa recuperação de cinco minutos em vez de uma visita ao local.

Por fim, descreva apenas o caso que exercitou. Uma mudança de endereço bem-sucedida durante uma sessão não é prova de que migrações de DNS, outra implementação de cliente ou um perfil reconstruído se comportem da mesma forma. A documentação de link-options indica o âmbito da opção com precisão; o seu registo de teste deve indicar que parte desse âmbito cobriu realmente.