Een Raspberry Pi beheren in een LAN zonder internet-uplink

Twee apparaten op een privé-LAN kunnen beveiligd verkeer uitwisselen zonder enige uplink. Wat ze niet kunnen, is de diensten tevoorschijn toveren die hun gekozen beveiligingsmodel verwacht. Het werk is dus half selectie en half inventarisatie: kies de bescherming die bij de taak past en inventariseer vervolgens alles wat stilletjes naar het internet zou grijpen.

De aanname voor deze uitleg is dat beide apparaten goedgekeurde adressen op hetzelfde privénetwerk hebben. Leid bereikbaarheid niet af uit het feit dat beide lid zijn van dezelfde wifi; de aansluiting, de routering en de toegangsregels beslissen dat nog steeds.

Kies bescherming op basis van de taak, niet uit gewoonte

Een terminalsessie of een ondersteunde bestandsbeheertaak past bij SSH, waarvan de architectuur serverauthenticatie, gebruikerauthenticatie en de kanalen in het beveiligde transport scheidt. Geen van die rollen vereist een commerciële VPN-aanbieder, en geen ervan houdt op te werken omdat er geen standaardroute naar het internet is.

Eén extra TCP-dienst kan door een geautoriseerde SSH-forward reizen als de server dat toestaat: houd de lokale listener nauw gebonden en de bestemming expliciet, en bedenk dat dit de ene dienst doorstuurt in plaats van een Ethernet-segment na te bootsen.

Gerouteerde toegang tot meerdere adressen of protocollen is een andere eis, en een lokaal beëindigde VPN kan die leveren. De peer is in dat geval een bereikbare lokale gateway, geen eindpunt ergens op het internet, en de gateway heeft nog steeds de bedoelde routes, doorstuurregels en dienstrechten nodig. Waar één toepassing al goed TLS spreekt, is het laten beschermen van zijn eigen verbinding vaak het kleinste antwoord dat werkt.

Inventariseer wat het LAN zou verlaten

Zorg dat de software, hostidentiteiten en inloggegevens aanwezig zijn voordat u op een geïsoleerde opstelling vertrouwt, of gebruik het offline-leveringsproces dat de organisatie ondersteunt. Een downloadcommando is geen installatieplan voor een machine die de bron niet kan bereiken, en dat tijdens een storing ontdekken is een slecht moment om het te leren.

Maak naamgeving bewust. Gebruik de bedoelde lokale DNS-dienst of een gedocumenteerde adressenregeling, want een geconfigureerde publieke resolver maakt geen pad naar zichzelf. Het wijzigen van een socketadres is ook geen rechtvaardiging om de identiteitscontroles van de toepassing over te slaan. Als het antwoord is dat de opstelling gewoon adressen gebruikt, schrijf dat dan ook op, zodat de volgende engineer niet een uur besteedt aan een zoekdomein dat nooit is geconfigureerd.

Lees daarna het authenticatie- en verificatiemodel voor externe afhankelijkheden: inschrijving, een identiteitsprovider, een multifactor-goedkeuring, het opvragen van certificaatstatus, een tijdbron. Elk daarvan is een potentiële blokkade op een geïsoleerd netwerk. Zet ze op een lijst vóór het onderhoudsvenster, niet er tijdens, want een afhankelijkheid die u op het verkeerde moment ontdekt, maakt van een taak van vijf minuten een middag. Zorg voor een goedgekeurde bereikbare regeling of kies een model dat offline werkt, en schakel nooit stilzwijgend een controle uit omdat de bijbehorende dienst ontbreekt.

Houd identiteitscontroles waar ze horen

Controleer de verwachte hostsleutel of het certificaat via het inrichtingsproces dat u vertrouwt, en houd de klok juist waar het protocol certificaattijden valideert. Een switch delen met een apparaat maakt dat apparaat niet het apparaat dat u wilde bereiken, en het tegendeel aannemen is precies de fout die een aanvaller op hetzelfde segment u graag ziet maken.

Tijd verdient een eigen regel in het plan. Veel protocollen weigeren anders geldige inloggegevens wanneer de klok ver genoeg is afgedreven, en een Pi zonder netwerktijdbron kan maandenlang stilletjes afdrijven voordat er iets klaagt.

Test met de uplink daadwerkelijk afwezig

Trek de uplink los en voer dan de exacte onderhoudsbewerking uit waarvoor u hebt ontworpen: de terminalsessie, het kopiëren van het bestand, de doorgestuurde dienst, de gerouteerde verbinding. Bevestig dat een geweigerde identiteit of een verboden bron nog steeds wordt geweigerd, want een ontwerp dat alleen het gelukkige pad bewijst, is helemaal niet getest. Lees de logboeken terwijl u het doet, want de interessante storingen zijn degene die een spoor achterlaten zonder de uitkomst te veranderen.

Leg het lokale eindpunt, het beschermingsmechanisme en elke afhankelijkheid vast die de bewerking gebruikte. Uitgang naar het internet en een veilig pad voor lokaal beheer zijn twee verschillende eisen, en ze gescheiden houden is wat de tweede laat overleven wanneer de eerste wegvalt.