Mantenha vários túneis vpnc ativos com sondagens por perfil

Um perfil vpnc reconecta-se de forma limpa após um roaming; três deles acabam por quebrar, à vez, os sockets, as rotas e o estado do resolvedor uns dos outros. O script de reconexão do pacote foi escrito para um único túnel, por isso reinicia todos os perfis sempre que qualquer um deles está em baixo. Corrigir isso exige três coisas: portas locais separadas, uma sondagem que teste um serviço real por perfil e uma cadeia ordenada que nunca execute duas ligações ao mesmo tempo.

Dê a cada perfil a sua própria porta local

Um perfil vpnc deixado na porta local predefinida compete com o perfil que já está a correr. A segunda ligação falha enquanto a primeira mantém a porta, e a linha do registo parece um problema de gateway e não um conflito local. Em vez disso, defina uma linha por ficheiro de perfil:

Local Port 0

O zero deixa o kernel escolher uma porta efémera, pelo que dois perfis podem ser estabelecidos ao mesmo tempo. Nomeie cada ficheiro pela gateway e pelo grupo que serve, mantenha-o legível apenas para o root e ligue-se sempre com o perfil correspondente em vez de uma predefinição partilhada. Um ficheiro predefinido partilhado é a forma como um script reconecta o túnel errado depois de alguém mudar o nome de um perfil.

Os ficheiros de perfil contêm credenciais, por isso as permissões fazem parte do desenho e não da arrumação. Um ficheiro legível por todos em /etc/vpnc entrega o segredo do grupo a cada utilizador local. Mantenha o modo em 0600 com o root como proprietário e deixe os scripts ler o ficheiro como root em vez de copiar segredos para argumentos. É também por isso que um script de sondagem nunca deve escrever o conteúdo do ficheiro num registo.

Sonde um serviço por perfil, não o endereço do túnel

Um pedido de eco para o próprio endereço do túnel prova sobretudo que a interface existe. Não diz nada sobre se o anfitrião por trás dela ainda alcança a aplicação que justifica o túnel. A interface pode estar ativa enquanto a rota além dela já desapareceu.

Sonde um serviço por perfil com um curto tempo limite TCP e reconecte apenas o perfil cuja sondagem falhou. Dois segundos separam um caminho morto de um lento, e uma sondagem TCP não depende de o ICMP ser permitido em algum ponto do caminho. Altere apenas o alvo e o nome da configuração entre perfis:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

Guarde isso como /usr/local/bin/ensure-vpn-ops.sh, torne-o executável e repita para cada perfil alterando apenas o alvo da sondagem e o nome da configuração. Uma sondagem que responde a uma pergunta de protocolo sobrevive a gateways que descartam o eco mas continuam a encaminhar os serviços que interessam aos utilizadores.

Encadeie as sondagens para que nunca compitam

O script de reconexão do pacote pode chamar as suas sondagens em sequência, e a sequência é todo o objetivo. Duas chamadas de vpnc-connect a correr em conjunto reescrevem a tabela de encaminhamento numa ordem que ninguém controla, e é assim que um perfil saudável perde a sua rota.

Mantenha as chamadas em primeiro plano, acrescente uma breve pausa de estabilização para a interface subjacente e agende a cadeia a partir da tabela cron do root, já que só o root pode reescrever as rotas do túnel:

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

Mantenha a ordem idêntica entre o script de arranque e a entrada cron, pois uma cadeia que no arranque corre numa ordem diferente é efetivamente outro programa. Quando um perfil depende das rotas de outro, coloque a dependência primeiro e deixe a sondagem posterior falhar sem dano enquanto o túnel anterior ainda está a subir.

Vigie o registo e depois quebre um de propósito

Registe uma linha por execução com o perfil, o alvo da sondagem, o resultado e a ação tomada. Sem isso, um túnel que oscila a cada minuto parece exatamente um que nunca caiu, e um erro na sondagem é indistinguível de uma falha do gateway. O registo também prova que a cadeia tocou apenas o perfil que falhou. Escreva-o num local que sobreviva a um reinício, senão as provas saem com o processo.

Depois quebre um túnel deliberadamente e veja o que acontece. Pare um único perfil e confirme que processos e rotas ainda estão presentes:

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

Apenas o perfil parado deve ser reconectado, e as outras sessões devem conservar tanto os processos como as rotas. Se dois perfis reiniciarem, a sua cadeia está a correr em paralelo num lugar que não esperava.

O que o vigilante não deve fazer

Um vigilante que reinicia tudo sempre que algo falha parece saudável durante os testes e provoca uma falha numa janela de manutenção. Reinicie por perfil, nunca globalmente.

Prefira um cliente mantido quando a gateway oferece um para o mesmo protocolo, e nunca codifique uma palavra-passe no script nem a passe numa linha de comandos, porque o ficheiro de perfil já guarda o segredo. Se uma tarefa tiver de correr como utilizador comum depois de o túnel estar ativo, reduza privilégios dentro do script em vez de fazer correr toda a cadeia com essa conta. Por fim, releia as rotas após uma reconexão, porque um perfil pode voltar com outro endereço atribuído e deixar uma rota obsoleta que nenhuma sondagem dirigida ao endereço do túnel notará jamais.