Administrar una Raspberry Pi en una LAN sin enlace de internet

Dos dispositivos en una LAN privada pueden intercambiar tráfico protegido sin ningún enlace ascendente. Lo que no pueden hacer es hacer aparecer los servicios que espera su modelo de seguridad elegido. El trabajo es, por tanto, mitad selección y mitad inventario: elija la protección que encaja con la tarea y luego enumere todo lo que buscaría internet en silencio.

La premisa de este recorrido es que ambos dispositivos tienen direcciones aprobadas en la misma red privada. No deduzca la accesibilidad del hecho de que ambos se unieran al mismo wifi; la conexión, el enrutamiento y las reglas de acceso siguen decidiéndolo.

Elija la protección según la tarea, no por costumbre

Una sesión de terminal o una tarea de administración de archivos compatible encaja con SSH, cuya arquitectura separa la autenticación del servidor, la autenticación del usuario y los canales que se transportan dentro del transporte protegido. Ninguno de esos roles requiere un proveedor de VPN comercial, y ninguno deja de funcionar porque no haya una ruta predeterminada hacia internet.

Un servicio TCP adicional puede viajar por un reenvío SSH autorizado cuando el servidor lo permite: mantenga el escucha local estrechamente vinculado y el destino explícito, y recuerde que esto reenvía ese único servicio en lugar de reproducir un segmento Ethernet.

El acceso enrutado a varias direcciones o protocolos es un requisito distinto, y una VPN terminada localmente puede proporcionarlo. El par en ese caso es una puerta de enlace local accesible, no un extremo en algún lugar de internet, y la puerta de enlace sigue necesitando las rutas previstas, las reglas de reenvío y los permisos de servicio. Donde una sola aplicación ya habla TLS correctamente, dejar que proteja su propia conexión suele ser la respuesta más pequeña que funciona.

Inventaríe lo que saldría de la LAN

Prepare el software, las identidades de host y las credenciales antes de depender de un banco aislado, o utilice el proceso de entrega sin conexión que admite la organización. Un comando de descarga no es un plan de instalación para una máquina que no puede alcanzar el origen, y descubrirlo durante una interrupción es un mal momento para aprenderlo.

Haga que el nombrado sea deliberado. Utilice el servicio DNS local previsto o una disposición de direcciones documentada, porque un resolutor público configurado no crea un camino hacia sí mismo. Cambiar una dirección de socket tampoco justifica saltarse las comprobaciones de identidad de la aplicación. Si la respuesta es que el banco simplemente usa direcciones, anótelo también, para que el siguiente ingeniero no pase una hora en un dominio de búsqueda que nunca se configuró.

Después lea el modelo de autenticación y verificación de las dependencias externas: inscripción, un proveedor de identidad, una aprobación multifactor, la recuperación del estado del certificado, una fuente de tiempo. Cada una es un posible bloqueo en una red aislada. Enumérelas antes de la ventana de mantenimiento, no durante, porque una dependencia que descubre en el momento equivocado convierte una tarea de cinco minutos en una tarde entera. Proporcione un arreglo accesible aprobado o elija un modelo que funcione sin conexión, y nunca desactive en silencio una comprobación porque falte su servicio.

Mantenga las comprobaciones de identidad donde corresponden

Verifique la clave de host o el certificado esperado mediante el proceso de aprovisionamiento en el que confía, y mantenga el reloj correcto donde el protocolo valida las horas del certificado. Compartir un conmutador con un dispositivo no convierte a ese dispositivo en el que pretendía alcanzar, y suponer lo contrario es exactamente el error que un atacante en el mismo segmento querría que cometiera.

El tiempo merece su propia línea en el plan. Muchos protocolos rechazan credenciales por lo demás válidas cuando el reloj se ha desviado lo suficiente, y una Pi sin fuente de tiempo de red puede desviarse en silencio durante meses antes de que algo se queje.

Pruebe con el enlace ascendente realmente ausente

Desconecte el enlace ascendente y realice después la operación de mantenimiento exacta para la que diseñó: la sesión de terminal, la copia de archivos, el servicio reenviado, la conexión enrutada. Confirme que una identidad denegada o un recurso prohibido siguen denegados, porque un diseño que solo demuestra el camino feliz no se ha probado en absoluto. Lea los registros mientras lo hace, ya que los fallos interesantes son los que dejan rastro sin cambiar el resultado.

Registre el extremo local, el mecanismo de protección y cada dependencia que utilizó la operación. La salida a internet y una ruta segura para la administración local son dos requisitos distintos, y mantenerlos separados es lo que permite que el segundo sobreviva a la pérdida del primero.