Administrar um Raspberry Pi numa LAN sem ligação à internet

Dois dispositivos numa LAN privada podem trocar tráfego protegido sem qualquer ligação ascendente. O que não podem fazer é fazer aparecer os serviços que o modelo de segurança escolhido espera. O trabalho é, portanto, metade seleção e metade inventário: escolha a proteção que se ajusta à tarefa e depois liste tudo o que iria silenciosamente buscar a internet.

A premissa deste percurso é que ambos os dispositivos têm endereços aprovados na mesma rede privada. Não deduza a acessibilidade do facto de ambos se terem ligado ao mesmo wifi; a ligação, o encaminhamento e as regras de acesso continuam a decidir isso.

Escolha a proteção pela tarefa, não pelo hábito

Uma sessão de terminal ou uma tarefa de administração de ficheiros suportada encaixa no SSH, cuja arquitetura separa a autenticação do servidor, a autenticação do utilizador e os canais transportados dentro do transporte protegido. Nenhum desses papéis exige um fornecedor de VPN comercial, e nenhum deles deixa de funcionar por não existir uma rota predefinida para a internet.

Um serviço TCP adicional pode viajar por um encaminhamento SSH autorizado quando o servidor o permite: mantenha o ouvinte local estreitamente vinculado e o destino explícito, e lembre-se de que isto encaminha esse único serviço em vez de reproduzir um segmento Ethernet.

O acesso encaminhado a vários endereços ou protocolos é um requisito diferente, e uma VPN terminada localmente pode fornecê-lo. O par nesse caso é um gateway local acessível, não um ponto final algures na internet, e o gateway continua a precisar das rotas previstas, das regras de encaminhamento e das permissões de serviço. Onde uma única aplicação já fala TLS corretamente, deixá-la proteger a sua própria ligação é muitas vezes a resposta mais pequena que funciona.

Inventarie o que sairia da LAN

Prepare o software, as identidades de anfitrião e as credenciais antes de depender de uma bancada isolada, ou use o processo de entrega offline que a organização suporta. Um comando de transferência não é um plano de instalação para uma máquina que não consegue alcançar a origem, e descobri-lo durante uma falha é uma má altura para o aprender.

Torne a nomeação deliberada. Use o serviço DNS local previsto ou uma disposição de endereços documentada, porque um resolvedor público configurado não cria um caminho para si mesmo. Mudar um endereço de socket também não é justificação para saltar as verificações de identidade da aplicação. Se a resposta for que a bancada usa simplesmente endereços, escreva isso também, para que o próximo engenheiro não passe uma hora num domínio de pesquisa que nunca foi configurado.

Depois leia o modelo de autenticação e verificação das dependências externas: inscrição, um fornecedor de identidade, uma aprovação multifator, a obtenção do estado do certificado, uma fonte de tempo. Cada uma é um potencial bloqueio numa rede isolada. Liste-as antes da janela de manutenção, não durante, porque uma dependência descoberta na altura errada transforma uma tarefa de cinco minutos numa tarde. Proporcione um arranjo acessível aprovado ou escolha um modelo que funcione offline, e nunca desative silenciosamente uma verificação porque o seu serviço falta.

Mantenha as verificações de identidade onde pertencem

Verifique a chave de anfitrião ou o certificado esperado através do processo de aprovisionamento em que confia, e mantenha o relógio correto onde o protocolo valida as horas do certificado. Partilhar um comutador com um dispositivo não torna esse dispositivo aquele que pretendia alcançar, e assumir o contrário é exatamente o erro que um atacante no mesmo segmento gostaria que cometesse.

O tempo merece a sua própria linha no plano. Muitos protocolos rejeitam credenciais de outro modo válidas quando o relógio derivou o suficiente, e um Pi sem fonte de tempo de rede pode derivar em silêncio durante meses antes de algo se queixar.

Teste com a ligação ascendente realmente ausente

Desligue a ligação ascendente e execute depois a operação de manutenção exata para a qual desenhou: a sessão de terminal, a cópia do ficheiro, o serviço encaminhado, a ligação encaminhada. Confirme que uma identidade negada ou um recurso proibido continuam negados, porque um desenho que só prova o caminho feliz não foi testado de todo. Leia os registos enquanto o faz, pois as falhas interessantes são as que deixam rasto sem alterar o resultado.

Registe o ponto final local, o mecanismo de proteção e cada dependência usada pela operação. A saída para a internet e um caminho seguro para a administração local são dois requisitos diferentes, e mantê-los separados é o que permite ao segundo sobreviver à perda do primeiro.