Rota do appliance OpenVPN: dono da configuração ou script de inicialização?
Uma rota de filial que sobrevive a um reinício ainda pode desaparecer após salvar na GUI ou uma atualização de firmware. Compare o dono de configuração suportado com um script de correção.
Você adiciona uma rota de filial, ela funciona, e então uma atualização de firmware ou um salvamento pela interface web a remove. Duas correções parecem igualmente razoáveis nesse momento: colocar a rota na fonte de configuração suportada do appliance ou adicioná-la ao arquivo gerado a partir de um script de inicialização. Elas se comportam igual por uma semana e divergem na segunda atualização. Este artigo compara o que cada uma realmente possui.
Os dois candidatos possuem coisas diferentes
A fonte de configuração suportada é tudo o que o appliance trata como entrada: um campo da GUI, um perfil importado, um diretório documentado por cliente, um banco de dados de ajustes que o pacote de gestão lê. O server.conf gerado é saída. Editar a saída funciona até o gerador rodar de novo, e isso acontece ao salvar, ao reiniciar e ao atualizar.
A abordagem com script aplica correções a essa saída depois que o gerador termina. É uma técnica legítima para um laboratório, e é o padrão errado para um escritório de filial, porque torna a rota dependente de correspondência de texto em vez de um campo documentado.
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
O que o appliance regenera, e quando
Os pacotes de gestão normalmente mantêm os ajustes em um banco de dados ou conjunto de modelos e geram a configuração do daemon na inicialização. Um salvamento pela interface web costuma reescrever o arquivo inteiro em vez de corrigir uma linha. Se a sua alteração vivia nesse arquivo, agora ela sumiu, e nada registra um aviso, porque do ponto de vista do appliance nada foi perdido.
Os wrappers de inicialização têm um segundo modo de falha. Um grep para uma diretiva com espaçamento específico deixa de corresponder após uma mudança de modelo, e o script silenciosamente não faz nada. Pior ainda, uma atualização de firmware pode substituir o wrapper por uma versão nova, levando a correção consigo. Você então tem uma rota que existiu por um ano e desapareceu durante uma manutenção que ninguém relacionou ao roteamento.
O que o dono suportado deve expressar
Um prefixo de filial precisa de três declarações, não de uma. O cliente precisa aprender a rota, o servidor precisa saber qual cliente autenticado possui o prefixo, e o lado da filial precisa devolver o tráfego ao endereço de túnel que recebeu. Em termos de OpenVPN isso significa um route enviado, um iroute correspondente ligado ao cliente, e um caminho de retorno do outro lado.
É aqui que as interfaces dos appliances enganam. Uma caixa marcada «permitir que os clientes acessem a LAN do servidor» descreve tráfego para a própria rede do servidor. A sua filial é a direção oposta: uma rede atrás de um cliente, alcançável pelo lado do servidor. O mesmo rótulo não implica suporte a isso, e uma diretiva válida num arquivo não é promessa de que o pacote a preserve.
Quando não existe controle suportado
Às vezes a versão instalada realmente não consegue expressar uma rota específica de um par. Então as opções honestas são outro gateway que você controla, ou um modo site a site suportado nas duas pontas. As duas pontas precisam falá-lo. Uma página de produto que diz site a site não torna um perfil OpenVPN arbitrário intercambiável com o túnel de outro protocolo, e forçar esse emparelhamento costuma produzir um túnel meio conectado que parece bom numa página de status.
Escolha a opção que você consegue descrever em uma frase a quem herdar a rede. Se a resposta exige mencionar um caminho de script e um padrão de texto, o desenho já é frágil.
Torne a intenção auditável
Registre o contrato fora do appliance: identidade efetiva do cliente, prefixo, gateway de retorno e o campo suportado que fornece cada um. Exporte a configuração pelo mecanismo suportado para que uma reconstrução tenha referência, e verifique o serviço após uma reconexão, um reinício e uma atualização, em vez de apenas após a mudança.
Compare o resultado gerado com esse registro quando algo quebrar, em vez de restaurar uma linha sem explicação e esperar.referência do OpenVPN 2.6 é o lugar para confirmar como route e iroute interagem antes de discutir com uma interface.
Lista de verificação para a próxima mudança: nomeie o dono, declare o contrato em três partes, exporte a intenção e teste novamente após os próprios eventos do ciclo de vida do appliance, não após a sua edição.