Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Fehlerbehebung bei der AWS Site-to-Site VPN Konnektivität mit einem Juniper JunOS-Kunden-Gateway-Gerät
Wenn Sie Probleme mit der Konnektivität eines Kunden-Gateway-Geräts von Juniper beheben, sollten Sie vier Dinge berücksichtigen: IKE IPsec, Tunnel und BGP. Sie können zwar in beliebiger Reihenfolge nach Fehlern in diesen drei Bereichen suchen, wir empfehlen jedoch, mit IKE (am Ende des Netzwerk-Stacks) zu beginnen und sich hochzuarbeiten.
## IKE
Verwenden Sie den folgenden -Befehl. Die Antwort zeigt ein Kunden-Gateway-Gerät mit korrekt konfiguriertem IKE.
```
user@router> show security ike security-associations
```
```
Index Remote Address State Initiator cookie Responder cookie Mode
4 72.21.209.225 UP c4cd953602568b74 0d6d194993328b02 Main
3 72.21.209.193 UP b8c8fb7dc68d9173 ca7cb0abaedeb4bb Main
```
Es sollte mindestens eine Zeile mit einer Remote-Adresse des in den Tunneln angegebenen Remote-Gateways angezeigt werden. Der `State` sollte `UP` sein. Wenn kein Eintrag vorhanden ist oder ein anderer Zustand (z. B. `DOWN`) angezeigt wird, ist IKE nicht korrekt konfiguriert.
Wenn Sie weitere Informationen zur Fehlersuche benötigen, aktivieren Sie die IKE-Trace-Optionen (wie in den Beispielkonfigurationsinformationen empfohlen). Führen Sie dann den folgenden Befehl aus, um verschiedene Debugging-Meldungen auf dem Bildschirm auszugeben.
```
user@router> monitor start kmd
```
Mit dem folgenden Befehl können Sie die gesamte Protokolldatei von einem externen Host abrufen.
```
scp username@router.hostname:/var/log/kmd
```
## IPsec
Verwenden Sie den folgenden -Befehl. In der Antwort wird ein Kunden-Gateway-Gerät angezeigt, das korrekt IPsec konfiguriert ist.
```
user@router> show security ipsec security-associations
```
```
Total active tunnels: 2
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131073 72.21.209.225 500 ESP:aes-128/sha1 df27aae4 326/ unlim - 0
>131073 72.21.209.225 500 ESP:aes-128/sha1 5de29aa1 326/ unlim - 0
<131074 72.21.209.193 500 ESP:aes-128/sha1 dd16c453 300/ unlim - 0
>131074 72.21.209.193 500 ESP:aes-128/sha1 c1e0eb29 300/ unlim - 0
```
Sie sollten mindestens zwei Zeilen pro Gateway-Adresse (entsprechend dem Remote-Gateway) sehen. Beachten Sie die Einfügezeichen am Beginn jeder Zeile (< >), die die Richtung des Datenverkehrs für den jeweiligen Eintrag angeben. Für die Ausgabe gibt es eigene Zeilen für eingehenden Datenverkehr ("<", Datenverkehr vom Virtual Private Gateway zu diesem Kunden-Gateway) und ausgehenden Datenverkehr (">").
Wenn Sie weitere Informationen zur Fehlersuche benötigen, aktivieren Sie die IKE-Trace-Optionen (weitere Informationen finden Sie im vorherigen Abschnitt zu IKE).
## Tunnel
Überprüfen Sie zunächst noch einmal, ob die benötigten Firewall-Regeln konfiguriert sind. Eine Liste der Regeln finden Sie unter [Firewall-Regeln für ein AWS Site-to-Site VPN Kunden-Gateway-Gerät](FirewallRules.md).
Wenn die Firewall-Regeln korrekt eingerichtet sind, können Sie mithilfe des folgenden Befehls mit der Fehlersuche fortfahren.
```
user@router> show interfaces st0.1
```
```
Logical interface st0.1 (Index 70) (SNMP ifIndex 126)
Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel
Input packets : 8719
Output packets: 41841
Security: Zone: Trust
Allowed host-inbound traffic : bgp ping ssh traceroute
Protocol inet, MTU: 9192
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 169.254.255.0/30, Local: 169.254.255.2
```
Stellen Sie sicher, dass `Security: Zone` korrekt konfiguriert ist und die Adresse `Local` mit der internen Adresse des Kunden-Gateway-Geräte-Tunnels übereinstimmt.
Führen Sie nun den folgenden Befehl aus und ersetzen Sie dabei `169.254.255.1` durch die interne IP-Adresse des Virtual Private Gateways. Ihre Ergebnisse sollten etwa wie folgt aussehen.
```
user@router> ping 169.254.255.1 size 1382 do-not-fragment
```
```
PING 169.254.255.1 (169.254.255.1): 1410 data bytes
64 bytes from 169.254.255.1: icmp_seq=0 ttl=64 time=71.080 ms
64 bytes from 169.254.255.1: icmp_seq=1 ttl=64 time=70.585 ms
```
Fahren Sie mit der Fehlersuche in der Konfiguration fort.
## BGP
Führen Sie den folgenden Befehl aus.
```
user@router> show bgp summary
```
```
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
169.254.255.1 7224 9 10 0 0 1:00 1/1/1/0 0/0/0/0
169.254.255.5 7224 8 9 0 0 56 0/1/1/0 0/0/0/0
```
Führen Sie zur weiteren Fehlersuche den folgenden Befehl aus; ersetzen Sie dabei `169.254.255.1` durch die interne IP-Adresse des Virtual Private Gateways.
```
user@router> show bgp neighbor 169.254.255.1
```
```
Peer: 169.254.255.1+179 AS 7224 Local: 169.254.255.2+57175 AS 65000
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ EXPORT-DEFAULT ]
Options:
Holdtime: 30 Preference: 170 Local AS: 65000 Local System AS: 0
Number of flaps: 0
Peer ID: 169.254.255.1 Local ID: 10.50.0.10 Active Holdtime: 30
Keepalive Interval: 10 Peer index: 0
BFD: disabled, down
Local Interface: st0.1
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 7224)
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 4 Sent 8 Checked 4
Input messages: Total 24 Updates 2 Refreshes 0 Octets 505
Output messages: Total 26 Updates 1 Refreshes 0 Octets 582
Output Queue[0]: 0
```
Hier sollten `Received prefixes` und `Advertised prefixes` beide mit "1" aufgelistet sein. Diese Werte befinden sich im Abschnitt `Table inet.0`.
Wenn `State` nicht `Established` ist, finden Sie unter `Last State` und `Last Error` detaillierte Informationen zur Fehlerbehebung.
Wenn BGP-Peering aktiviert ist, überprüfen Sie, ob Ihr Kunden-Gateway-Gerät die Standardroute (0.0.0.0/0) an die VPC sendet.
```
user@router> show route advertising-protocol bgp 169.254.255.1
```
```
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 Self I
```
Stellen Sie außerdem sicher, dass Sie das Präfix Ihrer VPC vom Virtual Private Gateway empfangen.
```
user@router> show route receive-protocol bgp 169.254.255.1
```
```
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.110.0.0/16 169.254.255.1 100 7224 I
```