Administrer un Raspberry Pi sur un LAN sans liaison internet

Deux appareils sur un LAN privé peuvent échanger du trafic protégé sans aucune liaison montante. Ce qu'ils ne peuvent pas faire, c'est faire apparaître les services que leur modèle de sécurité attend. Le travail se partage donc entre le choix et l'inventaire : choisissez la protection adaptée à la tâche, puis listez tout ce qui irait discrètement chercher l'internet.

L'hypothèse de ce parcours est que les deux appareils disposent d'adresses approuvées sur le même réseau privé. N'en déduisez pas qu'ils sont joignables du simple fait qu'ils ont rejoint le même Wi-Fi ; le raccordement, le routage et les règles d'accès en décident encore.

Choisir la protection selon la tâche, pas par habitude

Une session de terminal ou une tâche d'administration de fichiers prise en charge convient à SSH, dont l'architecture sépare l'authentification du serveur, l'authentification de l'utilisateur et les canaux transportés à l'intérieur du transport protégé. Aucun de ces rôles n'exige un fournisseur de VPN commercial, et aucun d'eux ne cesse de fonctionner parce qu'il n'existe pas de route par défaut vers l'internet.

Un service TCP supplémentaire peut passer par une redirection SSH autorisée lorsque le serveur le permet : gardez l'écouteur local étroitement lié et la destination explicite, et rappelez-vous que cela redirige ce seul service plutôt que de reproduire un segment Ethernet.

L'accès routé à plusieurs adresses ou protocoles est une autre exigence, et un VPN terminé localement peut la fournir. Le pair est alors une passerelle locale joignable, pas un point de terminaison quelque part sur l'internet, et la passerelle a toujours besoin des routes prévues, des règles de redirection et des autorisations de service. Là où une seule application parle déjà correctement TLS, la laisser protéger sa propre connexion est souvent la plus petite réponse qui fonctionne.

Inventorier ce qui quitterait le LAN

Mettez en place les logiciels, les identités d'hôte et les identifiants avant de dépendre d'un banc isolé, ou utilisez le processus de livraison hors ligne que l'organisation prend en charge. Une commande de téléchargement n'est pas un plan d'installation pour une machine qui ne peut pas atteindre la source, et le découvrir pendant une panne est un mauvais moment pour l'apprendre.

Rendez le nommage délibéré. Utilisez le service DNS local prévu ou un agencement d'adresses documenté, car un résolveur public configuré ne crée pas de chemin vers lui-même. Changer une adresse de socket n'est pas non plus une justification pour contourner les contrôles d'identité de l'application. Si la réponse est que le banc utilise simplement des adresses, notez-le aussi, afin que l'ingénieur suivant ne passe pas une heure sur un domaine de recherche qui n'a jamais été configuré.

Lisez ensuite le modèle d'authentification et de vérification des dépendances externes : enrôlement, fournisseur d'identité, approbation multifacteur, récupération du statut de certificat, source de temps. Chacune est un blocage potentiel sur un réseau isolé. Listez-les avant la fenêtre de maintenance, pas pendant, car une dépendance découverte au mauvais moment transforme une tâche de cinq minutes en un après-midi. Prévoyez un dispositif joignable approuvé ou choisissez un modèle qui fonctionne hors ligne, et ne désactivez jamais silencieusement un contrôle parce que son service manque.

Garder les contrôles d'identité là où ils ont leur place

Vérifiez la clé d'hôte ou le certificat attendu via le processus de provisionnement auquel vous faites confiance, et gardez l'horloge correcte là où le protocole valide les dates de certificat. Partager un commutateur avec un appareil ne fait pas de cet appareil celui que vous vouliez joindre, et supposer le contraire est exactement l'erreur qu'un attaquant sur le même segment aimerait que vous fassiez.

Le temps mérite sa propre ligne dans le plan. De nombreux protocoles rejettent des identifiants par ailleurs valides lorsque l'horloge a suffisamment dérivé, et un Pi sans source de temps réseau peut dériver tranquillement pendant des mois avant que quoi que ce soit ne se plaigne.

Tester avec la liaison montante réellement absente

Débranchez la liaison montante, puis effectuez exactement l'opération de maintenance pour laquelle vous avez conçu : la session de terminal, la copie de fichier, le service redirigé, la connexion routée. Confirmez qu'une identité refusée ou une ressource interdite reste refusée, car une conception qui ne prouve que le chemin heureux n'a pas été testée du tout. Lisez les journaux pendant que vous le faites, car les échecs intéressants sont ceux qui laissent une trace sans changer le résultat.

Consignez le point de terminaison local, le mécanisme de protection et chaque dépendance utilisée par l'opération. La sortie vers l'internet et un chemin sûr pour l'administration locale sont deux exigences différentes, et les garder séparées est ce qui permet à la seconde de survivre à la perte de la première.