Konfigurieren von Serviceschnittstellen
Übersicht über die Benennung von Services-Schnittstellen
Jede Schnittstelle hat einen Schnittstellennamen, der den Medientyp, den Steckplatz, in dem sich die FPC befindet, den Speicherort auf der FPC, in der die PIC installiert ist, und den PIC-Port angibt. Der Schnittstellenname identifiziert einen einzelnen Netzwerkkonnektor im System eindeutig. Sie verwenden den Schnittstellennamen bei der Konfiguration von Schnittstellen und bei der Aktivierung verschiedener Funktionen und Eigenschaften, wie z. B. Routing-Protokolle, auf einzelnen Schnittstellen. Das System verwendet den Schnittstellennamen, wenn Informationen über die Schnittstelle angezeigt werden, z. B. im show interfaces Befehl.
Der Schnittstellenname wird durch ein physisches Teil, ein logisches Teil und ein Kanalteil im folgenden Format dargestellt:
physical<:channel>.logical
Der Kanalteil des Namens ist für alle Schnittstellen mit Ausnahme der kanalisierten DS3-, E1-, OC12- und STM1-Schnittstellen optional.
Der physische Teil eines Schnittstellennamens identifiziert das physische Gerät, was einem einzelnen physischen Netzwerkkonnektor entspricht. Dieser Teil des Schnittstellennamens hat das folgende Format:
type-fpc/pic/port
type ist der Medientyp, der das Netzwerkgerät identifiziert. Für Serviceschnittstellen kann es sich um eine der folgenden Sein:
ams– Aggregierte Multiservices (AMS)-Schnittstelle. Eine AMS-Schnittstelle ist ein Bündel von Serviceschnittstellen, die als eine einzige Schnittstelle fungieren können. Eine AMS-Schnittstelle wird wieamsNin der Konfiguration angezeigt, wobeiNeine eindeutige Nummer ist, die eine AMS-Schnittstelle identifiziert (z. Bams0. ). Die Mitgliederschnittstellen in einer AMS-Schnittstelle werden in der Konfiguration mit einemmams-Präfix identifiziert (z. Bmams-1/2/0. ).cp– Schnittstelle für Datenstromsammleres— Verschlüsselungsschnittstellegr— Generische Routing-Kapselungstunnelschnittstelle.gre— Diese Schnittstelle wird intern generiert und nicht konfigurierbar.ip— IP-over-IP-Kapselungstunnelschnittstelle.ipip— Diese Schnittstelle wird intern generiert und nicht konfigurierbar.ls— Schnittstelle für Verbindungsservices.lsq—Intelligente Warteschlangenschnittstelle (IQ) für Verbindungsservices; wird auch für Sprachdienste verwendet.mams— Mitgliederschnittstelle in einer AMS-Schnittstelle.ml– Multilink-Schnittstelle.mo— Überwachungs-Serviceschnittstelle. Die logische Schnittstellemo-fpc/pic/port.16383 ist eine intern generierte, nicht konfigurierbare Schnittstelle für den Routersteuerungsverkehr.ms— Multiservices-Schnittstellen auf modularen Schnittstellenkarten (MS-MIC) und modularen Portkonzentratoren für Multiservices (MS-MPC).mt– Multicast-Tunnelschnittstelle. Diese Schnittstelle wird automatisch generiert, Sie können jedoch bei Bedarf Eigenschaften darauf konfigurieren.mtun— Diese Schnittstelle wird intern generiert und nicht konfigurierbar.rlsq— Redundanz LSQ-Schnittstelle.rsp— Adaptive Serviceschnittstelle für Redundanz.si– Service-Inline-Schnittstelle, nur auf Routern der MX3D-Serie konfiguriert.sp– Adaptive Serviceschnittstelle. Die logische Schnittstellesp-fpc/pic/port.16383 ist eine intern generierte, nicht konfigurierbare Schnittstelle für den Routersteuerungsverkehr.tap— Diese Schnittstelle wird intern generiert und nicht konfigurierbar.vtVirtuelle Loopback-Tunnelschnittstelle.
Siehe auch
Aktivierung von Servicepaketen
Für AS-PICs, Multiservices-PICs, Multiservices-DPCs und das interne Adaptive Services Module (ASM) im M7i-Router gibt es zwei Servicepakete: Layer 2 und Layer 3. Beide Servicepakete werden auf allen adaptiven Serviceschnittstellen unterstützt, aber Sie können nur ein Servicepaket pro PIC aktivieren, mit Ausnahme eines kombinierten Pakets, das vom ASM unterstützt wird. Auf einem einzigen Router können Sie beide Servicepakete aktivieren, indem Sie zwei oder mehr PICs auf der Plattform installieren.
Graceful Routing Engine Switchover (GRES) wird automatisch auf allen Service-PICs und DPCs mit Ausnahme des ES PIC aktiviert. Es wird von allen Routern der M-Serie, MX-Serie und T-Serie mit Ausnahme von TX Matrix-Routern unterstützt. Layer-3-Services sollten nach dem Switchover den Status beibehalten, aber Layer-2-Services werden neu gestartet. Für IPsec-Services werden IKE-Verhandlungen (Internet Key Exchange) nicht gespeichert und müssen nach dem Switchover neu gestartet werden. Weitere Informationen zu GRES finden Sie im Junos OS-Benutzerhandbuch für hohe Verfügbarkeit.
Sie aktivieren Servicepakete pro PIC, nicht pro Port. Wenn Sie beispielsweise das Layer 2-Servicepaket konfigurieren, verwendet das gesamte PIC das konfigurierte Paket. Um ein Servicepaket zu aktivieren, fügen Sie die Servicepaket-Anweisung auf Der [edit chassis fpc slot-number pic pic-number adaptive-services] Hierarchieebene ein und geben Sie folgendes layer-3anlayer-2:
[edit chassis fpc slot-number pic pic-number adaptive-services] service-package (layer-2 | layer-3);
Um zu bestimmen, welches Paket ein AS PIC unterstützt, erteilen Sie den show chassis hardware Befehl: Wenn das PIC das Layer-2-Paket unterstützt, wird es als Link Services IIaufgeführt, und wenn es das Layer-3-Paket unterstützt, wird es als Adaptive Services IIaufgeführt. Um zu bestimmen, welches Paket ein Multiservices-PIC unterstützt, erteilen Sie den show chassis pic fpc-slot slot-number pic-slot slot-number Befehl. Das Package Feld zeigt den Wert Layer-2 oder Layer-3.
Der ASM verfügt über eine Standardoption (layer-2-3), die die In den Layer 2- und Layer 3-Servicepaketen verfügbaren Funktionen kombiniert.
Nachdem Sie eine Änderung des Servicepakets vorgenommen haben, wird das PIC offline genommen und sofort wieder online gestellt. Sie müssen den PIC nicht manuell offline und online nehmen.
Durch das Ändern des Servicepakets gehen alle Zustandsinformationen, die mit dem vorherigen Servicepaket verknüpft sind, verloren. Sie sollten das Servicepaket nur ändern, wenn kein aktiver Datenverkehr an den PIC geht.
Die in jedem Paket unterstützten Services unterscheiden sich nach PIC und Plattformtyp. Tabelle 1 listet die von jedem Servicepaket unterstützten Services für jeden PIC und jede Plattform auf.
Auf den AS- und Multiservices-PICs umfasst die Unterstützung von Link-Services Junos OS CoS-Komponenten, LFI (FRF.12), MLFR End-to-End (FRF.15), MLFR UNI NNI (FRF.16), MLPPP (RFC 1990) und Multiclass-MLPPP. Weitere Informationen finden Sie unter Funktionen und Schnittstellen von Layer 2-Servicepaketen und Layer 2-Servicepaketfunktionen und -schnittstellen.
Der AS PIC II für Layer 2-Service unterstützt nur das Layer-2-Servicepaket .
Dienstleistungen |
ASM |
AS/AS2 PICs und Multiservices-PICs |
AS/AS2- und Multiservices-PICs |
AS2- und Multiservices-PICs |
AS2- und Multiservices-PICs |
|---|---|---|---|---|---|
| Layer 2-Servicepaket (nur) | M7i | M7i, M10i und M20 | M40e und M120 | M320, T320 und T640 | TX-Matrix |
Link-Services: |
|||||
|
Ja |
Ja |
Ja |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Nein |
Sprachdienste: |
|||||
|
Ja |
Ja |
Ja |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Nein |
| Layer 3-Servicepaket (nur) | M7i | M7i, M10i und M20 | M40e und M120 | M320, T320 und T640 | TX-Matrix |
Sicherheitsservices: |
|||||
|
Ja |
Ja |
Ja |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Nein |
Buchhaltungsservices: |
|||||
|
Ja |
Ja |
Ja |
Ja |
Ja |
|
Nein |
Nein |
Nein |
Ja |
Nein |
|
Ja |
Ja |
Ja (nur M40e) |
Ja |
Nein |
|
Nein |
Ja |
Ja (nur M40e) |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Ja |
LNS-Services: |
|||||
|
Ja |
Ja (nur M7i und M10i) |
Ja (nur M120) |
Nein |
Nein |
Sprachdienste: |
|||||
|
Ja |
Ja |
Ja |
Ja |
Nein |
| Layer 2- und Layer 3-Servicepaket (gemeinsame Funktionen) | M7i | M7i, M10i und M20 | M40e und M120 | M320, T320 und T640 | TX-Matrix |
RPM-Services: |
|||||
|
Ja |
Ja |
Ja |
Ja |
Nein |
Tunnelservices: |
|||||
|
Ja |
Ja |
Ja |
Ja |
Ja |
|
Ja |
Ja |
Ja |
Nein |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Ja |
|
Nein |
Nein |
Nein |
Nein |
Nein |
|
Ja |
Ja |
Ja |
Ja |
Ja |
|
Ja |
Ja |
Ja |
Ja |
Ja |
|
Ja |
Ja |
Ja |
Ja |
Ja |
|
Ja |
Ja |
Ja |
Ja |
Ja |
Layer-2-Servicepaketfunktionen und -schnittstellen
Wenn Sie das Layer 2-Servicepaket aktivieren, können Sie Link-Services konfigurieren. Auf den AS- und Multiservices-PICs und dem ASM umfassen Link-Services Unterstützung für Folgendes:
Junos CoS-Komponenten – Layer-2-Servicepaketfunktionen und -schnittstellen beschreibt, wie die Junos CoS-Komponenten auf Link Services IQ (
lsq)-Schnittstellen funktionieren. Ausführliche Informationen zu Junos CoS-Komponenten finden Sie im Junos OS Class-of-Service-Benutzerhandbuch für Routing-Geräte.LFI auf Frame Relay-Links mit FRF.12 End-to-End-Fragmentierung: Der Standard für FRF.12 ist in der Spezifikation FRF.12, Frame Relay Fragmentierungsimplementierungsvereinbarung definiert.
LFI auf MLPPP-Links.
MLFR UNI NNI (FRF.16) – Der Standard für FRF.16 ist in der Spezifikation FRF.16.1, Multilink Frame Relay UNI/NNI Implementation Agreement definiert.
MLPPP (RFC 1990)
MLFR End-to-End (FRF.15)
Für die LSQ-Schnittstelle auf den AS- und Multiservices-PICs ist die Konfigurationssyntax fast die gleiche wie für Multilink- und Link Services-PICs. Der Hauptunterschied besteht in der Verwendung des Schnittstellentyp-Descriptors lsq anstelle von ml oder ls. Wenn Sie das Layer 2-Servicepaket aktivieren, werden automatisch die folgenden Schnittstellen erstellt:
gr-fpc/pic/port ip-fpc/pic/port lsq-fpc/pic/port lsq-fpc/pic/port:0 ... lsq-fpc/pic/port:N mt-fpc/pic/port pd-fpc/pic/port pe-fpc/pic/port sp-fpc/pic/port vt-fpc/pic/port
Schnittstellentypen gr, ip, , mt, , pd, peund vt sind Standardtunnelschnittstellen, die auf den AS- und Multiservices-PICs verfügbar sind, unabhängig davon, ob Sie das Layer 2- oder das Layer 3-Servicepaket aktivieren. Diese Tunnelschnittstellen funktionieren für beide Servicepakete gleich, nur dass das Layer-2-Servicepaket einige Tunnelfunktionen nicht unterstützt, wie in Tabelle 1 dargestellt.
Der Schnittstellentyp lsq-fpc/pic/port ist die physische Link Services IQ (lsq)-Schnittstelle. Schnittstellentypen lsq-fpc/pic/port:0 stellen lsq-fpc/pic/port:N FRF.16-Pakete dar. Diese Schnittstellentypen werden erstellt, wenn Sie die mlfr-uni-nni-bundles Anweisung auf der [edit chassis fpc slot-number pic pic-number] Option einschließen. Weitere Informationen finden Sie unter Funktionen und Schnittstellen für Layer 2-Servicepakete und Benutzerhandbuch für Link- und Multilink-Services-Schnittstellen für Routing-Geräte.
Der Schnittstellentyp sp wird erstellt, weil er vom Junos OS benötigt wird. Für das Layer 2-Servicepaket ist die sp Schnittstelle nicht konfigurierbar, Sie sollten sie jedoch nicht deaktivieren.
Siehe auch
Konfigurationsverfahren für Services
Führen Sie die folgenden allgemeinen Schritte zur Konfiguration von Services aus:
Beispiel: Konfiguration von Serviceschnittstellen
Die folgende Konfiguration umfasst alle Elemente, die zur Konfiguration von Services auf einer Schnittstelle erforderlich sind:
[edit]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
service {
input {
service-set Firewall-Set;
}
output {
service-set Firewall-Set;
}
}
address 10.1.3.2/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
filter {
input Sample;
}
address 172.16.1.2/24;
}
}
}
sp-1/0/0 {
unit 0 {
family inet {
address 172.16.1.3/24 {
}
}
}
}
}
forwarding-options {
sampling {
input {
family inet {
rate 1;
}
}
output {
cflowd 10.1.3.1 {
port 2055;
version 5;
}
flow-inactive-timeout 15;
flow-active-timeout 60;
interface sp-1/0/0 {
engine-id 1;
engine-type 136;
source-address 10.1.3.2;
}
}
}
}
firewall {
filter Sample {
term Sample {
then {
count Sample;
sample;
accept;
}
}
}
}
services {
stateful-firewall {
rule Rule1 {
match-direction input;
term 1 {
from {
application-sets Applications;
}
then {
accept;
}
}
term accept {
then {
accept;
}
}
}
rule Rule2 {
match-direction output;
term Local {
from {
source-address {
10.1.3.2/32;
}
}
then {
accept;
}
}
}
}
ids {
rule Attacks {
match-direction output;
term Match {
from {
application-sets Applications;
}
then {
logging {
syslog;
}
}
}
}
}
nat {
pool public {
address-range low 172.16.2.1 high 172.16.2.32;
port automatic;
}
rule Private-Public {
match-direction input;
term Translate {
then {
translated {
source-pool public;
translation-type source napt-44;
}
}
}
}
}
service-set Firewall-Set {
stateful-firewall-rules Rule1;
stateful-firewall-rules Rule2;
nat-rules Private-Public;
ids-rules Attacks;
interface-service {
service-interface sp-1/0/0;
}
}
}
applications {
application ICMP {
application-protocol icmp;
}
application FTP {
application-protocol ftp;
destination-port ftp;
}
application-set Applications {
application ICMP;
application FTP;
}
}
Konfigurieren von Standard-Timeout-Einstellungen für Serviceschnittstellen
Sie können globale Standardeinstellungen für bestimmte Timer angeben, die für die gesamte Schnittstelle gelten. Es gibt drei Aussagen dieses Typs:
inactivity-timeout— Legt den Timeout-Zeitraum für festgelegte Datenströme fest, nach dem diese nicht mehr gültig sind.open-timeout– Legt den Timeout-Zeitraum für die Einrichtung der TCP-Sitzung (Transmission Control Protocol) für die Verwendung mit SYN-Cookie-Abwehrmaßnahmen gegen Eindringung im Netzwerk fest.close-timout– Legt den Timeout-Zeitraum für den Abriss der TCP-Sitzung (Transmission Control Protocol) fest.
Um eine Einstellung für den Timeout-Zeitraum in Inaktivität zu konfigurieren, fügen Sie die inactivity-timeout Anweisung auf [edit interfaces interface-name services-options] Hierarchieebene ein:
[edit interfaces interface-name services-options] inactivity-timeout seconds;
Der Standardwert ist 30 Sekunden. Der Bereich der möglichen Werte beträgt 4 bis 86.400 Sekunden. Jeder Wert, den Sie in der Anwendungsprotokolldefinition konfigurieren, überschreibt den hier angegebenen Wert. weitere Informationen finden Sie unter Konfigurieren von Anwendungseigenschaften.
Um eine Einstellung für den Timeout-Zeitraum für die TCP-Sitzungseinrichtung zu konfigurieren, fügen Sie die open-timeout Anweisung auf Hierarchieebene [edit interfaces interface-name services-options] ein:
[edit interfaces interface-name services-options] open-timeout seconds;
Der Standardwert ist 5 Sekunden. Der Bereich der möglichen Werte beträgt 4 bis 224 Sekunden. Jeder Wert, den Sie in der IDS-Definition (Intrusion Detection Service) konfigurieren, überschreibt den hier angegebenen Wert. weitere Informationen finden Sie unter Konfigurieren von IDS-Regeln auf einer MS-DPC.
Um eine Einstellung für den Timeout-Zeitraum der TCP-Sitzung zu konfigurieren, fügen Sie die close-timeout Anweisung auf [edit interfaces interface-name services-options] Hierarchieebene ein:
[edit interfaces interface-name services-options] close-timeout seconds;
Der Standardwert ist 1 Sekunde. Der Bereich der möglichen Werte beträgt 2 bis 300 Sekunden.
Verwendung von Keep-Alive-Nachrichten zur besseren Kontrolle von TCP-Inaktivitäts-Timeouts
Keep-Alive-Meldungen werden automatisch generiert, um Tcp-Inaktivitäts-Timeouts zu verhindern. Die Standardanzahl von Keep-Alive-Nachrichten ist 4. Sie können jedoch die Anzahl der Keep-Alive-Nachrichten konfigurieren, indem Sie die tcp-tickles Anweisung auf Hierarchieebene [edit interaces interface-name service-options] eingeben.
Wenn ein Timeout für einen bidirektionalen TCP-Fluss generiert wird, werden Keep-Alive-Pakete gesendet, um den Timer zurückzusetzen. Wenn die Anzahl der aufeinanderfolgenden Keep-Alive-Pakete, die in einem Datenstrom gesendet werden, die Standard- oder konfigurierte Begrenzung erreicht, wird die Konversation gelöscht. Es gibt mehrere mögliche Szenarien, abhängig von der Einstellung der inactivity-timer standardbasierten oder konfigurierten maximalen Anzahl von Keep-Alive-Nachrichten.
Wenn der konfigurierte Wert von Keep-Alive-Nachrichten null und
inactivity-timeoutNICHT konfiguriert ist (in diesem Fall wird der Standard-Timeout-Wert von 30 verwendet), werden keine Keep-Alive-Pakete gesendet. Die Konversation wird gelöscht, wenn ein Datenstrom in der Konversation länger als 30 Sekunden untätig ist.Wenn der konfigurierte Wert der Keep-Alive-Nachrichten null und die
inactivity-timeoutkonfiguriert ist, werden keine Keep-Alive-Pakete gesendet und die Konversation wird gelöscht, wenn ein Datenstrom in der Konversation mehr als der konfigurierte Timeoutwert leer steht.Wenn die standardmäßige oder konfigurierte maximale Anzahl von Keep-Alive-Nachrichten eine positive ganze Zahl ist und alle Datenströme in einer Konversation mehr als der Standard- oder konfigurierte Wert für
inactivity-timeoutKeep-Alive-Pakete gesendet werden. Wenn Hosts nicht auf die konfigurierte Anzahl aufeinander folgender Keep-Alive-Pakete reagieren, wird die Konversation gelöscht. Das Intervall zwischen Keep-Alive-Paketen beträgt 1 Sekunde. Wenn der Host jedoch ein ACK-Paket zurücksendet, wird der entsprechende Datenstrom aktiviert, und Keep-Alive-Pakete werden erst gesendet, wenn der Datenstrom wieder inaktiv ist.
Siehe auch
Konfigurieren der Systemprotokollierung für Serviceschnittstellen
Sie geben Eigenschaften an, die steuern, wie Systemprotokollmeldungen für die Gesamte Schnittstelle generiert werden. Wenn Sie für dieselben Eigenschaften auf [edit services service-set service-set-name] Hierarchieebene unterschiedliche Werte konfigurieren, überschreiben die Servicesatzwerte die für die Schnittstelle konfigurierten Werte. Weitere Informationen zur Konfiguration von Servicesatzeigenschaften finden Sie unter Konfigurieren der Systemprotokollierung für Servicesätze.
Ab Junos OS Version 14.2R5, 15.1R3 und 16.1R1 können Sie für Multiservices-Schnittstellen (ms-) die Systemprotokollierung für PCP und ALGs nicht konfigurieren, indem Sie die Pcp-logs- und alg-logs-Anweisungen auf der Hierarchieebene [services service-set-service-set-name syslog host hostname class] einbinden. Wenn Sie versuchen, eine Konfiguration zu bestätigen, die die Optionen pcp-logs und alg-logs zur Definition der Systemprotokollierung für PCP und ALGs für ms-Schnittstellen enthält, wird eine Fehlermeldung angezeigt.
Um standardbasierte Systemprotokollierungswerte für die [edit interfaces interface-name services-options] gesamte Schnittstelle zu konfigurieren, fügen Sie die syslog Anweisung auf Hierarchieebene ein:
[edit interfaces interface-name services-options] syslog { host hostname { services severity-level; facility-override facility-name; log-prefix prefix-value; port port-number; } }
Konfigurieren Sie die host Anweisung mit einem Hostnamen oder einer IP-Adresse, die den Zielserver des Systemprotokolls angibt. Der Hostname local leitet Systemprotokollmeldungen an die Routing-Engine. Für externe Systemprotokollserver muss der Hostname von derselben Routing-Instanz aus erreichbar sein, an die das ursprüngliche Datenpaket (das die Sitzungseinrichtung ausgelöst hat) geliefert wird. Sie können nur einen Hostnamen für die Systemprotokollierung angeben.
Ab Junos OS Version 17.4R1 können Sie bis zu maximal vier Systemprotokollserver (kombination aus lokalen Systemprotokoll-Hosts und Remote-Systemprotokollsammlern) für jeden Servicesatz für ms-Schnittstelle in der [edit interfaces interface-name services-options] Hierarchie konfigurieren.
Tabelle 2 listet die Schweregraden auf, die Sie in Konfigurationsanweisungen auf [edit interfaces interface-name services-options syslog host hostname] Hierarchieebene angeben können. Die Werte von emergency durch info sind in der Reihenfolge von höchster Schweregrad (größter Einfluss auf die Funktion) bis zum niedrigsten.
Schweregrad |
Beschreibung |
|---|---|
|
Umfasst alle Schweregraden |
|
Systempanik oder ein anderer Zustand, der dazu führt, dass der Router nicht mehr funktioniert |
|
Bedingungen, die sofortige Korrektur erfordern, wie z. B. eine beschädigte Systemdatenbank |
|
Kritische Bedingungen wie Festplattenfehler |
|
Fehlerzustände, die im Allgemeinen weniger schwerwiegende Folgen haben als Fehler in der Notfall-, Alarm- und kritischen Ebene |
|
Bedingungen, die eine Überwachung rechtfertigen |
|
Bedingungen, die keine Fehler sind, aber eine besondere Behandlung rechtfertigen können |
|
Ereignisse oder Nicht-Terrorbedingungen von Interesse |
Wir empfehlen, den Schweregrad der Systemprotokollierung während des normalen Betriebs auf error festzulegen. Um die PIC-Ressourcennutzung zu überwachen, legen Sie die Ebene auf warning. Um Informationen über einen Eindringungsangriff zu notice erfassen, wenn ein Eindringungssystemfehler erkannt wird, legen Sie den Wert für eine bestimmte Schnittstelle fest. Legen Sie zum Debuggen einer Konfiguration oder Protokollfunktionen von Network Address Translation (NAT) die Stufe auf info.
Weitere Informationen zu Systemprotokollmeldungen finden Sie im Systemprotokoll-Explorer.
Um einen bestimmten Facility-Code für die gesamte Protokollierung am angegebenen Systemprotokoll-Host zu verwenden, fügen Sie die facility-override Anweisung auf Hierarchieebene [edit interfaces interface-name services-options syslog host hostname] ein:
[edit interfaces interface-name services-options] facility-override facility-name;
Zu den unterstützten Einrichtungen gehören authorization, daemon, , ftp, kernel, userund local0 durch local7.
Um ein Textpräfix für die gesamte Protokollierung an diesem Systemprotokollhost anzugeben, fügen Sie die log-prefix Anweisung auf [edit interfaces interface-name services-options syslog host hostname] Hierarchieebene ein:
[edit interfaces interface-name services-options] log-prefix prefix-value;
Siehe auch
Konfigurieren des TLS Syslog Protocol auf MS-MPC und MS-MIC
- Transport Layer Security (TLS) – Überblick
- TLS Transport Protocol for Syslog Messages Configuration – Übersicht
- Konfigurieren von TCP/TLS für Syslog-Meldungen
Transport Layer Security (TLS) – Überblick
Ab Junos OS Version 19.1R1 können Sie TLS (Transport Layer Security) für Syslog-Nachrichten konfigurieren, die von den Services generiert werden, die auf den MS-MPC- oder MS-MIC-Servicekarten in einem MX-Router ausgeführt werden. Die Services können einer der folgenden sein:
Junos Address Aware (früher als NAT-Feaures bezeichnet)
Junos VPN Site Secure (früher als IPsec-Funktionen bezeichnet)
Junos Network Secure (früher als Stateful Firewall-Funktionen bezeichnet)
Transport Layer Security (TLS) ist ein Protokoll auf Anwendungsebene, das Verschlüsselungstechnologie für das Internet bereitstellt. TLS setzt für diese Sicherheitsstufe auf Zertifikate und private/öffentliche Schlüsselaustauschpaare. Es ist das am häufigsten verwendete Sicherheitsprotokoll für Anwendungen, bei denen Daten sicher über ein Netzwerk ausgetauscht werden müssen, wie z. B. Dateiübertragungen, VPN-Verbindungen, Instant Messaging und Voice over IP (VoIP).
Das TLS-Protokoll wird für den Austausch von Zertifikaten, die gegenseitige Authentifizierung und das Aushandeln von Chiffren verwendet, um den Strom vor potenziellen Manipulationen und Abhören zu schützen. TLS wird manchmal als Secure Sockets Layer (SSL) bezeichnet. TLS und SSL sind nicht kompatibel, obwohl TLS derzeit eine gewisse Abwärtskompatibilität bietet.
- Vorteile von TLS
- Drei wesentliche Services von TLS
- TLS-Handshake
- Verschlüsselung des Syslog-Datenverkehrs mit TLS
- TLS-Versionen
Vorteile von TLS
TLS gewährleistet die sichere Datenübertragung zwischen einem Client und einem Server durch eine Kombination aus Datenschutz, Authentifizierung, Vertraulichkeit und Datenintegrität.
Drei wesentliche Services von TLS
Das TLS-Protokoll ist darauf ausgelegt, drei wichtige Services für die darüber ausgeführten Anwendungen bereitzustellen: Verschlüsselung, Authentifizierung und Datenintegrität.
Verschlüsselung: Um einen kryptografisch sicheren Datenkanal einzurichten, müssen Server und Client vereinbaren, welche Cipher Suites verwendet werden und welche Schlüssel zur Verschlüsselung der Daten verwendet werden. Das TLS-Protokoll gibt eine genau definierte Handshake-Sequenz für diesen Austausch an. TLS verwendet Kryptografie mit öffentlichen Schlüsseln, die es dem Client und dem Server ermöglicht, einen gemeinsam genutzten geheimen Schlüssel auszuhandeln, ohne sich vorher darüber zu machen, und zwar über einen unverschlüsselten Kanal.
Authentifizierung: Als Teil des TLS-Handshakes ermöglicht das Protokoll sowohl dem Server als auch dem Client, ihre Identität zu authentifizieren. Implizite Vertrauensstellungen zwischen dem Client und dem Server (weil der Client das vom Server generierte Zertifikat akzeptiert) ist ein wichtiger Aspekt von TLS. Es ist äußerst wichtig, dass die Serverauthentifizierung nicht kompromittiert wird. in der Realität gibt es jedoch selbstsignierte Zertifikate und Zertifikate mit Anomalien im Überfluss. Anomalien können abgelaufene Zertifikate, Instanzen von gemeinsamem Namen, die nicht mit einem Domänennamen übereinstimmen, usw. umfassen.
Integrität: Mit vorhandener Verschlüsselung und Authentifizierung übernimmt das TLS-Protokoll einen Mechanismus für die Einrahmung von Nachrichten und signiert jede Nachricht mit einem Message Authentication Code (MAC). Der MAC-Algorithmus übernimmt die effektive Prüfsumme, und die Schlüssel werden zwischen dem Client und dem Server ausgehandelt.
TLS-Handshake
Jede TLS-Sitzung beginnt mit einem Handshake, bei dem Client und Server sich auf den spezifischen Sicherheitsschlüssel und die Verschlüsselungsalgorithmen einigen, die für diese Sitzung verwendet werden sollen. Zu diesem Zeitpunkt authentifiziert der Client auch den Server. Optional kann der Server den Client authentifizieren. Sobald der Handshake abgeschlossen ist, kann die Übertragung von verschlüsselten Daten beginnen.
Verschlüsselung des Syslog-Datenverkehrs mit TLS
Das TLS-Protokoll stellt sicher, dass die Syslog-Nachrichten sicher über das Netzwerk gesendet und empfangen werden. TLS verwendet Zertifikate zur Authentifizierung und Verschlüsselung der Kommunikation. Der Client authentifiziert den Server, indem er sein Zertifikat und seinen öffentlichen Schlüssel anfordert. Optional kann der Server auch ein Zertifikat vom Client anfordern, so dass auch eine gegenseitige Authentifizierung möglich ist.
Ein Zertifikat auf dem Server, das den Server identifiziert, und das vom Server ausgestellte Zertifikat der Zertifizierungsstelle (Certificate of Certificate Authority, CA) müssen beim Client für TLS zur Verfügung stehen, um den Syslog-Datenverkehr zu verschlüsseln.
Für die gegenseitige Authentifizierung von Client und Server muss ein Zertifikat mit dem Client, das den Client identifiziert, und das vom Client ausgestellte Zertifikat der Zertifizierungsstelle auf dem Server verfügbar sein. Die gegenseitige Authentifizierung stellt sicher, dass der syslog-Server Protokollnachrichten nur von autorisierten Clients akzeptiert.
TLS wird als sicherer Transport verwendet, um allen unten aufgeführten primären Bedrohungen für Syslog entgegenzuwirken:
Vertraulichkeit zur Abwehr der Inhalte der Nachricht.
Integritätsprüfung, um Änderungen an einer Nachricht Hop-für-Hop-Basis entgegenzuwirken.
Server oder gegenseitige Authentifizierung zur Abwehr von Maskerade.
TLS-Versionen
Im Folgenden sind die Versionen von TLS:
TLS-Version 1.0 – Bietet sichere Kommunikation über Netzwerke durch Die Bereitstellung von Datenschutz und Datenintegrität zwischen kommunizierenden Anwendungen
TLS-Version 1.1: Diese erweiterte Version von TLS bietet Schutz vor Cipher-Block Chaining (CBC)-Angriffen.
TLS-Version 1.2 — Diese erweiterte Version von TLS bietet eine verbesserte Flexibilität für die Aushandlung kryptografischer Algorithmen.
TLS Transport Protocol for Syslog Messages Configuration – Übersicht
Ab Junos OS Version 19.1R1 können Sie einen Router der MX-Serie so konfigurieren, dass Tls (Transport Layer Security) für Syslogmeldungen verwendet wird, die von Services generiert werden, die auf den MS-MPC- oder MS-MIC-Servicekarten in einem Router der MX-Serie ausgeführt werden.
Die folgenden Servicepakete sind auf MS-MICs und MS-MPCs vorinstalliert und vorkonfiguriert:
Junos Traffic Vision (früher als Jflow bezeichnet)
Junos Address Aware (früher als NAT-Funktionen bezeichnet)
Junos VPN Site Secure (früher als IPsec-Funktionen bezeichnet)
Junos Network Secure (früher als Stateful Firewall-Funktion bezeichnet)
Junos Services Crypto Base PIC-Paket
Junos Services Application Level Gateways
Sie können für jeden Servicesatz maximal vier Syslog-Server konfigurieren und verschlüsselte Daten an die Server senden.
Syslog-Meldungen werden über eine dedizierte Verbindung gesendet, die für eine bestimmte Reihe eindeutiger Konfigurationsparameter erstellt wurde:
Quell-IP-Adresse
Ziel-IP-Adresse (TCP/TLS-Server)
Hafen
SSL-Profilname (für TLS-Verbindung)
Hinweis:Wenn das ssl-profile nicht unter der tcp-log-Hierarchie konfiguriert ist, handelt es sich um einen TCP-Transport ohne TLS.
Wenn es mehrere Servicesätze mit der TCP/TLS-Protokollierungskonfiguration mit denselben Parametern wie oben gibt, teilen sich die Protokolle, die aus den Sitzungen all dieser Servicesätze generiert werden, dieselbe Verbindung.
Diese Funktion unterstützt sowohl IPv4 als auch IPv6.
Die konfigurierte TCP/TLS-Verbindung bleibt so lange bestehen, bis die Konfiguration vorhanden ist, auch wenn keine Protokollierungsereignisse auftreten.
Unterstützung für die TCP/TLS-Sylog-Konfiguration wird nur für eine sichere und zuverlässige Protokollierung auf der Data Plane bereitgestellt.
Für Aggregated Multi Service (AMS) mit mehreren aktiven Mitgliedern erstellt jeder Member eine eigene TCP/TLS-Verbindung, und syslogs, die von jedem Member-PIC generiert werden, werden über ihre einzigartigen Verbindungen gesendet.
Konfigurieren von TCP/TLS für Syslog-Meldungen
Sie können die TCP/TLS-Transportprotokolle verwenden, um Syslog-Nachrichten zuverlässig und sicher an externe Syslog-Server zu senden.
So konfigurieren Sie die TCP/TLS-Protokolle für Syslog-Meldungen: