ppp0 ou ppp1? Como nomear uma sessão VPN PPP para scripts

O script do hook é acionado, lê ppp0 e aplica rotas à interface que tiver esse nome naquele momento. Às vezes é o túnel que você pretendia; às vezes é uma sessão que se conectou um minuto antes. A próxima reconexão muda o número, e o mesmo script configura silenciosamente o link errado. A correção é pegar a interface da invocação que acabou de executar e carregar o perfil pretendido ao lado dela.

Acompanhe uma sessão das opções até o hook

Comece onde a sessão é criada. O xl2tpd inicia o pppd com o arquivo de opções indicado pelo pppoptfile desse túnel, então o plugin, o número da unidade e qualquer marcador de perfil são decididos ali e não em um arquivo global. Um gerenciador de conexões pode gerar suas próprias opções, o que significa que editar /etc/ppp/options não é prova de que o túnel que lhe importa mudou. Quando o link sobe, o pppd executa os scripts de notificação do despachante da distribuição. Esses scripts recebem o nome da interface como primeiro argumento e o marcador de perfil como sexto.

O ambiente carrega os mesmos fatos sob nomes como IFNAME e PPP_IPPARAM, mas a disponibilidade deles depende do despachante instalado. Leia o despachante antes de confiar em uma variável: algumas distribuições mantêm a ordem dos argumentos upstream, outras filtram o ambiente antes de chamar seu script. Um script que usa apenas $1 e o sexto argumento funciona nas duas disposições.

Leia a interface a partir da invocação

O hook tradicional recebe a interface primeiro. Esse valor posicional é o identificador de interface que descreve a sessão que acionou o script. Guarde-o em uma variável no topo e depois use essa variável para rotas, regras de firewall e desmontagem.

ipparam office-vpn

Anexe um marcador de perfil onde as opções são definidas, não no script. Com essa linha no arquivo de opções do túnel, toda sessão criada a partir desse arquivo carrega office-vpn como sexto argumento. O script pode ramificar pelo marcador enquanto ainda age na interface real. Mantenha os dois separados no código, porque o marcador é estável e a interface é alocada por sessão.

Peça um nome apenas se a recusa estiver correta

Um nome fixo parece mais simples do que ler argumentos, mas muda o comportamento em caso de falha. A opção unit pede um número para uma conexão de saída, e o pppd recorre a uma alocação dinâmica quando essa unidade já está ocupada. Nada nesse resultado reserva o ppp0 para o seu perfil.

ifname ppp-office

A opção ifname comporta-se de forma diferente: se o nome pedido já estiver em uso ou não puder ser atribuído, o pppd encerra em vez de escolher outro. É uma escolha de política, não uma renomeação cosmética. Use-a quando uma segunda instância simultânea do mesmo perfil deve ser recusada, e confirme que o pppd instalado e o seu gerenciador de conexões repassam a opção.

De qualquer modo, o nome que o script vê é aquele sobre o qual se deve agir. Um nome configurado não elimina a necessidade de ler a invocação, porque uma sessão reiniciada ainda pode apresentar um nome diferente do anterior.

Faça a desmontagem corresponder à sessão configurada

Rotas e regras de firewall sobrevivem ao script que as criou, então a desmontagem precisa remover exatamente os objetos que a sessão possui. Marque as regras com o marcador de perfil e também com a interface, e exclua por essa marca. Se dois túneis podem estar ativos, apagar tudo que menciona ppp é como uma desconexão quebra a outra conexão.

Teste o caso que expõe o bug: suba a segunda sessão PPP enquanto a primeira ainda está conectada, depois reconecte a primeira e observe qual interface o hook relata. Uma execução bem-sucedida com uma única sessão não prova nada sobre a alocação de nomes. Repita com a VPN parada para confirmar que a desmontagem não deixa uma rota obsoleta.

Mantenha o marcador, a interface e o caminho do hook nas notas de implantação. Quando o número muda após uma reinicialização, esses três valores explicam por que o script se comportou diferente sem nenhuma edição de configuração.