Administrar un Raspberry Pi nunha LAN sen conexión a internet

Dous dispositivos nunha LAN privada poden intercambiar tráfico protexido sen ningún enlace ascendente. O que non poden facer é facer aparecer os servizos que espera o seu modelo de seguridade escollido. O traballo é, xa que logo, metade selección e metade inventario: escolla a protección que encaixa coa tarefa e despois enumere todo o que iría silenciosamente buscar internet.

A premisa deste percorrido é que ambos os dispositivos teñen enderezos aprobados na mesma rede privada. Non deduza a alcanzabilidade do feito de que ambos se unisen ao mesmo wifi; a conexión, o encamiñamento e as regras de acceso seguen decidíndoo.

Escolla a protección pola tarefa, non polo hábito

Unha sesión de terminal ou unha tarefa de administración de ficheiros admitida encaixa con SSH, cuxa arquitectura separa a autenticación do servidor, a autenticación do usuario e as canles transportadas dentro do transporte protexido. Ningún deses roles require un provedor de VPN comercial, e ningún deles deixa de funcionar porque non haxa unha ruta predeterminada cara a internet.

Un servizo TCP adicional pode viaxar por un reenvío SSH autorizado cando o servidor o permite: manteña o escoitador local estreitamente ligado e o destino explícito, e lembre que isto reenvía ese único servizo en lugar de reproducir un segmento Ethernet.

O acceso encamiñado a varios enderezos ou protocolos é un requisito distinto, e unha VPN terminada localmente pode fornecela. O par nese caso é unha pasarela local alcanzable, non un punto final nalgún lugar de internet, e a pasarela segue necesitando as rutas previstas, as regras de reenvío e os permisos de servizo. Onde unha única aplicación xa fala TLS correctamente, deixala protexer a súa propia conexión é a miúdo a resposta máis pequena que funciona.

Inventaríe o que sairía da LAN

Prepare o software, as identidades de host e as credenciais antes de depender dun banco illado, ou use o proceso de entrega sen conexión que admite a organización. Un comando de descarga non é un plan de instalación para unha máquina que non pode alcanzar a orixe, e descubrilo durante unha interrupción é un mal momento para aprendelo.

Faga deliberada a denominación. Use o servizo DNS local previsto ou unha disposición de enderezos documentada, porque un resolutor público configurado non crea un camiño cara a si mesmo. Cambiar un enderezo de socket tampouco é unha xustificación para saltar as comprobacións de identidade da aplicación. Se a resposta é que o banco simplemente usa enderezos, escriba iso tamén, para que o seguinte enxeñeiro non pase unha hora nun dominio de busca que nunca se configurou.

Despois lea o modelo de autenticación e verificación das dependencias externas: inscrición, un provedor de identidade, unha aprobación multifactor, a obtención do estado do certificado, unha fonte de tempo. Cada unha é un potencial bloqueo nunha rede illada. Enuméreos antes da xanela de mantemento, non durante, porque unha dependencia descuberta no momento equivocado converte unha tarefa de cinco minutos nunha tarde. Proporcione un arranxo alcanzable aprobado ou escolla un modelo que funcione sen conexión, e nunca desactive en silencio unha comprobación porque lle falte o seu servizo.

Manteña as comprobacións de identidade onde corresponden

Verifique a chave de host ou o certificado esperado mediante o proceso de aprovisionamento no que confía, e manteña o reloxo correcto onde o protocolo valida as horas do certificado. Compartir un conmutador cun dispositivo non fai que ese dispositivo sexa o que pretendía alcanzar, e supoñer o contrario é exactamente o erro que un atacante no mesmo segmento querería que cometera.

O tempo merece a súa propia liña no plan. Moitos protocolos rexeitan credenciais doutro xeito válidas cando o reloxo derivou o suficiente, e un Pi sen fonte de tempo de rede pode derivar en silencio durante meses antes de que algo se queixe.

Probe co enlace ascendente realmente ausente

Desconecte o enlace ascendente e realice despois a operación de mantemento exacta para a que deseñou: a sesión de terminal, a copia do ficheiro, o servizo reenviado, a conexión encamiñada. Confirme que unha identidade denegada ou un recurso prohibido seguen denegados, porque un deseño que só demostra o camiño feliz non se probou en absoluto. Lea os rexistros mentres o fai, xa que os fallos interesantes son os que deixan rastro sen cambiar o resultado.

Rexistre o punto final local, o mecanismo de protección e cada dependencia que usou a operación. A saída cara a internet e un camiño seguro para a administración local son dous requisitos diferentes, e mantelos separados é o que permite que o segundo sobreviva á perda do primeiro.