VPN-Clients und das LAN: wann eine eigene Zone sinnvoll ist

Die Tunnelschnittstelle in die LAN-Zone zu legen ist der kürzeste Weg zu einem funktionierenden VPN, und meist ist es die falsche Voreinstellung. Sie gewährt dem entfernten Client dasselbe Vertrauen wie dem verkabelten LAN, was die Aufgabe selten verlangt. Eine eigene Zone kostet ein paar Regeln und macht die Grenze sichtbar. Die Entscheidung ist nicht, ob Zonen besser sind; sie lautet, welche drei Bedingungen auf Ihr Netz zutreffen.

Der Zonenname verschlüsselt nichts und authentifiziert keinen Benutzer. Er gruppiert nur Schnittstellen für das Regelmodell der Firewall.

Was die Zonenzugehörigkeit tatsächlich steuert

Eine Zone gruppiert Schnittstellen oder Verkehr im Modell der Firewall. Ihre Einstellungen für Input, Output und Forwarding regeln dann unterschiedliche Rollen. Input ist Verkehr zum Router selbst; Forwarding ist Verkehr durch ihn zu einem anderen Host. Die Zonendokumentation von OpenWrt behandelt Input, Output und Forwarding genau deshalb als getrennte Einstellungen.

Eine Erlaubnis von der VPN-Zone in die LAN-Zone ist nicht automatisch eine umgekehrte Erlaubnis. Forwarding-Regeln sind gerichtet, und eine Regel, die Verkehr vom Client zum Server erlaubt, erlaubt keine Sitzungen vom Server zum Client. Ein Client, der eine Verbindung zu einem Server öffnen kann, ist kein Client, zu dem der Server eine Verbindung zurück öffnen kann.

Dieser Unterschied ist der Grund, warum eine eigene Zone nützlich ist: Sie können jede Richtung und jede Rolle ausdrücklich benennen. Schreiben Sie die Richtung neben jede Regel.

Entscheidung eins: Input, Forward oder beides

Brauchen entfernte Clients DNS vom Router, erlauben Sie Input nur für diesen Dienst. Müssen sie einen Dateiserver erreichen, erlauben Sie Forwarding zu diesem Ziel. Die meisten VPN-Entwürfe brauchen beides, aber für unterschiedliche Dienste.

Breiter Input-Zugriff auf jeden lokalen Dienst ist fast nie erforderlich. Behandeln Sie die Routerverwaltung als eigene Entscheidung getrennt vom Anwendungszugriff. Braucht der Router nur DNS zu beantworten, schreiben Sie diese einzige Erlaubnis und lassen Sie den Rest geschlossen.

Entscheidung zwei: welche Ressourcen entfernte Clients brauchen

Listen Sie die Client-Bereiche, die Ziele und die Dienste auf, die das VPN bereitstellen soll, bevor Sie Regeln schreiben. Eine Zielliste ist nützlicher als ein Vertrauenslabel, weil sie eine Firewall-Migration übersteht.

Halten Sie Verwaltungsschnittstellen vom gewöhnlichen Anwendungszugriff getrennt. Ein entfernter Client, der ein Wiki erreicht, braucht dadurch nicht die Admin-Seite des Routers oder die Hypervisor-Konsole.

Kann ein erlaubtes Ziel weiterleiten, endet die Zonengrenze an der Firewall, nicht bei dem, was das Ziel als Nächstes tut.

Entscheidung drei: wie Sie die Grenze beweisen

Testen Sie nach jeder Änderung einen erlaubten Fluss und einen absichtlich verweigerten. Der Nachweis, dass eine Website lädt, zeigt keine unbeabsichtigte breite Erlaubnis. Testen Sie aus dem Adressbereich des VPN-Clients, nicht aus dem LAN, und schließen Sie die Richtung ein, die scheitern soll. Notieren Sie beide Ergebnisse neben der Regel.

Bewahren Sie den Wiederherstellungszugang des Gateways, bevor Sie die Richtlinie der entfernten Zone ändern. Nutzen Sie die dauerhafte verwaltete Konfiguration statt Änderungen zur Laufzeit, sonst stellt der nächste Neustart das alte Vertrauen wieder her. Eine Kopie der vorherigen Konfiguration, außerhalb des Geräts aufbewahrt, ist der billigste Rückweg, den Sie je haben werden.

Wenn das Netz wächst, dokumentieren Sie Zugehörigkeit und Zweck der Regeln. Eine neu angeschlossene Schnittstelle sollte keine Privilegien erben, nur weil jemand ihr einen bequemen Zonennamen gegeben hat.