IPsec-Tunnel mit dynamischen Endpunkten

Der Remote-Router (dynamischer Peer) leitet die Verhandlungen mit dem lokalen Router (Juniper Networks) ein. Der lokale Router verwendet die standardmäßigen IKE- und IPsec-Richtlinien, um die vom Remote-Peer gesendeten Vorschläge abzugleichen, um die Werte der Sicherheitszuordnung (SA) auszuhandeln. Implizite Vorschläge enthalten eine Liste aller unterstützten Transformationen, die der lokale Router von allen dynamischen Peers erwartet.

Wenn die Authentifizierung mit vorinstallierten Schlüsseln verwendet wird, ist der vorinstallierte Schlüssel für eine Dienstgruppe global. Bei der Suche nach dem vorinstallierten Schlüssel für den Peer gleicht der lokale Router die Quelladresse des Peers mit allen explizit konfigurierten vorinstallierten Schlüsseln in diesem Dienstsatz ab. Wenn keine Übereinstimmung gefunden wird, verwendet der lokale Router den globalen vorinstallierten Schlüssel für die Authentifizierung.

Phase 2 der Authentifizierung gleicht die Proxyidentitäten der geschützten Hosts und Netzwerke, die vom Peer gesendet werden, mit einer Liste konfigurierter Proxyidentitäten ab. Die akzeptierte Proxyidentität wird verwendet, um die dynamischen Regeln für die Verschlüsselung des Datenverkehrs zu erstellen. Sie können Proxyidentitäten konfigurieren, indem Sie die allowed-proxy-pair Anweisung in das IKE-Zugriffsprofil aufnehmen. Wenn kein Eintrag übereinstimmt, wird die Verhandlung abgelehnt.

Wenn Sie die allowed-proxy-pair Anweisung nicht konfigurieren, wird der Standardwert ANY(0.0.0.0/0)-ANY angewendet, und der lokale Router akzeptiert alle vom Peer gesendeten Proxyidentitäten. Es werden sowohl IPv4- als auch IPv6-Adressen akzeptiert, aber Sie müssen alle IPv6-Adressen manuell konfigurieren.

Sobald die Aushandlung in Phase 2 erfolgreich abgeschlossen wurde, erstellt der Router die dynamischen Regeln und fügt die umgekehrte Route mithilfe der akzeptierten Proxyidentität in die Routing-Tabelle ein.

Nach erfolgreicher Aushandlung mit dem dynamischen Peer erstellt der Schlüsselverwaltungsprozess (Key Management Process, KMD) eine dynamische Regel für den akzeptierten Phase-2-Proxy und wendet sie auf den lokalen AS- oder Multiservices-PIC an. Die Quell- und Zieladressen werden vom akzeptierten Proxy angegeben. Diese Regel wird verwendet, um Datenverkehr zu verschlüsseln, der an einen der Endhosts in der Proxyidentität der Phase 2 gerichtet ist.

Die dynamische Regel enthält einen ipsec-inside-interface Wert, bei dem es sich um den Schnittstellennamen handelt, der dem dynamischen Tunnel zugewiesen ist. Die source-address und-Werte destination-address werden von der Proxy-ID akzeptiert. Der match-direction Wert gilt input für Servicesets im Next-Hop-Stil.

Die Regelsuche für statische Tunnel wird durch das Vorhandensein einer dynamischen Regel nicht beeinflusst. Sie wird in der konfigurierten Reihenfolge ausgeführt. Wenn ein Paket für ein Service-Set empfangen wird, werden statische Regeln immer zuerst abgeglichen.

Dynamische Regeln werden abgeglichen, nachdem die Regelübereinstimmung für statische Regeln fehlgeschlagen ist.

Die Reaktion auf Dead Peer Detection (DPD)-Hallo-Nachrichten erfolgt bei dynamischen Peers auf die gleiche Weise wie bei statischen Peers. Das Initiieren von DPD-Hello-Nachrichten von dynamischen Peers wird nicht unterstützt.

Statische Routen werden automatisch in die Routing-Tabelle für die Netzwerke und Hosts eingefügt, die durch ein Remote-Tunnel-Endgerät geschützt sind. Diese geschützten Hosts und Netzwerke werden als Remote-Proxy-Identitäten bezeichnet.

Jede Route wird basierend auf dem Remote-Proxy-Netzwerk und der vom Peer gesendeten Maske erstellt und nach erfolgreichen Aushandlungen in Phase 1 und Phase 2 in die entsprechende Routing-Tabelle eingefügt.

Die Routenpräferenz für jede statische umgekehrte Route ist 1. Dieser Wert ist erforderlich, um Konflikte mit ähnlichen Routen zu vermeiden, die möglicherweise vom Routingprotokollprozess (RPD) hinzugefügt werden.

