Primeiro arranque: inscrição para uma frota de dispositivos WireGuard

Uma imagem, uma chave por placa e um passo de autorização que não confia na afirmação do próprio dispositivo. Quatro etapas do arranque a um peer confirmado.

A placa arranca a partir da imagem comum, obtém uma concessão DHCP e um script de aprovisionamento é executado antes de alguém ter tocado no dispositivo. Em algum ponto desse script tem de obter uma identidade WireGuard que pertence a esta placa e a nenhuma outra, fazer autorizar essa identidade e escrever um perfil que o gateway aceite. A imagem pode transportar o software cliente, um modelo revisto e a chave pública do gateway. O que nunca deve transportar é uma única chave privada partilhada por toda a frota, porque isso transforma uma só placa roubada num incidente para toda a frota. A ordem abaixo mantém a identidade local e a autorização explícita.

O que a imagem transporta e o que não transporta

Envie o pacote, o modelo com marcadores de posição, a chave pública do gateway e o cliente de inscrição. O modelo é uma forma, não um segredo: deve ser legível pelo utilizador de aprovisionamento e não conter qualquer material de chave.

A chave privada é gerada no dispositivo no primeiro arranque e nunca o abandona. Só viaja a metade pública, dentro de um pedido de inscrição autorizado por algo diferente da afirmação do próprio dispositivo sobre quem é. É essa distinção que impede uma placa roubada de se tornar um problema para toda a frota. E é também a parte que a maioria dos scripts de primeiro arranque faz mal.

Passo 1: gerar a chave localmente

Execute a geração num diretório protegido depois de a ligação de rede subjacente estar aprovada e a funcionar. A subshell mantém a alteração de umask local a esta operação, e set -C recusa-se a substituir um ficheiro existente:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

Início rápido do WireGuard documenta a relação de geração de chaves em que estes dois comandos se baseiam. Se a geração for interrompida, deixe o dispositivo sem registo e deixe o fluxo de trabalho reconciliar os ficheiros. Não elimine uma identidade existente só para que o script corra limpo desde o início.

Conserve a chave pendente entre tentativas. Regerar uma identidade após cada falha temporária de rede é a forma como uma frota acaba com peers órfãos que ninguém consegue emparelhar com um dispositivo.

Passo 2: autorizar um registo de dispositivo

Suponha que o inventário chama a esta placa device-042 e lhe atribui 10.90.0.42/32. O serviço de inscrição tem de verificar que este requerente tem direito a esse registo. Um número de série escrito num formulário não é prova, porque os números de série são impressos no exterior da caixa.

Uma credencial de arranque por dispositivo, uma aprovação de operador ou uma atestação com suporte de hardware podem estabelecer a afirmação. Proteja a integridade do pedido e a autenticidade da resposta, e não substitua um segredo VPN partilhado por uma credencial de fábrica partilhada.

O registo inscrito liga o dispositivo, a sua chave pública, o endereço atribuído e o seu papel de gestão permitido. O WireGuard em si não define qualquer API de inscrição, pelo que esse serviço é algo que constrói e opera deliberadamente.

Passo 3: escrever duas configurações correspondentes

O dispositivo precisa de um perfil que encaminhe os prefixos de gestão para o túnel, e o gateway precisa de uma entrada de peer que só permita o endereço de origem próprio deste dispositivo. Com um gateway em 10.90.0.1 e uma rede de gestão de 10.60.0.0/16, o lado do dispositivo fica assim:

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

Os valores entre parênteses retos são marcadores de posição, não chaves. O keepalive importa quando a placa está atrás de NAT e tem de permanecer acessível; não é necessário em todo o lado, e acrescentá-lo por hábito mantém um rádio desperto sem motivo.

No gateway, a entrada de peer é estreita por conceção:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

Não copie a lista de destinos do dispositivo para a entrada de peer do gateway. No dispositivo essa lista diz o que encaminhar para o túnel; no gateway diz que endereços de origem este peer pode usar, e são afirmações diferentes.

O encaminhamento, as regras de firewall e o caminho de retorno para a rede de gestão continuam a ter de permitir o acesso aprovado. Um peer inscrito não é permissão para cada aplicação por trás dele.

Passo 4: confirmar a inscrição como estado do ciclo de vida

Aplique o registo do gateway e o perfil do dispositivo através de quem possui cada configuração, e depois marque a inscrição como completa apenas quando a identidade e o endereço previstos forem aceites. As tentativas devem reconciliar esse mesmo registo em vez de atribuir um segundo peer ou um segundo endereço.

Mantenha um caminho de recuperação para aprovisionamento interrompido, incluindo o caso em que o gateway aceitou a chave e o dispositivo nunca escreveu o seu perfil.

Quando uma placa é substituída ou retirada, remova a sua chave pública e a sua autorização em conjunto. Uma chave nova é um evento deliberado de reinscrição, não um efeito secundário de uma reimagem. Ordem de trabalho: gerar localmente, autorizar contra o inventário, escrever os dois lados, confirmar o estado e depois testar um pedido de gestão através do túnel.

Artigos relacionados