Que identificador a sua reserva de VPN precisa?

Três condições decidem qual identificador uma reserva deve usar: qual sistema distribui o endereço, se esse sistema chega a ver um quadro de camada 2 e o que ele usa como chave do cliente. Um router doméstico com DHCP, uma VPN em ponte e um túnel encaminhado respondem a essas perguntas de forma diferente. Escolher o identificador é mais duradouro do que tentar congelar cada endereço MAC que um adaptador relata, porque o identificador é o que o alocador realmente lê.

Comece pelo alocador e trabalhe de trás para a frente; o identificador do lado do cliente é o que esse sistema aceita.

Pergunte primeiro ao alocador

Um servidor DHCP aloca de um pool e compara as reservas com um identificador que reconhece, que pode ser o endereço de hardware, uma string de identificador de cliente ou um DUID conforme a versão do protocolo. Um servidor VPN aloca do seu próprio pool e compara com o que o seu modelo de configuração expõe, muitas vezes o Common Name autenticado. Uma rede em ponte pode entregar o mesmo problema ao servidor DHCP que já serve a LAN. Cada um é uma consulta diferente, e uma reserva válida num é invisível para os outros.

Confirme o que o servidor realmente vê antes de configurar qualquer coisa. Uma reserva que nomeia o identificador errado falha em silêncio: o cliente simplesmente recebe um endereço do pool, e o erro parece um problema do cliente.

Onde um endereço MAC ainda significa algo

Numa ligação Ethernet ou Wi-Fi física, o endereço de hardware identifica uma interface nesse segmento. As funções de privacidade rodam-no, os adaptadores virtuais criam novos, e um portátil pode apresentar valores diferentes em Wi-Fi e numa dock. Um túnel TUN encaminhado transporta pacotes IP e não transmite a identidade sem fios original a um servidor DHCP remoto, pelo que uma reserva baseada em MAC nesse caminho não tem com que comparar. TAP é diferente: transporta tramas Ethernet e pode juntar-se a um domínio em ponte onde os identificadores de camada 2 ainda importam.

Mesmo aí, o endereço relevante é o usado nesse domínio, não automaticamente o da ligação física superior.

Endereços de túnel e chaves de par têm o seu próprio espaço

Uma implementação de OpenVPN encaminhada atribui endereços através do seu próprio modelo: configuração por cliente com chave por nome autenticado, ou um pool explícito. Alterar a reserva DHCP de um router de LAN não cria essa atribuição, e acrescentar uma reserva de túnel não influencia a LAN. O WireGuard vai mais longe, porque um par é identificado pela sua chave pública e pelos endereços permitidos, não por qualquer identificador de hardware. Nenhuma reserva Ethernet genérica substitui aí a configuração do par.

Mantenha um inventário que separe quatro objetos: a credencial do dispositivo, o adaptador virtual, o identificador do alocador e o endereço atribuído. Uma mesma máquina física pode ter vários adaptadores, endereços e sessões.

Um endereço estável não é uma identidade

Um endereço previsível é cómodo em operação e não é uma credencial de autenticação. As regras de acesso que dependem de um endereço deixam de ser verificações de identidade no momento em que ele é reatribuído, partilhado ou falsificado. Se uma regra depende do endereço, coordene a reatribuição e a revogação com quem detém a identidade, e mantenha a decisão real de autenticação noutro lugar. Assim, uma comodidade não se torna a única prova de que dispositivo se ligou.

Registe o alocador, o identificador e o endereço atribuído em conjunto. Quando um muda, os outros dois são o que verifica.

Se dois sistemas afirmam ambos alocar para a mesma sub-rede, decida qual a possui antes de acrescentar reservas a qualquer um deles.