Es werden keine Routen hinzugefügt, wenn die akzeptierte Remote-Proxy-Adresse die Standardadresse ist (0.0.0.0/0). In diesem Fall können Sie Routing-Protokolle über den IPsec-Tunnel ausführen, um Routen zu lernen und statische Routen für den Datenverkehr hinzuzufügen, der über diesen Tunnel geschützt werden soll.

Bei Servicesätzen im Next-Hop-Stil enthalten die umgekehrten Routen Next-Hops, die auf die in der inside-service-interface Anweisung angegebenen Positionen verweisen.

Die Routingtabelle, in die diese Routen eingefügt werden sollen, hängt davon ab, wo der inside-service-interface Standort aufgeführt ist. Wenn diese Schnittstellen in einer VPN-Routing- und Weiterleitungsinstanz (VRF) vorhanden sind, werden Routen zur entsprechenden VRF-Tabelle hinzugefügt. Andernfalls werden die Routen zu inet.0hinzugefügt.

Sie können nur ein Tunnel-Profil pro Service-Set für alle dynamischen Peers konfigurieren. Der konfigurierte vorab freigegebene Schlüssel im Profil wird für die IKE-Authentifizierung aller dynamischen Peers verwendet, die in diesem Dienstsatz enden. Alternativ können Sie die ike-policy Anweisung einschließen, um auf eine von Ihnen definierte IKE-Richtlinie mit bestimmten Identifikationswerten oder einem Platzhalter (die any-remote-id Option) zu verweisen. Sie konfigurieren die IKE-Richtlinie auf Hierarchieebene [edit services ipsec-vpn ike] .

Das IKE-Tunnel-Profil gibt alle Informationen an, die zum Abschließen der IKE-Aushandlung erforderlich sind. Jedes Protokoll verfügt über eine eigene Anweisungshierarchie innerhalb der Clientanweisung, um protokollspezifische Attribut-Wert-Paare zu konfigurieren, aber für jedes Profil ist nur eine Clientkonfiguration zulässig. Im Folgenden finden Sie die Konfiguration auf Hierarchieebene [edit access] . Weitere Informationen zu Zugriffsprofilen finden Sie in der Junos OS-Verwaltungsbibliothek für Routing-Geräte.

Das IKE-Profil besteht aus folgenden Aussagen:

• allowed-proxy-pair– Während der IKE-Aushandlung in Phase 2 gibt der entfernte Peer seine Netzwerkadresse (remote) und die Netzwerkadresse seines Peers (local) an. Da mehrere dynamische Tunnel über denselben Mechanismus authentifiziert werden, muss diese Anweisung die Liste der möglichen Kombinationen enthalten. Wenn der dynamische Peer keine gültige Kombination darstellt, schlägt die Phase 2 der IKE-Aushandlung fehl.

  Wird standardmäßig verwendet, remote 0.0.0.0/0 local 0.0.0.0/0 wenn keine Werte konfiguriert sind. In dieser Konfiguration werden sowohl IPv4- als auch IPv6-Adressformate unterstützt, es gibt jedoch keine standardmäßigen IPv6-Adressen. Sie müssen even 0::0/0angeben.

• pre-shared-key—Schlüssel, der zur Authentifizierung des dynamischen Peers während der IKE-Phase-1-Aushandlung verwendet wird. Dieser Schlüssel ist beiden Enden durch einen Out-of-Band-Sicherheitsmechanismus bekannt. Sie können den Wert entweder in hexadecimal oder ascii-text im Format konfigurieren. Es ist ein obligatorischer Wert.

• ike-policy—Richtlinie, die die Remote-Identifikationswerte definiert, die den zulässigen dynamischen Peers entsprechen; Kann einen Platzhalterwert any-remote-id enthalten, der nur in dynamischen Endgerät-Konfigurationen verwendet werden kann.

• interface-id– Schnittstellenbezeichner, ein obligatorisches Attribut, das zum Ableiten der Schnittstelleninformationen für logische Services für die Sitzung verwendet wird.

• ipsec-policy– Name der IPsec-Richtlinie, die die IPsec-Richtlinieninformationen für die Sitzung definiert. Sie definieren die IPsec-Richtlinie auf Hierarchieebene [edit services ipsec-vpn ipsec policy policy-name] . Wenn keine Richtlinie festgelegt ist, wird jede vom dynamischen Peer vorgeschlagene Richtlinie akzeptiert.

Um die Konfiguration abzuschließen, müssen Sie auf das auf Hierarchieebene [edit access] konfigurierte IKE-Zugriffsprofil verweisen. Fügen Sie dazu die ike-access-profile Anweisung auf Hierarchieebene [edit services service-set name ipsec-vpn-options] ein:

