strongSwan vips: IKEv2 nach einer virtuellen Adresse fragen

vips fordert eine innere IKEv2-Adresse an; das Gateway entscheidet, was es gewährt. Konfigurieren Sie die Anfrage, laden Sie sie, und prüfen Sie dann, was der Responder tatsächlich zugewiesen hat.

Ihr IKEv2-Client kann das Gateway um eine innere Adresse bitten, und das Gateway entscheidet, was es zurückgibt. In strongSwan ist diese Anfrage die Einstellung vips, und sie bleibt eine Anfrage, auch wenn Sie eine bestimmte Adresse hineinschreiben. Die folgende Anleitung konfiguriert die Anfrage, lädt sie und liest, was zurückkam, weil diese drei Schritte auf drei verschiedene Arten scheitern. Keiner von ihnen wird kürzer, indem man fester tippt.

Was vips anfragt und was es nicht versprechen kann

vips gehört in eine Verbindungsdefinition und bittet den Responder um eine virtuelle Adresse. Der strongSwan-Leitfaden zu virtuellen Adressen sagt ausdrücklich, dass die Antwort eine andere Adresse oder gar keine sein kann, und genau diesen Satz überspringen Leute, wenn sie einen Wert eintragen und erwarten, dass er erscheint. Die Anfrage lohnt sich trotzdem, denn geprüft wird die Antwort. Behandeln Sie die Einstellung als Anweisung zu fragen, nicht als Konfiguration des Ergebnisses.

0.0.0.0 anzufordern verlangt eine beliebige verfügbare virtuelle IPv4-Adresse, was meist richtig ist, wenn der genaue Wert keine Rolle spielt. Eine bestimmte Adresse anzufordern ist ein Hinweis an das Gateway, keine Forderung an dasselbe.

Das swanctl-Fragment und wo es hingehört

Die Einstellung sitzt im Verbindungsblock, nicht in einer eigenen Datei und nicht in einem Betriebssystemprofil. Dieses isolierte Fragment zeigt die Form:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

Laden Sie sie mit der Datei, der die Verbindung gehört, starten Sie dann die Verbindung und lesen Sie das Ergebnis. Ein in den falschen Abschnitt eingefügtes Fragment erzeugt einen Parsefehler oder, schlimmer, eine Verbindung, die ohne die Anfrage lädt, die Sie zu stellen glaubten. Führen Sie die drei Befehle der Reihe nach aus und behalten Sie die Ausgabe.

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts wählt Verkehr aus, es erzeugt keine Adresse

local_ts benennt die Menge des Verkehrs, den die Child-SA schützt; es legt keine Adresse auf eine Schnittstelle. Sobald eine virtuelle IP ausgehandelt ist, hört strongSwan auf, seinen standardmäßigen dynamischen Selektor zu verwenden, und nutzt stattdessen die gewährte Adresse. Nageln Sie den Selektor auf eine wörtliche Adresse fest, behaupten Sie etwas, das das Gateway möglicherweise nicht gewährt hat, und deshalb zeigt sich der Fehler als funktionierende SA mit Verkehr, der nirgendwohin geht. Der Selektor beschreibt Verkehr, während die Zuweisung aus dem anderen Austausch kommt.

Der andere Weg zu einer stabilen inneren Adresse ist, sie lokal zu besitzen. Setzen Sie die Adresse auf eine Schnittstelle, bevor der Tunnel hochkommt, richten Sie den Selektor auf das, was bereits existiert, und ordnen Sie Peer und Route darum herum.

In diesem Entwurf wird nichts ausgehandelt, also kann nichts neu zugewiesen werden, und das ist der Tausch: Determinismus dafür, die Adressierung selbst zu erledigen. Es ist ein anderer Mechanismus, keine Variante von vips, weshalb die beiden nicht in einer Verbindung gemischt werden sollten. Ein festgenagelter Selektor neben einer ausgehandelten Adresse ist eine Verbindung, die funktioniert, bis das Gateway etwas anderes ausgibt.

Prüfen Sie, was der Responder tatsächlich zugewiesen hat

Lesen Sie die SA-Liste nach der Adresse, die das Gateway gewährt hat, und bestätigen Sie dann, dass die Adresse auf der Schnittstelle existiert. Wenn die beiden nicht übereinstimmen, steht der Tunnel, und der Verkehr geht nicht dorthin, wo Sie denken. Eine gewährte Adresse, die nie die Schnittstelle erreicht, ist der verwirrendste Fehler in dieser Reihenfolge, weil jede Hälfte für sich korrekt aussieht.

Halten Sie vier Adressen in Ihren Notizen getrennt: die angeforderte innere Adresse, die gewährte, die LAN-Adresse der Maschine und den öffentlichen Ausgang, den eine Website meldet. Sie gehören zu verschiedenen Schichten und erscheinen an verschiedenen Stellen. Eine Anleitung, die alle vier festhält, ist eine, der jemand anderes folgen kann, ohne zu fragen, welche Adresse gemeint war. Lesen Sie sie nach jedem Neuladen erneut, denn der gewährte Wert ist der einzige, der den laufenden Tunnel beschreibt.

Halten Sie den statischen Entwurf getrennt

Wenn Sie eine feste innere Adresse brauchen, richten Sie die Reservierung am Gateway ein und lassen Sie die Client-Anfrage eine Anfrage bleiben. Ein festgenagelter Selektor zusammen mit einer ausgehandelten Adresse ergibt eine Verbindung, die funktioniert, bis das Gateway etwas anderes zuweist. Schreiben Sie die Reservierungsregel neben die Verbindung, denn sie ist der Teil, den ein Kollege nicht aus der Konfigurationsdatei ableiten kann. Dann erbt ein neuer Client die Regel, statt sie neu zu entdecken.

Beim eingebauten Mac-Client existiert keiner dieser Optionsnamen. Verwenden Sie die Zuweisung oder Reservierung, die das Gateway anbietet, und das Profil, das der Betreiber veröffentlicht, und behandeln Sie jeden clientseitigen Wert als Hinweis, bis Sie die Zuweisung zurückgelesen haben. Rollback heißt, die vips-Zeile zu entfernen und neu zu laden, was Sie zu dem zurückbringt, was das Gateway standardmäßig zuweist.

Ähnliche Artikel