Três decisões de endereço antes de colocar sensores IoT atrás de uma VPN
Três endereços cumprem três funções: o concentrador público, o par de site autenticado e o endereço privado do sensor. Planeje cada um antes de atribuir algo público.
Três endereços se emaranham em todo plano de IoT sobre VPN, e eles não são o mesmo tipo de decisão. Um é como um operador remoto encontra o ponto final do túnel, outro é como o site prova que é o site, e outro é onde o serviço do sensor realmente escuta. Responda naquela ordem e o desenho quase sai sozinho. Responda como uma única pergunta e você acabará atribuindo endereços públicos a dispositivos que nunca precisaram de um. Um sensor atrás de um túnel de site de saída é alcançável por um operador autorizado sem nenhuma regra de entrada apontando para o sensor.
Comece por quem inicia
Quem disca determina quase tudo depois. Quando o site disca para um concentrador, o site não precisa de alcançabilidade de entrada, e o concentrador precisa de um nome ou endereço que o site consiga resolver. Essa única escolha elimina a maior parte do debate sobre endereçamento público estático antes de ele começar.
Os três papéis então se separam com clareza, e a tabela abaixo é a forma mais curta da decisão.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
Cada linha tem um proprietário diferente, e esse é o ponto real. O concentrador pertence a quem opera o serviço de VPN, o par do site à equipe de rede, e o endereço do sensor a quem possui o dispositivo.
O endereço do concentrador é de inicialização, não um destino
Um nome que resolve para um endereço público mantido basta para o concentrador. Um registro DNS pode acompanhar o ponto final quando ele se move, sem editar à mão cada configuração de site. O que o DNS não faz é criar alcançabilidade ou atualizar um cliente que armazena em cache a resposta antiga, e esses são problemas separados com correções separadas.
Se você opera túneis de site para site sem concentrador, a mesma lógica vale em outra forma: um lado precisa de um ponto final alcançável, ou os dois lados discam para um terceiro. Alguém ainda precisa ser dono desse endereço e das suas renovações.
O par do site é uma identidade com um prefixo anexado
O par é primeiro uma identidade e depois um prefixo. Em termos de WireGuard, o par guarda um par de chaves e a entrada AllowedIPs do concentrador amarra essa chave ao prefixo do site. Em termos de IKEv2, um certificado ou chave pré-compartilhada identifica o site e os seus seletores de tráfego dizem o que ele pode transportar. Mudar apenas uma metade quebra o arranjo, e por isso uma mudança de endereço nunca deve ser tratada como mudança de identidade.
Mantenha a propriedade da chave ou do certificado no site e não no operador do concentrador, para que uma troca de provedor não vire troca de identidade.
O prefixo é a parte que as pessoas esquecem de planejar. O concentrador precisa associar a sub-rede do sensor ao par correto, e o cliente do operador precisa de uma rota até ela; uma rota que só existe no cliente envia tráfego para um túnel que o descarta em silêncio. Escreva o prefixo no registro do site junto da impressão digital da chave, para que um gateway substituído não possa aparecer com cobertura diferente sem que ninguém perceba.
O endereço do sensor pertence à aplicação
Um endereço privado do plano do site é suficiente, e o que ele precisa é de estabilidade em vez de alcançabilidade pública: uma reserva DHCP, uma atribuição estática ou um nome na zona do próprio site. Se o dispositivo não puder ser renumerado, a tradução no gateway do site é uma resposta legítima, desde que a tradução esteja documentada e o tráfego de retorno a siga.
Outro hábito que vale a pena manter: nunca cole o endereço público do concentrador num campo de próximo salto no host do sensor. A VPN instala o seu próprio caminho, e uma adjacência Ethernet comum com um ponto final público é uma ficção que produz configuração de aparência convincente.
As respostas são a metade que fica de fora. O dispositivo precisa enviar a sua resposta de volta para o túnel, seja por uma rota até o cliente do operador, seja pelo mesmo gateway que traduziu o pedido. Um sensor com o gateway padrão errado aceita o pedido e responde para o vazio, e as notas de encaminhamento explicam por que chegada e encaminhamento da resposta são dois requisitos e não um.
Decida, e depois escreva o limite
Escreva o limite de acesso antes de alguém se conectar. Restrinja o gateway ao segmento de IoT e aos serviços específicos de que o operador precisa, porque uma rota que funciona tende a se tornar acesso geral por acidente. Mantenha o monitoramento apenas de leitura e a autoridade de configuração como papéis separados com identidades separadas, e nomeie a pessoa que remove o acesso quando o contrato termina.
A aprovação pertence ao proprietário da rede, e estar numa DMZ não é uma política de acesso.
O teste após a implantação é monótono e conclusivo: um pedido dentro do prefixo permitido que tem sucesso, um contador que sobe no gateway, e uma tentativa deliberada fora do prefixo que falha.