Network Address Translation – Überblick
Junos Address Aware Übersicht über die Netzwerkadressierung
Junos Address Aware Netzwerkadressierung bietet Network Address Translation (NAT) Funktionen für die Übersetzung von IP-Adressen. Dies ist besonders wichtig, da die Internet Assigned Numbers Authority (IANA) Anfang 2011 den letzten großen Block von IPv4-Adressen zugewiesen hat.
Dieses Thema enthält die folgenden Abschnitte:
- Vorteile von NAT
- NAT-Konzept und -Einrichtungen im Überblick
- IPv4-zu-IPv4 Basic NAT
- Deterministisches NAPT
- Statische Ziel-NAT
- Zweimal NAT
- IPv6 NAT
- Unterstützung für Gateways auf Anwendungsebene (ALG)
- NAT-PT mit DNS ALG
- Dynamisches NAT
- Zustandsbehaftetes NAT64
- 464XLAT
- Dual-Stack Lite
- Junos Address Aware Linecard-Support für Netzwerkadressierung
Vorteile von NAT
NAT unterstützt eine Vielzahl von Netzwerkzielen, darunter:
-
Ausblenden einer Reihe von Hostadressen in einem privaten Netzwerk hinter einem Pool öffentlicher Adressen, um die Hostadressen vor direkten Angriffen auf das Netzwerk zu schützen und eine Erschöpfung der IPv4-Adressen zu vermeiden
-
Bereitstellung der Tools für den Übergang auf IPv6 auf der Grundlage geschäftlicher Anforderungen und zur Gewährleistung eines unterbrechungsfreien Wachstums von Anwendern und Services
-
Bereitstellung von IPv4–IPv6-Koexistenz
NAT-Konzept und -Einrichtungen im Überblick
Junos Address Aware Netzwerkadressierung bietet Carrier-Grade NAT (CGN) für IPv4- und IPv6-Netzwerke und erleichtert den Transit des Datenverkehrs zwischen verschiedenen Netzwerktypen.
Junos Address Aware Netzwerkadressierung unterstützt eine Vielzahl von NAT-Übersetzungsoptionen:
-
Übersetzung statischer Quellen: Ermöglicht das Ausblenden eines privaten Netzwerks. Es bietet eine Eins-zu-Eins-Zuordnung zwischen der ursprünglichen Adresse und der übersetzten Adresse; Das Mapping wird statisch konfiguriert. Weitere Informationen finden Sie unter Basic NAT .
-
Deterministisches NAPT: Macht die Protokollierung der Adressübersetzung überflüssig, indem sichergestellt wird, dass die ursprüngliche IPv4- oder IPv6-Quelladresse und der ursprüngliche Port immer derselben Post-NAT-IPv4-Adresse und demselben Portbereich zugeordnet sind.
-
Dynamische Quellübersetzung— Umfasst zwei Optionen: dynamische Adressquellübersetzung und Network Address Port Translation (NAPT):
-
Dynamische reine Adressquellübersetzung— mdash; Eine NAT-Adresse wird dynamisch aus einem Quell-NAT-Pool übernommen, und die Zuordnung von der ursprünglichen Quelladresse zur übersetzten Adresse wird beibehalten, solange mindestens ein aktiver Fluss vorhanden ist, der diese Zuordnung verwendet. Weitere Informationen finden Sie unter Dynamisches NAT.
-
NAPT: Sowohl die ursprüngliche Quelladresse als auch der Quellport werden übersetzt. Die übersetzte Adresse und der Port werden aus dem entsprechenden NAT-Pool übernommen. Weitere Informationen finden Sie unter NAPT .
-
-
Statische Zielübersetzung: Ermöglicht es Ihnen, ausgewählte private Server zugänglich zu machen. Es bietet eine Eins-zu-Eins-Zuordnung zwischen der übersetzten Adresse und der Zieladresse; Das Mapping wird statisch konfiguriert. Weitere Informationen finden Sie unter Statische Ziel-NAT.
-
Protokollübersetzung: Ermöglicht die Zuweisung von Adressen aus einem Pool auf statischer oder dynamischer Basis, wenn Sitzungen über IPv4- oder IPv6-Grenzen hinweg initiiert werden. Weitere Informationen finden Sie unter Konfigurieren von NAT-PT, NAT-PT mit DNS ALG, und Stateful NAT64.
-
Kapselung von IPv4-Paketen in IPv6-Pakete mithilfe von Softwires: Ermöglicht die Übertragung von Paketen über Softwires zu einem NAT-Endgerät der Carrier-Klasse, wo sie einer Source-NAT-Verarbeitung unterzogen werden, um die ursprüngliche Quelladresse zu verbergen. Weitere Informationen finden Sie unter Übersicht über Tunnelingdienste für den Übergang von IPv4 zu IPv6.
Die Netzwerkadressierung von Junos Address Aware unterstützt die in IETF RFCs und Internet-Entwürfen beschriebenen NAT-Funktionen, wie unter " Unterstützte NAT- und SIP-Standards" in der Standardreferenz beschrieben.
Nicht alle Arten von NAT werden auf allen Schnittstellentypen unterstützt. Siehe Vergleich der NAT-Funktionen auf Betreiberniveau für Junos Address Aware nach Typ der Schnittstellenkarte, der die auf den unterstützten Schnittstellen verfügbaren Funktionen auflistet.
IPv4-zu-IPv4 Basic NAT
Basic Network Address Translation oder Basic NAT ist eine Methode, bei der IP-Adressen transparent für Endbenutzer von einer Gruppe auf eine andere abgebildet werden. Network Address Port Translation oder NAPT ist eine Methode, bei der viele Netzwerkadressen und ihre TCP/UDP-Ports in eine einzige Netzwerkadresse und ihre TCP/UDP-Ports übersetzt werden. Zusammen stellen diese beiden Vorgänge, die als traditionelles NAT bezeichnet werden, einen Mechanismus zum Verbinden eines Bereichs mit privaten Adressen mit einem externen Bereich mit global eindeutigen registrierten Adressen bereit.
Die traditionelle NAT, spezifiziert in RFC 3022, Traditional IP Network Address Translator, wird vollständig von der Junos Address Aware Netzwerkadressierung unterstützt. Darüber hinaus wird NAPT für Quelladressen unterstützt.
Grundlegende NAT
Bei Basic NAT wird ein Block externer Adressen für die Übersetzung von Adressen von Hosts in einer privaten Domäne reserviert, wenn diese Sitzungen in die externe Domäne initiieren. Für Pakete, die aus dem privaten Netzwerk ausgehen, übersetzt Basic NAT Quell-IP-Adressen und zugehörige Felder wie IP-, TCP-, UDP- und ICMP-Header-Prüfsummen. Bei eingehenden Paketen übersetzt Basic NAT die Ziel-IP-Adresse und die oben aufgeführten Prüfsummen.
Hairpinning wird für grundlegende NAT unterstützt.
NAPT
Verwenden Sie NAPT, damit die Komponenten des privaten Netzwerks eine einzige externe Adresse gemeinsam nutzen können. NAPT übersetzt die Transportkennung (z. B. TCP-Portnummer, UDP-Portnummer oder ICMP-Abfrage-ID) des privaten Netzwerks in eine einzige externe Adresse. NAPT kann mit Basic NAT kombiniert werden, um einen Pool externer Adressen in Verbindung mit der Portübersetzung zu verwenden.
Für Pakete, die aus dem privaten Netzwerk ausgehen, übersetzt NAPT die Quell-IP-Adresse, die Quelltransport-ID (TCP/UDP-Port oder ICMP-Abfrage-ID) und zugehörige Felder wie IP-, TCP-, UDP- und ICMP-Header-Prüfsummen. Bei eingehenden Paketen übersetzt NAPT die Ziel-IP-Adresse, die Zieltransport-ID sowie die IP- und Transport-Header-Prüfsummen.
Wenn Sie auf Routern der MX-Serie mit MS-MICs und MS-MPCs eine NAPT44-NAT-Regel konfigurieren und die Quell-IP-Adresse eines gefälschten Pakets gleich dem NAT-Pool ist und die Übereinstimmungsbedingung der NAT-Regel fehlschlägt, wird das Paket kontinuierlich zwischen der Service-PIC und der Packet Forwarding Engine durchgeschaltet. Es wird empfohlen, die Sitzung manuell zu löschen und einen Filter zu erstellen, um NAT Pool-IP-Spoofing unter solchen Bedingungen zu blockieren.
Hairpinning wird für NAPT unterstützt.
Deterministisches NAPT
Verwenden Sie deterministisches NAPT44, um sicherzustellen, dass die ursprüngliche IPv4-Quelladresse und der ursprüngliche Port immer derselben Post-NAT-IPv4-Adresse und demselben Portbereich zugeordnet sind und dass die umgekehrte Zuordnung einer bestimmten übersetzten externen IPv4-Adresse und eines bestimmten Ports immer derselben internen IP-Adresse zugeordnet wird. Dadurch entfällt die Notwendigkeit der Protokollierung der Adressübersetzung. Ab Junos OS Version 17.4R1 wird deterministisches NAPT64 auf MS-MPC und MS-MIC unterstützt. Deterministisches NAPT64 stellt sicher, dass die ursprüngliche IPv6-Quelladresse und der ursprüngliche Port immer derselben Post-NAT-IPv4-Adresse und demselben Portbereich zugeordnet sind und dass die umgekehrte Zuordnung einer bestimmten übersetzten externen IPv4-Adresse und eines bestimmten Ports immer derselben internen IPv6-Adresse zugeordnet wird.
Statische Ziel-NAT
Verwenden Sie statische Ziel-NAT, um die Zieladresse für externen Datenverkehr in eine in einem Zielpool angegebene Adresse zu übersetzen. Der Zielpool enthält eine Adresse und keine Portkonfiguration.
Weitere Informationen zur statischen Ziel-NAT finden Sie unter RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations.
Zweimal NAT
In Twice NAT werden sowohl die Quell- als auch die Zieladresse übersetzt, wenn Pakete den NAT-Router durchlaufen. Die zu übersetzenden Quellinformationen können entweder nur Adresse oder Adresse und Port sein. Sie würden z. B. Twice NAT verwenden, wenn Sie zwei Netzwerke verbinden, in denen sich alle oder einige Adressen in einem Netzwerk mit Adressen in einem anderen Netzwerk überschneiden (unabhängig davon, ob es sich um ein privates oder öffentliches Netzwerk handelt). Im traditionellen NAT wird nur eine der Adressen übersetzt.
Um Twice NAT zu konfigurieren, müssen Sie sowohl eine Zieladresse als auch eine Quelladresse für die Übereinstimmungsrichtung, den Pool oder das Präfix und den Übersetzungstyp angeben.
Sie können Gateways auf Anwendungsebene (ALGs) für ICMP und Traceroute unter Stateful Firewall-, NAT- oder Class-of-Service (CoS)-Regeln konfigurieren, wenn Twice NAT im selben Servicesatz konfiguriert ist. Diese ALGs können nicht auf Datenströme angewendet werden, die vom Packet Gateway Control Protocol (PGCP) erstellt wurden. Twice NAT unterstützt keine anderen ALGs. Standardmäßig kann sich die Funktion "Twice NAT" auf IP-, TCP- und UDP-Header auswirken, die in die Nutzlast von ICMP-Fehlermeldungen eingebettet sind.
Zweimal NAT, spezifiziert in RFC 2663, IP Network Address Translator (NAT) Terminologie und Überlegungen, wird vollständig von Junos Address Aware Netzwerkadressierung unterstützt.
IPv6 NAT
IPv6-to-IPv6 NAT (NAT66), definiert in Internet draft draft-mrw-behave-nat66-01, IPv6-to-IPv6 Network Address Translation (NAT66), wird vollständig von Junos Address Aware Netzwerkadressierung unterstützt.
Unterstützung für Gateways auf Anwendungsebene (ALG)
Junos Address Aware Netzwerkadressierung unterstützt eine Reihe von ALGs. Sie können NAT-Regeln verwenden, um eingehenden Datenverkehr basierend auf ALGS zu filtern. Weitere Informationen finden Sie unter Übersicht über Network Address Translation-Regeln.
NAT-PT mit DNS ALG
NAT-PT und Domain Name System (DNS) ALG werden verwendet, um die Kommunikation zwischen IPv6-Hosts und IPv4-Hosts zu erleichtern. Mithilfe eines Pools von IPv4-Adressen weist NAT-PT IPv6-Knoten dynamisch Adressen aus diesem Pool zu, wenn Sitzungen über IPv4- oder IPv6-Grenzen hinweg initiiert werden. Eingehende und ausgehende Sitzungen müssen denselben NAT-PT-Router durchlaufen, damit diese Sitzungen verfolgt werden können. RFC 2766, Network Address Translation - Protocol Translation (NAT-PT), empfiehlt die Verwendung von NAT-PT für die Übersetzung zwischen reinen IPv6-Knoten und reinen IPv4-Knoten und nicht für die IPv6-zu-IPv6-Übersetzung zwischen IPv6-Knoten oder die IPv4-zu-IPv4-Übersetzung zwischen IPv4-Knoten.
DNS ist ein verteiltes hierarchisches Benennungssystem für Computer, Dienste oder andere Ressourcen, die mit dem Internet oder einem privaten Netzwerk verbunden sind. Der DNS ALG ist ein anwendungsspezifischer Agent, der es einem IPv6-Knoten ermöglicht, mit einem IPv4-Knoten zu kommunizieren und umgekehrt.
Wenn DNS ALG mit NAT-PT verwendet wird, übersetzt das DNS ALG IPv6-Adressen in DNS-Abfragen und -Antworten an die entsprechenden IPv4-Adressen und umgekehrt. IPv4-Name-zu-Adress-Zuordnungen werden im DNS mit "A"-Abfragen gespeichert. IPv6-Name-zu-Adress-Zuordnungen werden im DNS mit "AAAA"-Abfragen gespeichert.
Verwenden Sie für IPv6-DNS-Abfragen die do-not-translate-AAAA-query-to-A-query Anweisung auf Hierarchieebene [edit applications application application-name] .
Dynamisches NAT
Der dynamische NAT-Fluss ist in Abbildung 1 dargestellt.
Mit dynamischer NAT können Sie eine private IP-Adresse (Quelle) einer öffentlichen IP-Adresse zuordnen, die aus einem Pool registrierter (öffentlicher) IP-Adressen stammt. NAT-Adressen aus dem Pool werden dynamisch zugewiesen. Durch die dynamische Zuweisung von Adressen können auch einige wenige öffentliche IP-Adressen von mehreren privaten Hosts verwendet werden, im Gegensatz zu einem gleich großen Pool, der von der statischen Quell-NAT benötigt wird.
Weitere Informationen zur dynamischen Adressübersetzung finden Sie unter RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations.
Zustandsbehaftetes NAT64
Der Stateful NAT64-Flow ist in Abbildung 2 dargestellt.
Stateful NAT64 ist ein Mechanismus, um zu einem IPv6-Netzwerk zu wechseln und gleichzeitig die Erschöpfung von IPv4-Adressen zu bewältigen. Wenn Nur-IPv6-Clients IPv4-Server über Unicast UDP, TCP oder ICMP kontaktieren können, können mehrere Nur-IPv6-Clients dieselbe öffentliche IPv4-Serveradresse gemeinsam nutzen. Um die gemeinsame Nutzung der IPv4-Serveradresse zu ermöglichen, übersetzt NAT64 eingehende IPv6-Pakete in IPv4 (und umgekehrt).
Wenn Stateful NAT64 in Verbindung mit DNS64 verwendet wird, sind in der Regel keine Änderungen am IPv6-Client oder am IPv4-Server erforderlich. DNS64 ist nicht Gegenstand dieses Dokuments, da es normalerweise als Erweiterung für derzeit bereitgestellte DNS-Server implementiert wird.
Stateful NAT64, spezifiziert in RFC 6146, Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, wird vollständig von der Junos Address Aware Netzwerkadressierung unterstützt.
464XLAT
Ab Junos OS Version 17.1R1 können Sie einen 464XLAT Provider-Side Translater (PLAT) konfigurieren. Dies wird nur auf MS-MICs und MS-MPCs unterstützt. 464XLAT bietet eine einfache und skalierbare Technik für einen IPv4-Client mit einer privaten Adresse, um sich über ein IPv6-Netzwerk mit einem IPv4-Host zu verbinden. 464XLAT unterstützt IPv4 nur im Client-Server-Modell, daher unterstützt es keine IPv4-Peer-to-Peer-Kommunikation oder eingehende IPv4-Verbindungen.
Ein kundenseitiger Übersetzer (CLAT), der kein Produkt von Juniper Networks ist, übersetzt das IPv4-Paket in IPv6, indem er die IPv4-Quell- und Zieladressen in IPv6/96-Präfixe einbettet und das Paket über ein IPv6-Netzwerk an das PLAT sendet. Das PLAT übersetzt das Paket in IPv4 und sendet das Paket über ein IPv4-Netzwerk an den IPv4-Host (siehe Abbildung 3).
XLAT464 bietet den Vorteil, dass kein IPv4-Netzwerk unterhalten und keine zusätzlichen öffentlichen IPv4-Adressen zugewiesen werden müssen.
Die CLAT kann sich auf dem mobilen Endgerät des Endbenutzers in einem reinen IPv6-Mobilfunknetzwerk befinden, sodass Mobilfunkanbieter IPv6 für ihre Benutzer and bereitstellen können, die reine IPv4-Anwendungen auf mobilen Geräten unterstützen (siehe Abbildung 4).
Dual-Stack Lite
Der Dual-Stack-Lite-Flow (DS-Lite) ist in Abbildung 5 dargestellt.
DS-Lite verwendet IPv4-over-IPv6-Tunnel, um ein IPv6-Zugangsnetzwerk zu durchqueren und eine IPv4-IPv4-NAT auf Betreiberniveau zu erreichen. Dies erleichtert die schrittweise Einführung von IPv6 im Internet, indem es die Abwärtskompatibilität mit IPv4 gewährleistet.
DS-Lite wird auf Routern der MX-Serie mit MS-DPCs und auf Routern der M Series mit MS-100-, MS-400- und MS-500-MultiServices-PICS unterstützt. Ab Junos OS Version 17.4R1 wird DS-Lite auf Routern der MX-Serie mit MS-MPCs und MS-MIC unterstützt.Ab Junos OS Version 19.2R1 wird DS-Lite auf MX Virtual Chassis- und MX Broadband Network Gateway (BNG)-Routern unterstützt.
Junos Address Aware Linecard-Support für Netzwerkadressierung
Junos Address Aware Technologien zur Netzwerkadressierung sind auf den folgenden Linecards verfügbar:
-
MultiServices Dense Port Concentrator (MS-DPC)
-
MS-100, MS-400 und MS-500 MultiServices PICS
-
MultiServices Modular Port Concentrator (MS-MPC) und MultiServices Modular Interface Card (MS-MIC)
-
Modulare Portkonzentratoren (Inline-NAT).
Eine Liste der spezifischen NAT-Typen, die von jedem Kartentyp unterstützt werden, finden Sie unter Vergleich der NAT-Funktionen auf Betreiberniveau für Junos Address Aware nach Art der Schnittstellenkarte.
Siehe auch
Beispiele für IPv6-Übergangsszenarien
Junos OS unterstützt viele IPv6-Übergangsszenarien, die von Junos OS-Kunden benötigt werden. Im Folgenden finden Sie ausgewählte Beispiele:
- Beispiel 1: IPv4-Erschöpfung mit einem Nicht-IPv6-Zugangsnetzwerk
- Beispiel 2: IPv4-Erschöpfung mit einem IPv6-Zugangsnetzwerk
- Beispiel 3: IPv4-Erschöpfung für Mobilfunknetze
Beispiel 1: IPv4-Erschöpfung mit einem Nicht-IPv6-Zugangsnetzwerk
Abbildung 6 zeigt ein Szenario, in dem der Internet Service Provider (ISP) sein IPv4-Netzwerk nicht wesentlich geändert hat. Dieser Ansatz ermöglicht IPv4-Hosts den Zugriff auf das IPv4-Internet und IPv6-Hosts den Zugriff auf das IPv6-Internet. Ein Dual-Stack-Host kann als IPv4-Host behandelt werden, wenn er den IPv4-Zugriffsdienst verwendet, und als IPv6-Host, wenn er den IPv6-Zugriffsdienst verwendet.
Bei diesem Ansatz müssen zwei neue Gerätetypen bereitgestellt werden: ein Dual-Stack-Home-Gateway und ein Dual-Stack-Network Address Translation (NAT) auf Betreiberniveau. Das Dual-Stack-Home-Gateway integriert IPv4-Weiterleitung und v6-over-v4-Tunneling-Funktionen. Es kann auch eine v4-v4 NAT-Funktion integrieren. Die Dual-Stack-Carrier-Grade NAT (CGN) integriert v6-over-v4-Tunneling und v4-v4-NAT-Funktionen der Carrier-Klasse.
Beispiel 2: IPv4-Erschöpfung mit einem IPv6-Zugangsnetzwerk
In dem in Abbildung 7 dargestellten Szenario ist das ISP-Netzwerk nur IPv6.
Die Dual-Stack-Lite-Lösung (DS-Lite) eignet sich für reine IPv6-ISPs. Das beste Geschäftsmodell für diesen Ansatz ist, dass das Customer Premises Equipment (CPE) die Funktionen für das Tunneling von IPv6 zu einem IPv4-Backbone und das Tunneling von IPv4 zu einem IPv6-Backbone integriert hat und automatisch erkennen kann, welche Lösung benötigt wird.
Nicht alle Kunden eines bestimmten ISP müssen gleichzeitig vom IPv4-Zugriff auf den IPv6-Zugriff wechseln. Tatsächlich kann der Übergang besser gehandhabt werden, indem Kundengruppen (z. B. alle, die mit einem einzigen Point of Presence verbunden sind) schrittweise Switching durchgeführt werden. Ein solcher inkrementeller Ansatz sollte sich als einfacher zu planen, terminieren und auszuführen erweisen als eine umfassende Umstellung.
Beispiel 3: IPv4-Erschöpfung für Mobilfunknetze
Die Komplexität von Mobilfunknetzen erfordert einen flexiblen Migrationsansatz, um minimale Unterbrechungen und maximale Abwärtskompatibilität während des Übergangs zu gewährleisten. NAT64 kann verwendet werden, um IPv6-Geräten die Kommunikation mit IPv4-Hosts zu ermöglichen, ohne die Clients zu ändern.
Übersicht über die NAT-Implementierung von Junos OS auf Betreiberniveau
Mit Junos OS können Sie eine Carrier-Grade Network Address Translation (CGNAT)-Lösung implementieren und skalieren, die auf der Art der für Ihre Implementierung verwendeten Serviceschnittstellen basiert:
MultiServices Denser Port Concentrator (MS-DPC): Das Layer-3-Services-Paket wird verwendet, um NAT für adaptive MS-DPC-Service-PIC zu konfigurieren. Diese Lösung stellt die NAT-Funktionalität bereit, die in der Übersicht über die Netzwerkadressierung von Junos Address Aware beschrieben wird.
MS-100-, MS-400- und MS-500-MultiServices-PICS: Das Layer-3-Services-Paket wird verwendet, um NAT für Multiservice-PIC zu konfigurieren. Diese Lösung stellt die NAT-Funktionalität bereit, die in der Übersicht über die Netzwerkadressierung von Junos Address Aware beschrieben wird.
MultiServices Modular Port Concentrator (MS-MPC) und MultiServices Modular Interface Card (MS-MIC) – MS-MPCs und MS-MICs sind vorkonfiguriert, um die Konfiguration von NAT auf Betreiberniveau zu ermöglichen. Diese Lösung stellt die NAT-Funktionalität bereit, die in der Übersicht über die Netzwerkadressierung von Junos Address Aware beschrieben wird.
Inline NAT for Modular Port Concentrator (MPC) Line Cards) – Inline NAT nutzt die Servicefunktionen von MPC-Linecards und ermöglicht eine kostengünstige Implementierung der NAT-Funktionalität auf der Datenebene, wie unter Übersicht über Inline Network Address Translation beschrieben.
Siehe auch
Vergleich der NAT-Funktionen auf Betreiberniveau für Junos Address Aware nach Art der Schnittstellenkarte
Tabelle 1 fasst die Funktionsunterschiede zwischen den NAT-Implementierungen von Junos OS auf Betreiberniveau zusammen.
Ab Junos OS Version 17.2R1 wird Inline-NAT auf MPC5E und MPC6E unterstützt.
Ab Junos OS Version 17.4R1 wird Inline-NAT auf MPC7E, MPC8E und MPC9E unterstützt.
Funktion |
MS-DPC MS-100 MS-400 MS-500 |
MS-MPC MS-MIC |
MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E und MPC9E Inline-NAT |
|---|---|---|---|
Statische Quelle NAT |
Nein |
Nein |
Nein |
Dynamische Quelle NAT – nur Adresse |
Nein |
Nein |
Nein |
Dynamic Source NAT – NAPT-Portübersetzung mit gesicherter Portblockierung |
Nein |
ja (Dynamic Source NAT – NAPT Port Translation mit gesicherter Portblockzuweisung für MS-MPC und MS-MIC ab Junos OS Version 14.2R2) |
Nein |
Dynamic Source NAT – NAPT44 Port-Übersetzung mit deterministischer Portblockzuweisung |
Nein |
ja (Dynamic Source NAT – NAPT44 Port Translation with Deterministic Port Block Allocation supported for MS-MPC and MS-MIC ab Junos OS Version 17.3R1, in Junos OS Version 14.2R7 und höher 14.2, in 15.1R3 und höher 15.1 sowie in 16.1R5 und höher 16.1) |
Nein |
Dynamic Source NAT – NAPT64-Port-Übersetzung mit deterministischer Portblockzuweisung |
Nein |
ja (Dynamic Source NAT – NAPT64 Port Translation mit deterministischer Portblockzuweisung für MS-MPC und MS-MIC ab Junos OS Version 17.4R1) |
Nein |
Statische Ziel-NAT |
Nein |
Nein |
Nein
Hinweis:
Destination NAT kann indirekt implementiert werden. Siehe Überblick über Inline Network Address Translation |
Zweimal NAT |
Nein |
ja (zweimal wird NAT für MS-MPC und MS-MIC ab Junos OS Version 15.1R1 unterstützt) |
Nein
Hinweis:
Zweimal kann NAT indirekt implementiert werden. Siehe Überblick über Inline Network Address Translation |
NAPT – Parität und Reichweite bewahren |
Nein |
ja (NAPT – Parität und Bereich beibehalten für MS-MPC und MS-MIC ab Junos OS Version 15.1R1) |
Nein |
NAPT – APP/EIF/EIM |
Nein |
Nein |
Nein |
IKE ALG |
Nein |
ja (ab Junos OS Version 14.2R7, 15.1R5, 16.1R2 und 17.1R1) |
Nein |
Zustandsbehaftetes NAT64 |
Nein |
Nein |
Nein |
Stateful NAT64 mit APP/EIM/EIF |
Nein |
Nein |
Nein |
Stateful NAT64 mit ALGs
|
Nein |
Nein |
Nein |
DS-Lite |
Nein |
ja (DS-Lite unterstützt MS-MPC und MS-MIC ab Junos OS Version 17.4R1) |
Nein |
Platz 6 |
Nein |
Nein |
Nein |
6to4 |
Nein |
Nein |
Nein |
464XLAT |
Nein |
ja (ab Junos OS Version 17.1R1) |
Nein |
Überlappungsadressen im gesamten NAT-Pool |
Nein |
Nein |
Nein |
| Überlastungs-Pool |
Nein |
Nein |
Nein |
Port Control Protocol |
Nein |
ja (Das Port Control Protocol mit NAPT44 wird für MS-MPC und MS-MIC ab Junos OS Version 17.4R1 unterstützt. Ab Junos OS Version 18.2R1 unterstützt das Port Control Protocol auf MS-MPC und MS-MIC DS-Lite. PCP bietet einen Mechanismus zur Steuerung der Weiterleitung eingehender Pakete durch vorgeschaltete Geräte wie NAT44 und Firewall-Geräte sowie einen Mechanismus zur Reduzierung des Application Keepalive-Datenverkehrs. |
Nein |
CGN-PIC |
Nein |
Nein |
Nein |
AMS Support |
Nein |
Nein |
Nein |
Portweiterleitung |
Nein |
ja (Portweiterleitung wird für MS-MPC und MS-MIC ab Junos OS Version 17.4R1 unterstützt.) |
Nein |
Keine Übersetzung |
Nein |
ja (keine Übersetzung für MS-MPC und MS-MIC ab Junos OS Version 15.1R1 unterstützt) |
Nein |
Tabelle 2 fasst die Verfügbarkeit von Übersetzungstypen nach Linecard-Typ zusammen.
Art der Übersetzung |
MS-DPC MS-100 MS-400 MS-500 |
MS-MPC MS-MIC |
MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E und MPC9E Inline-NAT |
|---|---|---|---|
|
Nein |
Nein |
Nein |
|
Nein |
Nein |
Nein |
|
Nein |
Nein |
Nein |
|
Nein |
ja ( |
Nein |
|
Nein |
ja ( |
Nein |
|
Nein |
Nein |
Nein |
|
Nein |
Nein |
Nein |
|
Nein |
Nein |
Nein |
|
Nein |
Nein |
Nein |
|
Nein |
Nein |
Nein |
|
Nein |
ja (ab Junos OS Version 17.1R1) |
Nein |
|
Nein |
Nein |
Nein |
|
Nein |
ja ( |
ja ( |
|
Nein |
ja ( |
Nein |
|
Nein |
ja ( |
Nein |
ALGs verfügbar für Junos OS Address Aware NAT
Die folgenden in Tabelle 3 aufgeführten Gateways auf Anwendungsebene (ALGs) werden für die NAT-Verarbeitung auf den aufgeführten Plattformen unterstützt.
Um die Implementierungsdetails (Port, Protokoll usw.) für diese Junos OS-Standardanwendungen anzuzeigen, suchen Sie den Junos OS-Standard-ALG-Namen in der Tabelle, und suchen Sie dann den aufgeführten Namen in . groups Weitere Informationen zu TFTP finden Sie junos-tftp beispielsweise wie abgebildet.
Das Junos OS stellt die bereit, die junos-algdie Funktion anderer ALGs ermöglicht, indem ALG-Registrierungen verarbeitet werden, Pakete mit langsamem Pfad durch registrierte ALGs fließen und ALG-Ereignisse an die ALG-Plug-ins übertragen werden. Das junos-alg ALG ist automatisch auf den MS-MPC- und MS-MIC-Plattformen verfügbar und erfordert keine weitere Konfiguration.
Die Remote Shell (RSH) und Remote Login (rlogin) Application Layer Gateways (ALGs) werden von Network Address Port Translation (NAPT) auf Routern der MX-Serie mit MS-MICs und MS-MPCs nicht unterstützt.
user@host# show groups junos-defaults applications application junos-tftp application-protocol tftp; protocol udp; destination-port 69;
Tabelle 3 fasst die ALGs zusammen, die für Junos OS Address Aware NAT für Services Interface-Karten verfügbar sind.
ALG |
MS-DPC |
MS-MPC, MS-MIC |
Junos OS – Standard-ALG-Name |
|---|---|---|---|
Grundlegende TCP-ALG |
Nein |
Nein |
Hinweis:
Bestimmte Junos OS ALGs werden nicht unterstützt. Eine Funktion namens TCP-Tracker, die standardmäßig verfügbar ist, führt jedoch Segmentreihenfolge und erneute Übertragung sowie Verbindungsverfolgung sowie Validierungen für TCP-Verbindungen durch. |
Grundlegende UDP-ALG |
Nein |
Nein |
Hinweis:
Der TCP-Tracker führt begrenzte Integritäts- und Validierungsprüfungen für UDP durch. |
BOOTEN |
Nein |
Nein |
|
DCE RPC-Services |
Nein |
Nein |
|
DNS (Englisch) |
Nein |
Nein |
|
DNS (Englisch) |
Nein |
Nein |
|
FTP |
Nein |
Nein |
|
Gatekeeper RAS (ab Junos OS Version 17.1R1) |
Nein |
Nein |
|
H323 |
Nein |
Nein |
|
ICMP |
Nein |
Nein
Hinweis:
In Junos OS Version 14.1 und früher werden ICMP-Nachrichten standardmäßig verarbeitet, aber PING ALG-Unterstützung wird nicht bereitgestellt. Ab Junos OS 14.2 werden ICMP-Nachrichten standardmäßig verarbeitet und PING ALG-Unterstützung bereitgestellt. |
|
IIOP |
Nein |
Nein |
|
IKE ALG |
Nein |
Nein
Hinweis:
Ab Junos OS Version 14.2R7, 15.1R5, 16.1R2 und 17.1R1 wird das IKE ALG ALG auf MS-MPCs und MS-MICs unterstützt. |
|
IP (IP) |
Nein |
Der TCP-Tracker, der auf diesen Plattformen standardmäßig verfügbar ist, führt begrenzte Integritäts- und Validierungsprüfungen durch. |
|
NETBIOS |
Nein |
Nein |
|
NETSHOW |
Nein |
Nein |
|
PPTP |
Nein |
Nein |
|
REALAUDIO |
Nein |
Nein |
|
Sun RPC- und RPC-Portkartenservices |
Nein |
Nein |
|
RTSP |
Nein |
Nein |
|
SIP |
Nein |
Nein |
Das SIP
Hinweis:
SIP-Sitzungen sind auf 12 Stunden (720 Minuten) für die NAT-Verarbeitung auf den MS-MIC- und MS-MPC-Schnittstellenkarten begrenzt. SIP-Sitzungen auf dem MS-DPC haben keine zeitliche Begrenzung. |
SNMP |
Nein |
Nein |
|
SQLNET |
Nein |
Nein |
|
TFTP |
Nein |
Nein |
|
Traceroute |
Nein |
Nein |
|
Unix Remote Shell Service |
Nein |
Nein
Hinweis:
Remote Shell (RSH) ALG wird für Network Address Port Translation (NAPT) nicht unterstützt. |
|
WINFrame |
Nein |
Nein |
|
TALK-UDP |
Nein |
Nein |
|
MS RPC |
Nein |
Nein |
|
Siehe auch
ALGs standardmäßig verfügbar für Junos OS Address Aware NAT auf dem ACX500-Router
Die folgenden in Tabelle 4 aufgeführten Gateways auf Anwendungsebene (ALGs) werden für die NAT-Verarbeitung auf ACX500-Routern unterstützt.
Um die Implementierungsdetails (Port, Protokoll usw.) für diese Junos OS-Standardanwendungen anzuzeigen, suchen Sie den Junos OS-Standard-ALG-Namen in der Tabelle, und suchen Sie dann den aufgeführten Namen in . groups Weitere Informationen zu TFTP finden Sie junos-tftp beispielsweise wie abgebildet.
Das ALG für NAT wird nur auf den ACX500-Innenroutern unterstützt.
Das Junos OS stellt die bereit, die junos-algdie Funktion anderer ALGs ermöglicht, indem ALG-Registrierungen verarbeitet werden, Pakete mit langsamem Pfad durch registrierte ALGs fließen und ALG-Ereignisse an die ALG-Plug-ins übertragen werden. Das junos-alg ALG ist automatisch auf dem ACX500-Router verfügbar und erfordert keine weitere Konfiguration.
Die Remote-Anmeldung (rlogin) Application Layer Gateways (ALGs) werden mit Network Address Port Translation (NAPT) auf dem ACX500-Router nicht unterstützt.
| ALG |
ACX500 Router |
Junos OS – Standard-ALG-Name |
|---|---|---|
| Grundlegende TCP-ALG |
Nein |
Hinweis:
Bestimmte Junos OS ALGs werden nicht unterstützt. Eine Funktion namens TCP-Tracker, die standardmäßig verfügbar ist, führt jedoch Segmentreihenfolge und erneute Übertragung sowie Verbindungsverfolgung sowie Validierungen für TCP-Verbindungen durch. |
| Grundlegende UDP-ALG |
Nein |
Hinweis:
Der TCP-Tracker führt begrenzte Integritäts- und Validierungsprüfungen für UDP durch. |
| DNS (Englisch) |
Nein |
|
| FTP |
Nein |
|
| ICMP |
Nein
Hinweis:
ICMP-Nachrichten werden standardmäßig verarbeitet, aber PING ALG-Unterstützung wird nicht bereitgestellt. |
|
| TFTP |
Nein |
|
| Unix Remote Shell Service |
Nein
Hinweis:
Remote Shell (RSH) ALG wird für Network Address Port Translation (NAPT) nicht unterstützt. |
|
Details zum ALG-Support
Dieser Abschnitt enthält Details zu den ALGs. Er umfasst Folgendes:
Grundlegender TCP
Diese ALG führt eine grundlegende Plausibilitätsprüfung für TCP-Pakete durch. Wenn Fehler gefunden werden, werden die folgenden Anomalieereignisse und Systemprotokollmeldungen generiert:
-
TCP-Quell- oder Zielport Null
-
TCP-Header-Längenprüfung fehlgeschlagen
-
TCP-Sequenznummer null und es werden keine Flags gesetzt
-
TCP-Sequenznummer Null und FIN/PSH/RST-Flags sind gesetzt
-
TCP FIN/RST oder SYN(URG|FIN|RST)-Flags gesetzt sind
Die TCP-ALG führt die folgenden Schritte aus:
-
Wenn der Router ein SYN-Paket empfängt, erstellt der ALG TCP-Forward- und -Reverse-Flows und gruppiert sie in einer Konversation. Es verfolgt den TCP-Drei-Wege-Handshake.
-
Der SYN-Abwehrmechanismus verfolgt den TCP-Verbindungsaufbaustatus. Es wird erwartet, dass die TCP-Sitzung innerhalb eines kleinen Zeitintervalls (derzeit 4 Sekunden) aufgebaut wird. Wenn der TCP-Drei-Wege-Handshake in diesem Zeitraum nicht eingerichtet wird, wird die Sitzung beendet.
-
Ein Keepalive-Mechanismus erkennt TCP-Sitzungen mit nicht reagierenden Endgeräten.
-
ICMP-Fehler sind nur zulässig, wenn ein Flow mit den in den ICMP-Daten angegebenen Selektorinformationen übereinstimmt.
Grundlegende UDP
Diese ALG führt eine grundlegende Plausibilitätsprüfung für UDP-Header durch. Wenn Fehler gefunden werden, werden die folgenden Anomalieereignisse und Systemprotokollmeldungen generiert:
-
UDP-Quell- oder Zielport 0
-
UDP-Header-Längenprüfung fehlgeschlagen
Der UDP-ALG führt die folgenden Schritte aus:
-
Wenn das erste Paket empfangen wird, erzeugt das ALG bidirektionale Datenströme, um UDP-Sitzungsdatenverkehr weiterzuleiten und umzukehren.
-
Wenn die Sitzung länger als die maximal zulässige Leerlaufzeit (der Standardwert beträgt 30 Sekunden) im Leerlauf ist, werden die Flows gelöscht.
-
ICMP-Fehler sind nur zulässig, wenn ein Flow mit den in den ICMP-Daten angegebenen Selektorinformationen übereinstimmt.
DNS (Englisch)
Das Domain Name System (DNS) ALG verarbeitet Daten, die mit der Suche und Übersetzung von Domainnamen in IP-Adressen verbunden sind. Der ALG wird normalerweise auf Port 53 ausgeführt. Der ALG überwacht DNS-Anfrage- und -Antwortpakete und unterstützt nur UDP-Datenverkehr. Die ALG unterstützt keine Payload-Übersetzungen. Das DNS ALG schließt die Sitzung nur, wenn eine Antwort empfangen wird oder ein Leerlauf-Timeout erreicht wird.
Im Folgenden finden Sie ein Beispiel für die Konfiguration von DNS-ALG:
-
Erstellen einer NAT-Schnittstelle.
[edit] services { service-set set-dns { nat-rules nat-dns; interface-service { service-interface ms-0/2/0; } } -
Konfigurieren des NAT-Pools.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definieren von NAT-Regeln für DNS ALG.
[edit] services { nat { rule nat-dns { match-direction input; term term1 { from { source-address { 10.50.50.2/32; } applications junos-dns-udp;; } then { translated { source-pool p-napt; translation-type { basic-nat44; } } } } } } -
Binden von Dienstsätzen an die Schnittstelle.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-dns; } output { service-set set-dns; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
FTP
FTP ist das Dateiübertragungsprotokoll, das in RFC 959 spezifiziert ist. Neben der Hauptsteuerverbindung werden auch Datenverbindungen für die Datenübertragung zwischen Client und Server hergestellt. und der Host, der Port und die Richtung werden über den Steuerkanal ausgehandelt.
Bei FTP im nicht-passiven Modus scannt der Stateful Firewall-Service von Junos OS die Client-zu-Server-Anwendungsdaten nach dem PORT-Befehl, der die IP-Adresse und Portnummer bereitstellt, mit der der Server eine Verbindung herstellt. Bei FTP im passiven Modus scannt der Stateful Firewall-Service von Junos OS die Client-zu-Server-Anwendungsdaten nach dem PASV-Befehl und scannt dann die Server-zu-Client-Antworten nach der Antwort 227, die die IP-Adresse und Portnummer enthält, mit der der Client eine Verbindung herstellt.
Es gibt eine zusätzliche Komplikation: FTP stellt diese Adressen und Portnummern in ASCII dar. Wenn Adressen und Ports umgeschrieben werden, kann sich daher die TCP-Sequenznummer ändern, und danach muss der NAT-Dienst dieses Delta in SEQ- und ACK-Nummern beibehalten, indem er Sequenz-NAT für alle nachfolgenden Pakete durchführt.
Die Unterstützung für Stateful-Firewall- und NAT-Services erfordert, dass Sie das FTP-ALG auf TCP-Port 21 konfigurieren, um das FTP-Steuerungsprotokoll zu aktivieren. Die ALG übernimmt folgende Aufgaben:
-
Automatische Zuweisung von Datenports und Firewall-Berechtigungen für dynamische Datenverbindungen
-
Erstellt Flows für die dynamisch ausgehandelte Datenverbindung
-
Überwacht die Steuerverbindung sowohl im aktiven als auch im passiven Modus
-
Schreibt die Steuerpakete mit der entsprechenden NAT-Adresse und Portinformationen um
Damit passives FTP auf dem ACX500 ordnungsgemäß funktioniert, ohne dass das FTP Application Layer Gateway (ALG) aktiviert ist (indem Sie die application junos-ftp Anweisung auf der [edit services nat rule rule-name term term-name from] Hierarchieebene nicht angeben), müssen Sie die aktivierte APP-Funktion (Address Pooling Pairing) aktivieren (indem Sie die address-pooling Anweisung auf Hierarchieebene [edit services nat rule rule-name term term-name then translated] einschließen). Eine solche Konfiguration führt dazu, dass die Daten- und Steuer-FTP-Sitzungen dieselbe NAT-Adresse erhalten.
Im Folgenden finden Sie ein Beispiel für die Konfiguration von FTP ALG:
-
Erstellen einer NAT-Schnittstelle.
[edit] services { service-set set-ftp { nat-rules nat-ftp; interface-service { service-interface ms-0/2/0; } } -
Konfigurieren des NAT-Pools.
[edit] services { nat { pool p-napt { address 10.30.30.0/24; port { range low 9000 high 9010; } } } -
Definieren von NAT-Regeln für FTP-ALG.
[edit] services { nat { rule nat-ftp { match-direction input; term term1 { from { source-address { 10.10.10.0/24; } applications junos-ftp; } then { translated { source-pool p-napt; translation-type { napt-44; } } } } } } -
Binden von Dienstsätzen an die Schnittstelle.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-ftp; } output { service-set set-ftp; } } address 10.10.10.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.10.10.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
ICMP
Das Internet Control Message Protocol (ICMP) ist in RFC 792 definiert. Das Junos OS ermöglicht das Filtern von ICMP-Nachrichten nach einem bestimmten Typ oder einem bestimmten Typcodewert. ICMP-Fehlerpakete, denen ein speziell konfigurierter Typ und Code fehlt, werden mit allen vorhandenen Datenströmen in die entgegengesetzte Richtung abgeglichen, um die Legitimität des Fehlerpakets zu prüfen. ICMP-Fehlerpakete, die den Filterabgleich bestehen, unterliegen der NAT-Übersetzung.
Das ICMP ALG verfolgt den Ping-Datenverkehr immer zustandsbehaftet anhand der ICMP-Sequenznummer. Jede Echoantwort wird nur weitergeleitet, wenn eine Echoanforderung mit der entsprechenden Sequenznummer vorliegt. Für jeden Ping-Flow können nur 20 Echo-Anfragen weitergeleitet werden, ohne eine Echo-Antwort zu erhalten. Wenn Sie dynamisches NAT konfigurieren, wird der PING-Paketbezeichner übersetzt, damit zusätzliche Hosts im NAT-Pool denselben Bezeichner verwenden können.
Die Unterstützung für NAT-Dienste erfordert, dass Sie das ICMP-ALG konfigurieren, wenn das Protokoll benötigt wird. Sie können den ICMP-Typ und den ICMP-Code für zusätzliche Filterung konfigurieren.
TFTP
Das Trivial File Transfer Protocol (TFTP) ist in RFC 1350 spezifiziert. Die ersten TFTP-Anforderungen werden an den UDP-Zielport 69 gesendet. Zusätzliche Flows können erstellt werden, um einzelne Dateien abzurufen oder abzulegen . Die Unterstützung von NAT-Diensten erfordert, dass Sie das TFTP-ALG für den UDP-Zielport 69 konfigurieren.
Im Folgenden finden Sie ein Beispiel für die Konfiguration von TFTP ALG:
-
Erstellen einer NAT-Schnittstelle.
[edit] services { service-set set-tftp { nat-rules nat-tftp; interface-service { service-interface ms-0/2/0; } } -
Konfigurieren des NAT-Pools.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definieren von NAT-Regeln für TFTP ALG.
[edit] services { nat { rule nat-tftp { match-direction input; term term1 { from { source-address { 10.50.50.2/32; } applications junos-tftp; } then { translated { source-pool p-napt; translation-type { dynamic-nat44; } } } } } } -
Binden von Dienstsätzen an die Schnittstelle.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-tftp; } output { service-set set-tftp; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
UNIX Remote-Shell-Services
Drei Protokolle bilden die Grundlage für UNIX-Remote-Shell-Services:
-
Exec – Ausführung von Remotebefehlen; Ermöglicht es einem Benutzer auf dem Client-System, einen Befehl auf dem entfernten System auszuführen. Der erste Befehl von Client(
rcmd) zu Server(rshd) verwendet den bekannten TCP-Port 512. Eine zweite TCP-Verbindung kann auf Anfrage vonrcmdgeöffnet werden. Die Clientportnummer für die zweite Verbindung wird als ASCII-Zeichenfolge an den Server gesendet. -
Anmeldung: Besser bekannt als
rlogin; verwendet den bekannten TCP-Port 513. Weitere Informationen finden Sie unter RFC 1282. Es ist keine spezielle Firewall-Verarbeitung erforderlich. -
Shell: Ausführung von Remotebefehlen; Ermöglicht es einem Benutzer auf dem Client-System, einen Befehl auf dem entfernten System auszuführen. Der erste Befehl vom Client (
rcmd) zum Server (rshd) verwendet den bekannten TCP-Port 514. Eine zweite TCP-Verbindung kann auf Anfrage vonrcmdgeöffnet werden. Die Clientportnummer für die zweite Verbindung wird als ASCII-Zeichenfolge an den Server gesendet.
NAT-Remote-Shell-Services erfordern, dass jeder zugewiesene dynamische Quellport innerhalb des Portbereichs 512 bis 1023 liegt. Wenn Sie einen NAT-Pool konfigurieren, ist dieser Portbereich ausschließlich Remote-Shell-Anwendungen vorbehalten.
Im Folgenden finden Sie ein Beispiel für die Konfiguration von RSH ALG:
-
Erstellen einer NAT-Schnittstelle.
[edit] services { service-set set-rsh { nat-rules nat-rsh; interface-service { service-interface ms-0/2/0; } } -
Konfigurieren des NAT-Pools.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Definition von NAT-Regeln für RSH ALG.
[edit] services { nat { rule nat-rsh { match-direction input; term term1 { from { source-address { 510.0.50.2/32; } applications junos-rsh; } then { translated { source-pool p-napt; translation-type { dynamic-nat44; } } } } } } -
Binden von Dienstsätzen an die Schnittstelle.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-rsh; } output { service-set set-rsh; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
Siehe auch
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.
deterministic-napt64 unterstützt für MS-MPC und MS-MIC
stateful-nat464
twice-dynamic-nat-44 unterstützt für MS-MPC und MS-MIC
twice-basic-nat-44 unterstützt für Inline-NAT
twice-dynamic-nat-44 unterstützt für MS-MPC und MS-MIC
twice-dynamic-napt-44 unterstützt für MS-MPC und MS-MIC
deterministic-napt44 unterstützt für MS-MPC und MS-MIC