Einen Raspberry Pi in einem LAN ohne Internet-Uplink administrieren

Zwei Geräte in einem privaten LAN können geschützten Verkehr ganz ohne Uplink austauschen. Was sie nicht können, ist, die Dienste herbeizuzaubern, die ihr gewähltes Sicherheitsmodell erwartet. Die Arbeit ist daher halb Auswahl und halb Bestandsaufnahme: Wählen Sie den Schutz, der zur Aufgabe passt, und listen Sie dann alles auf, was still nach dem Internet greifen würde.

Die Prämisse für diesen Durchlauf ist, dass beide Geräte genehmigte Adressen im selben privaten Netz besitzen. Schließen Sie nicht allein daraus auf Erreichbarkeit, dass beide demselben WLAN beigetreten sind; die Anbindung, das Routing und die Zugriffsregeln entscheiden weiterhin darüber.

Schutz nach Aufgabe wählen, nicht nach Gewohnheit

Eine Terminalsitzung oder eine unterstützte Dateiverwaltungsaufgabe passt zu SSH, dessen Architektur Server-Authentifizierung, Benutzerauthentifizierung und die im geschützten Transport geführten Kanäle trennt. Keine dieser Rollen benötigt einen kommerziellen VPN-Anbieter, und keine von ihnen hört auf zu funktionieren, weil keine Standardroute ins Internet existiert.

Ein zusätzlicher TCP-Dienst kann durch eine autorisierte SSH-Weiterleitung reisen, wenn der Server es erlaubt: Binden Sie den lokalen Listener eng und halten Sie das Ziel explizit, und denken Sie daran, dass dies den einen Dienst weiterleitet und kein Ethernet-Segment nachbildet.

Gerouteter Zugang zu mehreren Adressen oder Protokollen ist eine andere Anforderung, und ein lokal beendetes VPN kann sie liefern. Die Gegenseite ist in diesem Fall ein erreichbares lokales Gateway, kein Endpunkt irgendwo im Internet, und das Gateway braucht weiterhin die vorgesehenen Routen, Weiterleitungsregeln und Dienstberechtigungen. Wo eine einzelne Anwendung bereits ordnungsgemäß TLS spricht, ist es oft die kleinste funktionierende Antwort, sie ihre eigene Verbindung schützen zu lassen.

Bestandsaufnahme: Was das LAN verlassen würde

Bringen Sie Software, Host-Identitäten und Anmeldedaten an ihren Platz, bevor Sie sich auf eine isolierte Umgebung verlassen, oder nutzen Sie das Offline-Bereitstellungsverfahren, das die Organisation unterstützt. Ein Downloadbefehl ist kein Installationsplan für eine Maschine, die die Quelle nicht erreichen kann, und das während eines Ausfalls herauszufinden ist ein schlechter Zeitpunkt, um es zu lernen.

Gestalten Sie die Namensauflösung bewusst. Verwenden Sie den vorgesehenen lokalen DNS-Dienst oder eine dokumentierte Adressregelung, denn ein konfigurierter öffentlicher Resolver schafft keinen Pfad zu sich selbst. Das Ändern einer Socket-Adresse ist ebenso wenig eine Rechtfertigung dafür, die Identitätsprüfungen der Anwendung zu überspringen. Wenn die Antwort lautet, dass die Umgebung einfach Adressen verwendet, schreiben Sie auch das auf, damit der nächste Ingenieur nicht eine Stunde mit einer Suchdomäne verbringt, die nie konfiguriert wurde.

Dann lesen Sie das Authentifizierungs- und Verifikationsmodell auf externe Abhängigkeiten: Registrierung, ein Identitätsanbieter, eine Mehrfaktor-Bestätigung, der Abruf des Zertifikatsstatus, eine Zeitquelle. Jede davon ist ein möglicher Blocker in einem isolierten Netz. Listen Sie sie vor dem Wartungsfenster auf, nicht währenddessen, denn eine Abhängigkeit, die Sie im falschen Moment entdecken, macht aus einer fünfminütigen Aufgabe einen ganzen Nachmittag. Sorgen Sie für eine genehmigte erreichbare Regelung oder wählen Sie ein Modell, das offline funktioniert, und deaktivieren Sie niemals stillschweigend eine Prüfung, weil ihr Dienst fehlt.

Identitätsprüfungen bleiben, wo sie hingehören

Prüfen Sie den erwarteten Hostschlüssel oder das Zertifikat über den Bereitstellungsprozess, dem Sie vertrauen, und halten Sie die Uhr korrekt, wo das Protokoll Zertifikatszeiten prüft. Einen Switch mit einem Gerät zu teilen macht dieses Gerät nicht zu dem, das Sie erreichen wollten, und das Gegenteil anzunehmen ist genau der Fehler, den ein Angreifer im selben Segment Ihnen wünscht.

Die Zeit verdient eine eigene Zeile im Plan. Viele Protokolle weisen ansonsten gültige Anmeldedaten zurück, wenn die Uhr weit genug abgedriftet ist, und ein Pi ohne Netzwerkzeitquelle kann monatelang still abdriften, bevor irgendetwas sich beschwert.

Testen mit tatsächlich fehlendem Uplink

Ziehen Sie den Uplink ab und führen Sie dann genau die Wartungsoperation durch, für die Sie entworfen haben: die Terminalsitzung, das Kopieren von Dateien, den weitergeleiteten Dienst, die geroutete Verbindung. Bestätigen Sie, dass eine abgelehnte Identität oder eine verbotene Ressource weiterhin abgelehnt wird, denn ein Entwurf, der nur den Normalfall belegt, wurde überhaupt nicht getestet. Lesen Sie dabei die Protokolle, denn die interessanten Fehler sind diejenigen, die eine Spur hinterlassen, ohne das Ergebnis zu ändern.

Halten Sie den lokalen Endpunkt, den Schutzmechanismus und jede Abhängigkeit fest, die die Operation genutzt hat. Der Ausgang ins Internet und ein sicherer Pfad für die lokale Administration sind zwei verschiedene Anforderungen, und sie auseinanderzuhalten ist das, was es der zweiten ermöglicht, den Verlust der ersten zu überstehen.