☰

Ein lokales Subnetz vom StrongSwan VPN ausschließen

tag-icon • tag-icon vpn linux-networking strongswan
Ein lokales Subnetz vom StrongSwan VPN ausschließen

Ich habe einen Computer mit einer zusätzlichen, nur lokal verfügbaren Ethernet-Schnittstelle mit einem privaten Subnetz. Wenn ein StrongSwan-VPN eingerichtet ist, kann ich nicht auf dieses Subnetz zugreifen.

Dies ist die lokale „linke“ Konfiguration (festgelegt durchAlge):

conn ikev2-<rightip>
    fragmentation=yes
    rekey=no
    dpdaction=clear
    keyexchange=ikev2
    compress=no
    dpddelay=35s

    ike=aes128gcm16-prfsha512-ecp256!
    esp=aes128gcm16-ecp256!

    right=<rightip>
    rightid=<rightip>
    rightsubnet=0.0.0.0/0
    rightauth=pubkey

    leftsourceip=%config
    leftauth=pubkey
    leftcert=daves.crt
    leftfirewall=yes
    left=%defaultroute

    auto=add

Das betreffende Subnetz ist 10.0.0.0/24. %defaultroute wird in eine Adresse in 192.168.0.0/24 aufgelöst.

„left“ und „leftsubnet“ scheinen hierfür nicht die richtigen Optionen zu sein, aber ich sehe nichts Besseres. Ich habe versucht, leftsubnet auf 10.0.0.0/24 und auf !10.0.0.0/24 einzustellen.

Wie schließe ich ein lokales Subnetz von einer StronSwan-VPN-Verbindung aus?

Wie überprüfe ich die Routenkonfiguration einer Verbindung?

Antwort1

Sie können einePassthrough-Richtlinie.

UPDATE: wie von @ecdsa angemerkt, gibt es mit strongswan >= 5.5.2 eineeinfachere Methode, schauen Sie am Ende nach, ob Ihre Version es verwenden kann.

Beispiel mit ein paar zufälligen IPs. Vor jeder Änderung und jedem Tunnel:

# ip route get 10.0.0.55
10.0.0.55 dev lxcbr0 src 10.0.0.77 uid 0

Nach dem Einrichten des Tunnels besteht das Problem:

# ip route get 10.0.0.55
10.0.0.55 via 192.168.0.1 dev eth0 table 220 src 192.168.0.44 uid 0

Hinzufügen dieser Konfiguration zu /etc/ipsec.conf:

conn ignorelan
    left=127.0.0.1 #prevents usage in peers selection algorithm
    leftsubnet=10.0.0.0/24
    rightsubnet=10.0.0.0/24
    authby=never
    type=passthrough
    auto=route

und neu laden:

# ipsec reload

sollte es sofort aktivieren. Wenn dies (diesmal) nicht der Fall ist, können Sie Folgendes tun:

# ipsec route ignorelan
'ignorelan' shunt PASS policy installed

Es sollte auf jeden Fall bei jedem späteren Neustart verwendet werden. Sie haben jetzt (zusätzlich zu jedem Tunnel):

# ipsec status 
Shunted Connections:
     ignorelan:  10.0.0.0/24 === 10.0.0.0/24 PASS

[...]

Unabhängig davon, ob der Tunnel hergestellt wurde oder nicht, erhalten Sie die richtige Route zurück (die von Strongswan verwaltet wird, also in Tabelle 220 und nicht (nur) in der Haupttabelle):

# ip route get 10.0.0.55
10.0.0.55 dev lxcbr0 table 220 src 10.0.0.77 uid 0 
    cache

Bei einem Tunnel für 0.0.0.0/0 würde sich in Tabelle 220 ein Ergebnis ähnlich diesem ergeben:

# ip route show table 220
default via 192.168.0.1 dev eth0 proto static src 192.168.0.44 
10.0.0.0/24 dev lxcbr0 proto static src 10.0.0.77 
192.168.0.0/24 dev eth0 proto static src 192.168.0.44

Wenn Sie in den Passthrough-Einstellungen keine Routen eingeben, die der Realität entsprechen (z. B. falsche Netzmaske), müssen Sie mit falschen Ergebnissen für den „Shunt“ rechnen (wie die erwartete Quell-IP, aber über die falsche Netzwerkkarte). Seien Sie also vorsichtig.

AKTUALISIEREN: DieBypass-LAN-Pluginist einfacher zu verwenden, insbesondere in dynamischen Umgebungen.

Anstatt neue connEinträge hinzuzufügen, aktivieren Sie es (z. B. unter Debian Buster (nicht stabil), bearbeiten Sie /etc/strongswan.d/charon/bypass-lan.conf und setzen Sie load=yes (d. h.: charon.plugins.bypass-lan.load=yes) ). Standardmäßig wird jede Schnittstelle umgeleitet, d. h. ein Tunnel wird zwar aufgebaut, aber standardmäßig nicht verwendet. Setzen Sie also einfach entweder interfaces_ignoreoder interfaces_useentsprechend. Sie sollten interfaces_ignorefür die Schnittstelle(n), die Siewill nichtTunnel zu umgehen oder interfaces_usefür die Schnittstelle(n), die Siewollenum Tunnel zu umgehen. Beispiel:

interface_use = lxcbr0

Wird in diesem Beispiel nach erhalten ipsec start, wie bei der vorherigen Methode:

# ip route show table 220
10.0.0.0/24 dev lxcbr0 proto static src 10.0.0.77

(berücksichtigt jedoch auch IPv6-Routen, die sich auf diese Schnittstelle beziehen, wenn IPv6 verwendet wird).

Eine weitere (hackerartige) Methode wäre, die Tabelle 220 von Strongswan zu umgehen: Anstelle irgendwelcher Strongswan-Einstellungen würde dasselbe (für diese Frage und dieses Beispiel) mit Folgendem erreicht:

ip rule add priority 219 to 10.0.0.0/24 lookup main

Es wird die standardmäßige (Haupt-)Routingtabelle mit dem Zielnetzwerk verwendet, anstatt mit der Tabelle 220 von Strongswan zum nächsten Eintrag fortzufahren.

verwandte Informationen