IPsec-Tunnel mit dynamischen Endpunkten

Der Remote-Router (dynamischer Peer) initiiert die Verhandlungen mit dem lokalen Router (Juniper Networks). Der lokale Router verwendet die standardmäßigen IKE- und IPsec-Richtlinien, um die vom Remote-Peer gesendeten Vorschläge zum Aushandeln der Sicherheitszuordnungswerte (SA) abzugleichen. 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 einen Dienstsatz 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 wurden, 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 Aushandlung 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. Sowohl IPv4- als auch IPv6-Adressen werden akzeptiert, aber Sie müssen alle IPv6-Adressen manuell konfigurieren.

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

Nach erfolgreicher Aushandlung mit dem dynamischen Peer erstellt der Schlüsselverwaltungsprozess (kmd) eine dynamische Regel für den akzeptierten Phase-2-Proxy und wendet sie auf den lokalen AS oder den 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 Phase 2-Proxyidentität gerichtet ist.

Die dynamische Regel enthält einen ipsec-inside-interface Wert, nämlich den Schnittstellennamen, der dem dynamischen Tunnel zugewiesen ist. destination-address Die source-address und-Werte werden von der Proxy-ID übernommen. Der match-direction Wert gilt input für Servicesätze im Stil des nächsten Hops.

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 einen Servicesatz 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 Hello-Nachrichten mit Dead Peer Detection (DPD) erfolgt bei dynamischen Peers genauso 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 einen Remote-Tunnelendpunkt geschützt sind. Diese geschützten Hosts und Netzwerke werden als Remote-Proxyidentitä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 durch den Routing-Protokollprozess (rpd) hinzugefügt werden können.

Es werden keine Routen hinzugefügt, wenn die akzeptierte Remote-Proxy-Adresse die Standardadresse (0.0.0.0/0) ist. 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 Stil des nächsten Hops enthalten die umgekehrten Routen Next Hops, die auf die in der inside-service-interface Anweisung angegebenen Speicherorte verweisen.

Die Routing-Tabelle, in die diese Routen eingefügt werden, 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.0.

Sie können nur ein Tunnelprofil pro Servicesatz für alle dynamischen Peers konfigurieren. Der konfigurierte vorinstallierte 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 zum Verweisen auf eine von Ihnen definierte IKE-Richtlinie entweder mit bestimmten Identifikationswerten oder mit einem Platzhalter (die any-remote-id Option) einschließen. Sie konfigurieren die IKE-Richtlinie auf Hierarchieebene [edit services ipsec-vpn ike] .

Das IKE-Tunnelprofil 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, für jedes Profil ist jedoch 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 Administration Library for Routing Devices.

Das IKE-Profil besteht aus den folgenden Anweisungen:

• allowed-proxy-pairWährend Phase 2 der IKE-Aushandlung stellt der Remote-Peer seine Netzwerkadresse (remote) und die Netzwerkadresse () seines Peers bereitlocal. 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 aufweist, schlägt die IKE-Aushandlung der Phase 2 fehl.

  Wird standardmäßig verwendet, remote 0.0.0.0/0 local 0.0.0.0/0 wenn keine Werte konfiguriert sind. Sowohl IPv4- als auch IPv6-Adressformate werden in dieser Konfiguration unterstützt, es gibt jedoch keine Standard-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 sicheren Out-of-Band-Mechanismus bekannt. Sie können den Wert entweder in oder ascii-text im hexadecimal Format konfigurieren. Es handelt sich um einen obligatorischen 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 Endpunktkonfigurationen verwendet werden kann.

• interface-id– Schnittstellen-ID, ein obligatorisches Attribut, das zum Ableiten der logischen Service-Schnittstelleninformationen 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 der [edit services ipsec-vpn ipsec policy policy-name] Hierarchieebene. Wenn keine Richtlinie festgelegt ist, wird jede vom dynamischen Peer vorgeschlagene Richtlinie akzeptiert.

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

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

Alle Schnittstellen, auf die von der inside-service-interface Anweisung innerhalb eines Servicesatzes verwiesen wird, müssen derselben VRF-Instanz angehören.

Sie können eine Schnittstellen-ID für eine Gruppe dynamischer Peers konfigurieren, die angibt, welche logische(n) Schnittstelle(n) adaptiver Services an der dynamischen IPsec-Aushandlung teilnehmen. Durch die Zuordnung derselben Schnittstellenkennung zu mehreren logischen Schnittstellen können Sie zu diesem Zweck einen Pool von Schnittstellen anlegen. 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 Pools, der durch die Anweisung ipsec-interface-id identifiziert wird.

Wenn Sie den Modus konfigurieren shared , kann eine logische Schnittstelle für 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-Typ-Tunnel konfigurieren. Sie müssen die Anweisung dedicated einschließen, wenn Sie einen ipsec-interface-id Wert angeben.

Die Software enthält implizite standardmäßige IKE- und IPsec-Vorschläge, die mit den von den dynamischen Peers gesendeten Vorschlägen übereinstimmen. Die Werte sind in Tabelle 1 aufgeführt. 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 einer MS-MPC verteilen. Sie konfigurieren die Tunnelverteilung, 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 Endgeräten auch auf AMS-Schnittstellen (Aggregated Multiservices) 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 das Service-PIC in die Tunnelverteilung einbeziehen, indem Sie einfach einen weiteren Servicesatz hinzufügen, ohne die Konfiguration der IPsec-Peers ändern zu müssen.

Führen Sie die folgenden Schritte aus, um die Tunnelverteilung zu konfigurieren, wenn Sie IPsec-Tunnel für dynamische Endgeräte konfigurieren:

• Konfigurieren Sie einen Next-Hop-IPsec-Servicesatz für jede Services- oder AMS-Schnittstelle, die vom IPsec-Tunnel des dynamischen Endpunkts verwendet wird (siehe Verweisen auf das IKE-Zugriffsprofil in einem Serviceset). Alle Service-Sets müssen:

  • Verwenden Sie die gleiche Art von Dienstschnittstelle – entweder Multiservices-Schnittstellen (ms-) oder AMS-Schnittstellen (ams-).

  • Die Anweisung muss eine Schnittstelle enthalten, die outside-service sich in derselben VRF-Instanz (VPN Routing and Forwarding) befindet wie die Schnittstellen in den anderen Dienstsätzen.

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

  • Haben den gleichen ike-access-profile Namen.

• Bei der Konfiguration des Interface-Identifiers (siehe Konfigurieren des Interface-Identifiers) muss Folgendes ipsec-interface-id identifier konfiguriert werden:

  • Nur unter Schnittstellen, die in den inside-service-set Anweisungen der Servicemengen vorkommen.

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

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

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

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