Shorewall-Zonen für die zwei OpenVPN-Paketpfade
Trennen Sie den verschlüsselten OpenVPN-Transport vom entschlüsselten Client-Verkehr, geben Sie dem Tunnel eine eigene Zone und erlauben Sie nur den einen Dienst, den der Client braucht.
Zwei Paketflüsse überqueren ein Shorewall-Gateway, das OpenVPN terminiert, und nur einer davon ist verschlüsselt. Der erste ist der Transport des Clients zum VPN-Listener auf der internetzugewandten Schnittstelle. Der zweite ist die entschlüsselte Anfrage, die die Tunnelschnittstelle verlässt, zu einem Büroserver oder einem Dienst auf dem Gateway. Zeichnen Sie beide auf, bevor Sie die Richtlinie bearbeiten, denn eine Regel, die den ersten erfüllt, bewirkt für den zweiten nichts.
Zeichnen Sie die beiden Flüsse, bevor Sie die Richtlinie bearbeiten
Schreiben Sie die Flüsse als Zeilen mit Quelle, Ziel, Protokoll und Port. Auf dem äußeren Pfad ist die Quelle die öffentliche Adresse des Clients und das Ziel der Listener-Port des Gateways; Shorewall behandelt das als Verkehr vom Internet zur Firewall. Auf dem inneren Pfad ist die Quelle der Tunneladressbereich und das Ziel der freigegebene Dienst. Die beiden Zeilen haben unterschiedliche Eigentümer, auch wenn ein Administrator beide pflegt.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Fügen Sie eine Zeile nur hinzu, wenn die Anfrage am Gateway selbst endet, etwa Zugriff auf Resolver oder Verwaltung. Ein Dienst auf dem Host folgt der Host-Eingangsrichtlinie, nicht dem weitergeleiteten Pfad. Genau das Vermischen beider führt dazu, dass eine enge Tunnelregel eine Verwaltungsschnittstelle offenlegt.
Weisen Sie die Tunnelzone und den Schnittstellenumfang zu
Die Road-Warrior-Zone wird in /etc/shorewall/zones deklariert, die Tunnelschnittstelle wird in /etc/shorewall/interfaces eingebunden, und die äußere Verbindung wird in /etc/shorewall/tunnels beschrieben. Passen Sie sich der Syntax der installierten Version an, denn Spaltenreihenfolge und Optionsnamen haben sich zwischen Hauptversionen geändert. Der Beispielport des Leitfadens ist kein Grund, einen anderen Port zu erlauben als den, auf dem der Daemon tatsächlich lauscht. TCP und UDP sind nicht austauschbar, nur weil die Zahlen übereinstimmen.
Der Leitfaden gruppiert Schnittstellen mit tun+. Auf einem Host mit mehr als einem Tunnel kann dieser Platzhalter ein zweites VPN mit anderem Vertrauensniveau in dieselbe Zone legen. Prüfen Sie den Umfang gegen die tatsächlich vorhandenen Schnittstellen und halten Sie die Benennung im Lebenszyklus des Verbindungsmanagers, statt Schnittstellennamen von Hand zu bearbeiten.
Der historische Leitfaden enthält viel ältere OpenVPN-Konfigurationsbeispiele, und seine Krypto-Ratschläge sollten nicht in eine aktuelle Bereitstellung kopiert werden. Übernehmen Sie stattdessen das Zonen- und Flussmodell. Nehmen Sie die kryptografische Grundlage aus der gepflegten OpenVPN-Richtlinie des Gateways.
Erlauben Sie nur den Pfad, den Sie klassifiziert haben
Eine breite Freigabe von der VPN-Zone ins LAN ist ein Ausgangsdiagramm, keine fertige Richtlinie. Schreiben Sie die erlaubte Client-Quelle, die tatsächliche Dienstadresse, das Protokoll und den Port. Lesen Sie dann die Regeln darüber und die Zonenvorgabe, denn eine enge Ergänzung hebt eine breite Freigabe, die bereits passt, nicht auf. Verkehr zum Gateway-Host ist eine eigene Beziehung zum Verkehr, der durch ihn weitergeleitet wird.
Client-zu-Client-Verkehr braucht eine eigene Entscheidung. OpenVPNs client-to-client und Shorewalls routeback beeinflussen beide, ob Clients einander erreichen, und keines sollte aktiviert werden, nur damit eine LAN-Anwendung funktioniert. Entscheiden Sie, wo die Isolierung durchgesetzt wird, bevor Sie sie testen.
Halten Sie den Rückweg im selben Plan. Der Dienst oder sein Router muss wissen, wie Verkehr in den Tunnelbereich zurückkehrt, oder das Design muss die Quelle bewusst und im vorgesehenen Umfang übersetzen.
Validieren Sie und beweisen Sie dann beide Pfade
Validieren Sie die Konfiguration, bevor Sie irgendetwas neu starten, und halten Sie eine unabhängige Verwaltungssitzung offen, falls die neue Richtlinie falsch ist.
shorewall checkWenden Sie die Konfiguration nach einer sauberen Prüfung an und lesen Sie zurück, was Shorewall geladen hat. Diese Auslesen beschreiben die laufende Richtlinie und nicht das, was eine Datei zu sagen scheint.
shorewall show zones
ip route get 192.168.10.20Testen Sie eine frische erlaubte Anfrage und eine bewusst abgelehnte Anfrage vom selben Client. Ein erfolgreicher OpenVPN-Handshake beweist nur den äußeren Austausch; der erlaubte Dienst und die abgelehnte Ressource beweisen die innere Richtlinie, die Sie beabsichtigt haben. Verbinden Sie den Client dann neu und wiederholen Sie den Test, denn Name und Adresse der Tunnelschnittstelle können sich zwischen Sitzungen ändern. Weicht das Ergebnis ab, korrigieren Sie den Zonenumfang, statt die Regel zu erweitern.