Die ike-access-profile Anweisung muss auf denselben Namen verweisen wie die Anweisung, die Sie für den profile IKE-Zugriff auf Hierarchieebene [edit access] konfiguriert haben. Sie können in jedem Servicesatz nur auf ein Zugriffsprofil verweisen. Dieses Profil wird verwendet, um IKE- und IPsec-Sicherheitszuordnungen nur mit dynamischen Peers auszuhandeln.

Alle Schnittstellen, auf die die inside-service-interface Anweisung in einem Service-Set verweist, müssen derselben VRF-Instanz angehören.

Sie können eine Schnittstellenkennung für eine Gruppe dynamischer Peers konfigurieren, die angibt, welche logischen Schnittstellen für adaptive Services an der dynamischen IPsec-Aushandlung teilnehmen. Durch die Zuordnung desselben Interface-Identifikators zu mehreren logischen Schnittstellen können Sie zu diesem Zweck einen Pool von Schnittstellen erstellen. Um einen Schnittstellenbezeichner zu konfigurieren, schließen Sie die ipsec-interface-id Anweisung und die dedicated oder-Anweisung shared auf der [edit interfaces interface-name unit logical-unit-number dial-options] Hierarchieebene ein:

Durch Angabe des Schnittstellenbezeichners in der dial-options Anweisung wird diese logische Schnittstelle zu einem Teil des durch die ipsec-interface-id Anweisung identifizierten Pools.

Wenn Sie den Modus konfigurieren shared , kann eine logische Schnittstelle über mehrere Tunnel gemeinsam genutzt werden. Die dedicated Anweisung gibt an, dass die logische Schnittstelle in einem dedizierten Modus verwendet wird, was erforderlich ist, wenn Sie einen IPsec-Link-Type-Tunnel konfigurieren. Sie müssen die dedicated Anweisung einschließen, wenn Sie einen ipsec-interface-id Wert angeben.

Die Software enthält implizite Standard-IKE- und IPsec-Vorschläge, die den von den dynamischen Peers gesendeten Vorschlägen entsprechen. Die Werte sind in Tabelle 1 dargestellt; Wenn mehr als ein Wert angezeigt wird, ist der erste Wert der Standardwert.

Ab Junos OS Version 16.2R1 können Sie IPsec-Tunnel mit dynamischen Endpunkten auf mehrere MS-MICs oder auf mehrere Service-PICs eines MS-MPC verteilen. Sie konfigurieren die Tunnel-Verteilung, indem Sie einen Next-Hop-IPsec-Servicesatz für die Multiservices-Schnittstelle (ms-) jedes Service PIC konfigurieren. Ab Junos OS Version 17.1R1 können Sie IPsec-Tunnel mit dynamischen Endpunkten auch auf AMS-aggregierte (Multiservices)-Schnittstellen von MS-MICs oder MS-MPCs verteilen, indem Sie für jede AMS-Schnittstelle einen Next-Hop-IPsec-Servicesatz konfigurieren.

Sie können dem Router der MX-Serie später Service-PIC-Hardware hinzufügen und die Service-PIC in die Tunnel-Verteilung einbeziehen, indem Sie einfach einen weiteren Servicesatz hinzufügen, ohne die Konfiguration der IPsec-Peers ändern zu müssen.

Führen Sie zum Konfigurieren der Tunnel-Verteilung die folgenden Schritte aus, wenn Sie dynamische IPsec-Tunnel für Endgeräte konfigurieren:

• Konfigurieren Sie einen Next-Hop-IPsec-Service-Satz für jede Dienstschnittstelle oder AMS-Schnittstelle, die vom dynamischen Endgerät-IPsec-Tunnel verwendet wird (siehe Verweisen auf das IKE-Zugriffsprofil in einem Service-Set). Alle Service-Sets müssen:

  • Verwenden Sie dieselbe Art von Serviceschnittstelle – entweder Multiservices-Schnittstellen (ms-) oder AMS-Schnittstellen (ams-).

  • Die Anweisung muss eine Schnittstelle haben outside-service , die sich in derselben VPN-Routing- und Weiterleitungsinstanz (VRF) befindet wie die Schnittstellen in den anderen Servicesätzen.

  • Sie müssen dieselbe local-gateway IP-Adresse haben.

  • Haben den gleichen ike-access-profile Namen.

• Bei der Konfiguration der Schnittstellenkennung (siehe Schnittstellenkennung konfigurieren) muss die ipsec-interface-id identifier konfiguriert werden:

  • Nur unter Schnittstellen, die in den inside-service-set Anweisungen der Service Sets erscheinen.

  • Mit dedicated für alle Schnittstellen oder mit shared für alle Schnittstellen.

  • Unter nicht mehr als einer gemeinsam genutzten Einheit einer Schnittstelle.

  • Nur unter Schnittstellen, die mit konfiguriert sind service-domain inside.

  • Nur unter Schnittstellen, die sich im selben VRF befinden.