기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# AWS Site-to-Site VPN 고객 게이트웨이 디바이스 문제 해결
고객 게이트웨이 디바이스 문제를 해결할 때는 구조화된 접근 방식을 사용하는 것이 중요합니다. 이 섹션의 처음 두 주제에서는 각각 동적 라우팅(BGP 활성화됨)에 대해 구성된 디바이스와 정적 라우팅(BGP 활성화되지 않음)에 대해 구성된 디바이스를 사용할 때 문제를 해결하기 위한 일반화된 흐름도를 제공합니다. 다음 주제는 Cisco, Juniper 및 Yamaha 고객 게이트웨이 디바이스에 대한 디바이스별 문제 해결 가이드입니다.
이 섹션의 항목 외에도 [AWS Site-to-Site VPN 로그](monitoring-logs.md) 섹션을 사용하면 VPN 연결 문제를 해결하는 데 큰 도움이 될 수 있습니다. 일반적인 테스트 지침은 [AWS Site-to-Site VPN 연결 테스트](HowToTestEndToEnd_Linux.md) 섹션을 참조하세요.
**Topics**
+ [BGP를 사용하는 디바이스](Generic_Troubleshooting.md)
+ [BGP를 사용하지 않는 디바이스](Generic_Troubleshooting_noBGP.md)
+ [Cisco ASA](Cisco_ASA_Troubleshooting.md)
+ [Cisco IOS](Cisco_Troubleshooting.md)
+ [BGP를 사용하지 않는 Cisco IOS](Cisco_Troubleshooting_NoBGP.md)
+ [Juniper JunOS](Juniper_Troubleshooting.md)
+ [Juniper ScreenOS](Juniper_ScreenOs_Troubleshooting.md)
+ [Yamaha](Yamaha_Troubleshooting.md)
**추가 리소스**
+ [Amazon VPC 포럼](https://repost.aws/tags/TATGuEiYydTVCPMhSnXFN6gA/amazon-vpc)
# Border Gateway 프로토콜 사용 시 AWS Site-to-Site VPN 연결 문제 해결
다음 다이어그램과 표에는 BGP(Border Gateway Protocol)를 사용하는 고객 게이트웨이 디바이스의 문제 해결을 위한 일반 지침이 나와 있습니다. 또한 디바이스의 디버그 기능을 활성화하는 것이 좋습니다. 세부 정보는 게이트웨이 디바이스 공급업체에 문의하십시오.
![\[일반적인 고객 게이트웨이 디바이스 문제 해결을 위한 순서도\]](http://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-diagram.png)
| | |
| --- |--- |
| IKE | IKE 보안 연결이 존재하는지 확인합니다. IKE 보안 연결은 IPsec 보안 연결 설정에 사용되는 키 교환에 필요합니다. 아무런 IKE 보안 연결도 존재하지 않을 경우 IKE 구성 설정을 검토하십시오. 구성 파일에 표시된 것처럼 암호화, 인증, PFS(perfect-forward-secrecy) 및 모드 파라미터를 구성해야 합니다. IKE 보안 연결이 존재하는 경우 ‘IPsec’로 이동합니다. |
| IPsec | IPsec 보안 연결(SA)이 존재하는지 확인합니다. IPsec SA는 터널 자체입니다. 고객 게이트웨이 디바이스를 쿼리하여 IPsec SA가 활성 상태인지 확인합니다. 고객 게이트웨이 구성에 표시된 것처럼 암호화, 인증, PFS(perfect-forward-secrecy) 및 모드 파라미터를 구성해야 합니다. IPsec SA가 없으면 IPsec 구성을 검토합니다. IPsec SA가 있는 경우 '터널'로 이동합니다. |
| 터널 | 필요한 방화벽 규칙이 설정되어 있는지 확인합니다(규칙 목록은 [AWS Site-to-Site VPN 고객 게이트웨이 디바이스에 대한 방화벽 규칙](FirewallRules.md) 참조). 설정되어 있으면 앞으로 이동합니다. 터널을 통한 IP 연결이 있는지 확인합니다. 터널의 각 사이드에는 구성 파일에 지정되어 있는 것과 같은 IP 주소가 있습니다. 가상 프라이빗 게이트웨이 주소는 BGP 인접 라우터 주소로 사용되는 주소입니다. 고객 게이트웨이 디바이스에서 이 주소를 ping하여 IP 트래픽이 올바로 암호화 및 해독되는지 확인합니다. Ping에 실패하면 터널 인터페이스 구성을 검토하여 올바른 IP 주소가 구성되어 있는지 확인합니다. Ping에 성공하면 ‘BGP’로 이동합니다. |
| BGP | BGP 피어링 세션이 활성 상태인지 확인합니다. 각 터널에 대해 다음을 수행합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/Generic_Troubleshooting.html) 터널이 이 상태에 있지 않으면 BGP 구성을 검토하십시오. BGP 피어링이 설정되면 접두사를 수신하여 알리고 터널이 올바르게 구성됩니다. 두 터널 모두 이 상태여야 합니다. |
# Border Gateway 프로토콜이 없는 AWS Site-to-Site VPN 연결 문제 해결
다음 다이어그램과 표에는 BGP(Border Gateway Protocol)를 사용하지 않는 고객 게이트웨이 디바이스의 문제 해결을 위한 일반 지침이 나와 있습니다. 또한 디바이스의 디버그 기능을 활성화하는 것이 좋습니다. 세부 정보는 게이트웨이 디바이스 공급업체에 문의하십시오.
![\[일반적인 고객 게이트웨이 문제 해결을 위한 순서도\]](http://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-nobgp-diagram.png)
| | |
| --- |--- |
| IKE | IKE 보안 연결이 존재하는지 확인합니다. IKE 보안 연결은 IPsec 보안 연결 설정에 사용되는 키 교환에 필요합니다. 아무런 IKE 보안 연결도 존재하지 않을 경우 IKE 구성 설정을 검토하십시오. 구성 파일에 표시된 것처럼 암호화, 인증, PFS(perfect-forward-secrecy) 및 모드 파라미터를 구성해야 합니다. IKE 보안 연결이 존재하는 경우 ‘IPsec’로 이동합니다. |
| IPsec | IPsec 보안 연결(SA)이 존재하는지 확인합니다. IPsec SA는 터널 자체입니다. 고객 게이트웨이 디바이스를 쿼리하여 IPsec SA가 활성 상태인지 확인합니다. 고객 게이트웨이 구성에 표시된 것처럼 암호화, 인증, PFS(perfect-forward-secrecy) 및 모드 파라미터를 구성해야 합니다. IPsec SA가 없으면 IPsec 구성을 검토합니다. IPsec SA가 있는 경우 '터널'로 이동합니다. |
| 터널 | 필요한 방화벽 규칙이 설정되어 있는지 확인합니다(규칙 목록은 [AWS Site-to-Site VPN 고객 게이트웨이 디바이스에 대한 방화벽 규칙](FirewallRules.md) 참조). 설정되어 있으면 앞으로 이동합니다. 터널을 통한 IP 연결이 있는지 확인합니다. 터널의 각 사이드에는 구성 파일에 지정되어 있는 것과 같은 IP 주소가 있습니다. 가상 프라이빗 게이트웨이 주소는 BGP 인접 라우터 주소로 사용되는 주소입니다. 고객 게이트웨이 디바이스에서 이 주소를 ping하여 IP 트래픽이 올바로 암호화 및 해독되는지 확인합니다. Ping에 실패하면 터널 인터페이스 구성을 검토하여 올바른 IP 주소가 구성되어 있는지 확인합니다. Ping이 성공하면 '정적 경로'로 이동합니다. |
| 정적 경로 | 각 터널에 대해 다음을 수행합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/Generic_Troubleshooting_noBGP.html) 터널이 이 상태가 아닌 경우 디바이스 구성을 검토하십시오. 두 터널 모두 이 상태인지 확인하면 모두 완료된 것입니다. |
# Cisco ASA 고객 게이트웨이 디바이스와의 AWS Site-to-Site VPN 연결 문제 해결
Cisco 고객 게이트웨이 디바이스의 연결 문제를 해결할 때는 IKE, IPsec 및 라우팅을 고려하십시오. 이런 영역의 문제는 어떤 순서로든 해결할 수 있지만, (네트워크 스택의 맨 아래에 있는) IKE부터 시작해서 위로 올라가는 것이 좋습니다.
**중요**
일부 Cisco ASA는 액티브/스탠바이 모드만 지원합니다. 이런 Cisco ASA를 사용할 때는 액티브 터널이 한 번에 한 개만 있을 수 있습니다. 첫 번째 터널을 사용할 수 없을 경우에만 다른 스탠바이 터널이 활성화됩니다. 스탠바이 터널은 사용자의 로그 파일에 다음 오류를 발생시킬 수 있는데, 무시해도 됩니다. `Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside`
## IKE
다음 명령을 사용합니다. 응답에는 IKE가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
ciscoasa# show crypto isakmp sa
```
```
Active SA: 2
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2
1 IKE Peer: AWS_ENDPOINT_1
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
```
터널에 지정된 원격 게이트웨이의 `src` 값이 포함된 줄이 한 개 이상 나타날 것입니다. `state` 값은 `MM_ACTIVE`이고 `status`는 `ACTIVE`여야 합니다. 항목이 없거나 또 다른 상태의 항목이 있다는 것은 IKE가 올바로 구성되지 않았음을 나타냅니다.
추가적인 문제 해결을 위해서는 다음 명령을 실행하여 진단 정보를 제공하는 로그 메시지를 활성화합니다.
```
router# term mon
router# debug crypto isakmp
```
디버깅을 비활성화하려면 다음 명령을 사용합니다.
```
router# no debug crypto isakmp
```
## IPsec
다음 명령을 사용합니다. 응답에는 IPsec가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
ciscoasa# show crypto ipsec sa
```
```
interface: outside
Crypto map tag: VPN_crypto_map_name, seq num: 2, local addr: 172.25.50.101
access-list integ-ppe-loopback extended permit ip any vpc_subnet subnet_mask
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (vpc_subnet/subnet_mask/0/0)
current_peer: integ-ppe1
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 172.25.50.101, remote crypto endpt.: AWS_ENDPOINT_1
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: 6D9F8D3B
current inbound spi : 48B456A6
inbound esp sas:
spi: 0x48B456A6 (1219778214)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1
sa timing: remaining key lifetime (kB/sec): (4374000/3593)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0x6D9F8D3B (1839172923)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1
sa timing: remaining key lifetime (kB/sec): (4374000/3593)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
```
각 터널 인터페이스에 대해 `inbound esp sas` 및 `outbound esp sas`가 모두 나타나야 합니다. 이는 SA가 나열되고(예: `spi: 0x48B456A6`) IPsec가 올바로 구성되어 있음을 가정할 때의 얘기입니다.
Cisco ASA에서 IPsec은 흥미로운 트래픽(암호화해야하는 트래픽)이 전송된 후에만 나타납니다. IPsec을 항상 활성 상태로 유지하려면 SLA 모니터를 구성하는 것이 좋습니다. SLA 모니터는 관심 트래픽을 계속 보내어 IPsec을 활성 상태로 유지합니다.
또한 다음 ping 명령을 사용하여 IPsec가 협상을 시작하고 상위 스택으로 이동하도록 강제할 수도 있습니다.
```
ping ec2_instance_ip_address
```
```
Pinging ec2_instance_ip_address with 32 bytes of data:
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Ping statistics for 10.0.0.4:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
```
추가적인 문제 해결을 위해서는 다음 명령을 사용하여 디버깅을 활성화합니다.
```
router# debug crypto ipsec
```
디버깅을 비활성화하려면 다음 명령을 사용합니다.
```
router# no debug crypto ipsec
```
## 라우팅
터널의 다른 쪽 종단을 ping합니다. 이것이 작동하는 경우 IPsec을 설정해야 합니다. Ping이 작동하지 않으면 액세스 목록을 확인하고 이전 IPsec 단원을 참조하십시오.
인스턴스에 연결할 수 없는 경우 다음 정보를 확인하십시오.
1. 액세스 목록이 크립토 맵과 연결된 트래픽을 허용하도록 구성되어 있는지 확인합니다.
다음 명령을 사용하여 확인할 수 있습니다.
```
ciscoasa# show run crypto
```
```
crypto ipsec transform-set transform-amzn esp-aes esp-sha-hmac
crypto map VPN_crypto_map_name 1 match address access-list-name
crypto map VPN_crypto_map_name 1 set pfs
crypto map VPN_crypto_map_name 1 set peer AWS_ENDPOINT_1 AWS_ENDPOINT_2
crypto map VPN_crypto_map_name 1 set transform-set transform-amzn
crypto map VPN_crypto_map_name 1 set security-association lifetime seconds 3600
```
1. 다음 명령을 사용하여 액세스 목록을 확인합니다.
```
ciscoasa# show run access-list access-list-name
```
```
access-list access-list-name extended permit ip any vpc_subnet subnet_mask
```
1. 이 액세스 목록이 정확한지 확인합니다. 다음 예시 액세스 목록에서는 VPC 서브넷 10.0.0.0/16에 대한 모든 내부 트래픽을 허용합니다.
```
access-list access-list-name extended permit ip any 10.0.0.0 255.255.0.0
```
1. Cisco ASA 디바이스에서 경로 추적을 실행하여 Amazon 라우터에 도달하는지 확인합니다(예: *AWS\$1ENDPOINT\$11*/*AWS\$1ENDPOINT\$12*).
Amazon 라우터에 도달하면 Amazon VPC 콘솔에서 추가한 고정 경로를 확인하고, 특정 인스턴스에 대한 보안 그룹도 확인하십시오.
1. 자세한 문제 해결 정보는 구성을 검토하십시오.
## 터널 인터페이스 바운스
터널이 가동된 것처럼 보이지만 트래픽이 제대로 흐르지 않는 경우 터널 인터페이스를 바운스(비활성화 및 다시 활성화)하면 종종 연결 문제가 해결될 수 있습니다. Cisco ASA에서 터널 인터페이스를 바운스하려면 다음을 수행합니다.
1. 다음을 실행합니다.
```
ciscoasa# conf t
ciscoasa(config)# interface tunnel X (where X is your tunnel ID)
ciscoasa(config-if)# shutdown
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# end
```
또는 한 줄 명령을 사용할 수 있습니다.
```
ciscoasa# conf t ; interface tunnel X ; shutdown ; no shutdown ; end
```
1. 인터페이스를 바운스한 후 VPN 연결이 다시 설정되었는지, 트래픽이 제대로 흐르고 있는지 확인합니다.
# Cisco IOS 고객 게이트웨이 디바이스와의 AWS Site-to-Site VPN 연결 문제 해결
Cisco 고객 게이트웨이 디바이스의 연결 문제를 해결할 때는 IKE, IPsec, 터널 및 BGP의 네 가지 사항을 고려하십시오. 이런 영역의 문제는 어떤 순서로든 해결할 수 있지만, (네트워크 스택의 맨 아래에 있는) IKE부터 시작해서 위로 올라가는 것이 좋습니다.
## IKE
다음 명령을 사용합니다. 응답에는 IKE가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
router# show crypto isakmp sa
```
```
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
192.168.37.160 72.21.209.193 QM_IDLE 2001 0 ACTIVE
192.168.37.160 72.21.209.225 QM_IDLE 2002 0 ACTIVE
```
터널에 지정된 원격 게이트웨이의 `src` 값이 포함된 줄이 한 개 이상 나타날 것입니다. `state`는 `QM_IDLE`이고 `status`는 `ACTIVE`여야 합니다. 항목이 없거나 또 다른 상태의 항목이 있다는 것은 IKE가 올바로 구성되지 않았음을 나타냅니다.
추가적인 문제 해결을 위해서는 다음 명령을 실행하여 진단 정보를 제공하는 로그 메시지를 활성화합니다.
```
router# term mon
router# debug crypto isakmp
```
디버깅을 비활성화하려면 다음 명령을 사용합니다.
```
router# no debug crypto isakmp
```
## IPsec
다음 명령을 사용합니다. 응답에는 IPsec가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
router# show crypto ipsec sa
```
```
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 192.168.37.160
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.225 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149
#pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.225
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xB8357C22(3090512930)
inbound esp sas:
spi: 0x6ADB173(112046451)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB8357C22(3090512930)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel2
Crypto map tag: Tunnel2-head-0, local addr 174.78.144.73
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.193 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.193
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xF59A3FF6(4120526838)
inbound esp sas:
spi: 0xB6720137(3060924727)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xF59A3FF6(4120526838)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
```
각 터널 인터페이스에 대해 `inbound esp sas` 및 `outbound esp sas`가 모두 나타나야 합니다. SA가 나열되고(예: `spi: 0xF95D2F3C`) `Status`가 `ACTIVE`라고 가정하면, IPsec가 올바로 구성된 것입니다.
추가적인 문제 해결을 위해서는 다음 명령을 사용하여 디버깅을 활성화합니다.
```
router# debug crypto ipsec
```
디버깅을 비활성화하려면 다음 명령을 사용합니다.
```
router# no debug crypto ipsec
```
## 터널
우선, 필요한 방화벽 규칙이 있는지 확인합니다. 자세한 내용은 [AWS Site-to-Site VPN 고객 게이트웨이 디바이스에 대한 방화벽 규칙](FirewallRules.md) 단원을 참조하십시오.
방화벽 규칙이 올바로 설정되어 있으면 다음 명령으로 문제 해결을 계속합니다.
```
router# show interfaces tun1
```
```
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 169.254.255.2/30
MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 174.78.144.73, destination 72.21.209.225
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1427 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
407 packets input, 30010 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
```
`line protocol`이 가동 중인지 확인합니다. 터널 원본 IP 주소, 원본 인터페이스 및 대상이 각각 IP 주소 외부의 고객 게이트웨이 디바이스, 인터페이스 및 IP 주소 외부의 가상 프라이빗 게이트웨이에 대한 터널 구성과 일치하는지 확인합니다. `Tunnel protection via IPSec`가 존재하는지 확인합니다. 양쪽 터널 인터페이스에서 모두 명령을 실행합니다. 문제를 해결하려면 구성을 검토하고 고객 게이트웨이 디바이스에 대한 물리적 연결을 점검합니다.
또한, `169.254.255.1`을 가상 프라이빗 게이트웨이의 내부 IP 주소로 바꾸는 다음 명령을 사용합니다.
```
router# ping 169.254.255.1 df-bit size 1410
```
```
Type escape sequence to abort.
Sending 5, 1410-byte ICMP Echos to 169.254.255.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
```
5개의 느낌표가 나타나야 합니다.
자세한 문제 해결 정보는 구성을 검토하십시오.
## BGP
다음 명령을 사용합니다.
```
router# show ip bgp summary
```
```
BGP router identifier 192.168.37.160, local AS number 65000
BGP table version is 8, main routing table version 8
2 network entries using 312 bytes of memory
2 path entries using 136 bytes of memory
3/1 BGP path/bestpath attribute entries using 444 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 948 total bytes of memory
BGP activity 4/1 prefixes, 4/1 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.255.1 4 7224 363 323 8 0 0 00:54:21 1
169.254.255.5 4 7224 364 323 8 0 0 00:00:24 1
```
두 인접 라우터가 모두 나열되어야 합니다. 각각에 대해 `State/PfxRcd` 값이 `1`로 표시되어야 합니다.
BGP 피어링이 가동되면 고객 게이트웨이 디바이스가 VPC에 기본 경로(0.0.0.0/0)를 알리는지 확인합니다.
```
router# show bgp all neighbors 169.254.255.1 advertised-routes
```
```
For address family: IPv4 Unicast
BGP table version is 3, local router ID is 174.78.144.73
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Originating default network 0.0.0.0
Network Next Hop Metric LocPrf Weight Path
*> 10.120.0.0/16 169.254.255.1 100 0 7224 i
Total number of prefixes 1
```
그 밖에도, 가상 프라이빗 게이트웨이에서 VPC에 해당하는 접두사를 받아야 합니다.
```
router# show ip route bgp
```
```
10.0.0.0/16 is subnetted, 1 subnets
B 10.255.0.0 [20/0] via 169.254.255.1, 00:00:20
```
자세한 문제 해결 정보는 구성을 검토하십시오.
# Border Gateway 프로토콜이 없는 Cisco IOS 고객 게이트웨이 디바이스와의 AWS Site-to-Site VPN 연결 문제 해결
Cisco 고객 게이트웨이 디바이스의 연결 문제를 해결할 때는 IKE, IPsec 및 터널의 세 가지 사항을 고려하십시오. 이런 영역의 문제는 어떤 순서로든 해결할 수 있지만, (네트워크 스택의 맨 아래에 있는) IKE부터 시작해서 위로 올라가는 것이 좋습니다.
## IKE
다음 명령을 사용합니다. 응답에는 IKE가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
router# show crypto isakmp sa
```
```
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
174.78.144.73 205.251.233.121 QM_IDLE 2001 0 ACTIVE
174.78.144.73 205.251.233.122 QM_IDLE 2002 0 ACTIVE
```
터널에 지정된 원격 게이트웨이의 `src` 값이 포함된 줄이 한 개 이상 나타날 것입니다. `state`는 `QM_IDLE`이고 `status`는 `ACTIVE`여야 합니다. 항목이 없거나 또 다른 상태의 항목이 있다는 것은 IKE가 올바로 구성되지 않았음을 나타냅니다.
추가적인 문제 해결을 위해서는 다음 명령을 실행하여 진단 정보를 제공하는 로그 메시지를 활성화합니다.
```
router# term mon
router# debug crypto isakmp
```
디버깅을 비활성화하려면 다음 명령을 사용합니다.
```
router# no debug crypto isakmp
```
## IPsec
다음 명령을 사용합니다. 응답에는 IPsec가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
router# show crypto ipsec sa
```
```
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 174.78.144.73
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.225 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149
#pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.121
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xB8357C22(3090512930)
inbound esp sas:
spi: 0x6ADB173(112046451)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB8357C22(3090512930)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel2
Crypto map tag: Tunnel2-head-0, local addr 205.251.233.122
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.193 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.122
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xF59A3FF6(4120526838)
inbound esp sas:
spi: 0xB6720137(3060924727)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xF59A3FF6(4120526838)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
```
각 터널 인터페이스에 대해 인바운드 `esp sas` 및 아웃바운드 `esp sas`가 모두 나타나야 합니다. 이는 SA가 나열되고(예: `spi: 0x48B456A6`) 상태가 `ACTIVE`이며 IPsec가 올바로 구성되어 있음을 가정할 때의 얘기입니다.
추가적인 문제 해결을 위해서는 다음 명령을 사용하여 디버깅을 활성화합니다.
```
router# debug crypto ipsec
```
디버깅을 비활성화하려면 다음 명령을 사용합니다.
```
router# no debug crypto ipsec
```
## 터널
우선, 필요한 방화벽 규칙이 있는지 확인합니다. 자세한 내용은 [AWS Site-to-Site VPN 고객 게이트웨이 디바이스에 대한 방화벽 규칙](FirewallRules.md) 단원을 참조하십시오.
방화벽 규칙이 올바로 설정되어 있으면 다음 명령으로 문제 해결을 계속합니다.
```
router# show interfaces tun1
```
```
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 169.254.249.18/30
MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 174.78.144.73, destination 205.251.233.121
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1427 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
407 packets input, 30010 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
```
라인 프로토콜이 가동 중인지 확인합니다. 터널 원본 IP 주소, 원본 인터페이스 및 대상이 각각 IP 주소 외부의 고객 게이트웨이 디바이스, 인터페이스 및 IP 주소 외부의 가상 프라이빗 게이트웨이에 대한 터널 구성과 일치하는지 확인합니다. `Tunnel protection through IPSec`가 존재하는지 확인합니다. 양쪽 터널 인터페이스에서 모두 명령을 실행합니다. 문제를 해결하려면 구성을 검토하고 고객 게이트웨이 디바이스에 대한 물리적 연결을 점검합니다.
또한, `169.254.249.18`을 가상 프라이빗 게이트웨이의 내부 IP 주소로 바꾸는 다음 명령을 사용할 수 있습니다.
```
router# ping 169.254.249.18 df-bit size 1410
```
```
Type escape sequence to abort.
Sending 5, 1410-byte ICMP Echos to 169.254.249.18, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
```
5개의 느낌표가 나타나야 합니다.
### 라우팅
고정 라우팅 테이블을 보려면 다음 명령을 사용합니다.
```
router# sh ip route static
```
```
1.0.0.0/8 is variably subnetted
S 10.0.0.0/16 is directly connected, Tunnel1
is directly connected, Tunnel2
```
두 터널을 모두 통해 VPC CIDR에 대한 고정 경로가 존재함을 확인해야 합니다. 존재하지 않으면 다음과 같이 고정 경로를 추가합니다:
```
router# ip route 10.0.0.0 255.255.0.0 Tunnel1 track 100
router# ip route 10.0.0.0 255.255.0.0 Tunnel2 track 200
```
### SLA 모니터링 확인
```
router# show ip sla statistics 100
```
```
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
Latest RTT: 128 milliseconds
Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
```
```
router# show ip sla statistics 200
```
```
IPSLAs Latest Operation Statistics
IPSLA operation id: 200
Latest RTT: 128 milliseconds
Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
```
`Number of successes`의 값은 SLA 모니터가 성공적으로 설정되었는지 나타냅니다.
자세한 문제 해결 정보는 구성을 검토하십시오.
# Juniper JunOS 고객 게이트웨이 디바이스와의 AWS Site-to-Site VPN 연결 문제 해결
Juniper 고객 게이트웨이 디바이스의 연결 문제를 해결할 때는 IKE, IPsec, 터널 및 BGP의 네 가지 사항을 고려하십시오. 이런 영역의 문제는 어떤 순서로든 해결할 수 있지만, (네트워크 스택의 맨 아래에 있는) IKE부터 시작해서 위로 올라가는 것이 좋습니다.
## IKE
다음 명령을 사용합니다. 응답에는 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
```
터널에 지정된 원격 게이트웨이의 원격 주소가 포함된 줄이 한 개 이상 나타날 것입니다. `State`가 `UP`이어야 합니다. 항목이 없거나 또 다른 상태(예: `DOWN`)의 항목이 있다는 것은 IKE가 올바로 구성되지 않았음을 나타냅니다.
추가적인 문제 해결을 위해서는 예제 구성 파일에서 권장하는 대로 IKE 추적 옵션을 활성화하십시오. 그런 다음, 아래 명령을 실행하여 다양한 디버깅 메시지를 화면에 인쇄합니다.
```
user@router> monitor start kmd
```
외부 호스트에서 다음 명령으로 전체 로그 파일을 검색할 수 있습니다.
```
scp username@router.hostname:/var/log/kmd
```
## IPsec
다음 명령을 사용합니다. 응답에는 IPsec가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
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
```
특히, (원격 게이트웨이에 해당하는) 게이트웨이 주소당 두 줄 이상 나타나야 합니다. 각 줄 시작 부분의 캐럿 기호(< >)는 특정 항목에 대한 트래픽의 방향을 나타냅니다. 출력에는 인바운드 트래픽("<", 가상 프라이빗 게이트웨이에서 고객 게이트웨이 디바이스로 흐르는 트래픽)과 아웃바운드 트래픽(">")이 별개의 줄로 표시됩니다.
추가적인 문제 해결을 위해서는 IKE 추적 옵션을 활성화하십시오(자세한 내용은 IKE에 대한 이전의 단원 참조).
## 터널
우선, 필요한 방화벽 규칙이 있는지 중복 확인합니다. 규칙 목록은 [AWS Site-to-Site VPN 고객 게이트웨이 디바이스에 대한 방화벽 규칙](FirewallRules.md) 단원을 참조하십시오.
방화벽 규칙이 올바로 설정되어 있으면 다음 명령으로 문제 해결을 계속합니다.
```
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
```
`Security: Zone`이 올바른지, `Local` 주소가 고객 게이트웨이 디바이스 터널 내부 주소와 일치하는지 확인합니다.
다음으로, `169.254.255.1`을 가상 프라이빗 게이트웨이의 내부 IP 주소로 바꾸는 다음 명령을 사용합니다. 결과는 아래에 표시된 응답과 같은 내용이어야 합니다.
```
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
```
자세한 문제 해결 정보는 구성을 검토하십시오.
## BGP
다음 명령을 실행합니다.
```
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
```
추가적인 문제 해결을 위해, `169.254.255.1`을 가상 프라이빗 게이트웨이의 내부 IP 주소로 바꾸는 다음 명령을 사용합니다.
```
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
```
이때 `Received prefixes`와 `Advertised prefixes`가 각각 1에 나열되어야 합니다. 이것은 `Table inet.0` 단원 내에 있어야 합니다.
`State`가 `Established`가 아닌 경우 문제를 정정하는 데 필요한 사항에 대한 세부 정보는 `Last State` 및 `Last Error`를 확인하십시오.
BGP 피어링이 가동되면 고객 게이트웨이 디바이스가 VPC에 기본 경로(0.0.0.0/0)를 알리는지 확인합니다.
```
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
```
그 밖에도, 가상 프라이빗 게이트웨이에서 VPC에 해당하는 접두사를 받아야 합니다.
```
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
```
# Juniper ScreenOS 고객 게이트웨이 디바이스와의 AWS Site-to-Site VPN 연결 문제 해결
Juniper ScreenOS 기반 고객 게이트웨이 디바이스의 연결 문제를 해결할 때는 IKE, IPsec, 터널 및 BGP의 네 가지 사항을 고려하십시오. 이런 영역의 문제는 어떤 순서로든 해결할 수 있지만, (네트워크 스택의 맨 아래에 있는) IKE부터 시작해서 위로 올라가는 것이 좋습니다.
## IKE 및 IPsec
다음 명령을 사용합니다. 응답에는 IKE가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
ssg5-serial-> get sa
```
```
total configured sa: 2
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000002< 72.21.209.225 500 esp:a128/sha1 80041ca4 3385 unlim A/- -1 0
00000002> 72.21.209.225 500 esp:a128/sha1 8cdd274a 3385 unlim A/- -1 0
00000001< 72.21.209.193 500 esp:a128/sha1 ecf0bec7 3580 unlim A/- -1 0
00000001> 72.21.209.193 500 esp:a128/sha1 14bf7894 3580 unlim A/- -1 0
```
터널에 지정된 원격 게이트웨이의 원격 주소가 포함된 줄이 한 개 이상 나타날 것입니다. `Sta` 값은 `A/-`, `SPI`는 `00000000` 이외의 16진수여야 합니다. 다른 상태의 항목은 IKE가 올바로 구성되지 않았음을 나타냅니다.
추가적인 문제 해결을 위해서는 예제 구성 파일에서 권장하는 대로 IKE 추적 옵션을 활성화하십시오.
## 터널
우선, 필요한 방화벽 규칙이 있는지 중복 확인합니다. 규칙 목록은 [AWS Site-to-Site VPN 고객 게이트웨이 디바이스에 대한 방화벽 규칙](FirewallRules.md) 단원을 참조하십시오.
방화벽 규칙이 올바로 설정되어 있으면 다음 명령으로 문제 해결을 계속합니다.
```
ssg5-serial-> get interface tunnel.1
```
```
Interface tunnel.1:
description tunnel.1
number 20, if_info 1768, if_index 1, mode route
link ready
vsys Root, zone Trust, vr trust-vr
admin mtu 1500, operating mtu 1500, default mtu 1500
*ip 169.254.255.2/30
*manage ip 169.254.255.2
route-deny disable
bound vpn:
IPSEC-1
Next-Hop Tunnel Binding table
Flag Status Next-Hop(IP) tunnel-id VPN
pmtu-v4 disabled
ping disabled, telnet disabled, SSH disabled, SNMP disabled
web disabled, ident-reset disabled, SSL disabled
OSPF disabled BGP enabled RIP disabled RIPng disabled mtrace disabled
PIM: not configured IGMP not configured
NHRP disabled
bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
configured ingress mbw 0kbps, current bw 0kbps
total allocated gbw 0kbps
```
`link:ready`가 나타나는지, `IP` 주소가 고객 게이트웨이 디바이스 터널 내부 주소와 일치하는지 확인합니다.
다음으로, `169.254.255.1`을 가상 프라이빗 게이트웨이의 내부 IP 주소로 바꾸는 다음 명령을 사용합니다. 결과는 아래에 표시된 응답과 같은 내용이어야 합니다.
```
ssg5-serial-> ping 169.254.255.1
```
```
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 169.254.255.1, timeout is 1 seconds
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=32/32/33 ms
```
자세한 문제 해결 정보는 구성을 검토하십시오.
## BGP
다음 명령을 실행합니다.
```
ssg5-serial-> get vrouter trust-vr protocol bgp neighbor
```
```
Peer AS Remote IP Local IP Wt Status State ConnID Up/Down
--------------------------------------------------------------------------------
7224 169.254.255.1 169.254.255.2 100 Enabled ESTABLISH 10 00:01:01
7224 169.254.255.5 169.254.255.6 100 Enabled ESTABLISH 11 00:00:59
```
두 BGP 피어의 상태는 모두 `ESTABLISH`로 표시되어야 하며, 이는 가상 프라이빗 게이트웨이에 대한 BGP 연결이 활성 상태라는 의미입니다.
추가적인 문제 해결을 위해, `169.254.255.1`을 가상 프라이빗 게이트웨이의 내부 IP 주소로 바꾸는 다음 명령을 사용합니다.
```
ssg5-serial-> get vr trust-vr prot bgp neigh 169.254.255.1
```
```
peer: 169.254.255.1, remote AS: 7224, admin status: enable
type: EBGP, multihop: 0(disable), MED: node default(0)
connection state: ESTABLISH, connection id: 18 retry interval: node default(120s), cur retry time 15s
configured hold time: node default(90s), configured keepalive: node default(30s)
configured adv-interval: default(30s)
designated local IP: n/a
local IP address/port: 169.254.255.2/13946, remote IP address/port: 169.254.255.1/179
router ID of peer: 169.254.255.1, remote AS: 7224
negotiated hold time: 30s, negotiated keepalive interval: 10s
route map in name: , route map out name:
weight: 100 (default)
self as next hop: disable
send default route to peer: disable
ignore default route from peer: disable
send community path attribute: no
reflector client: no
Neighbor Capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received
force reconnect is disable
total messages to peer: 106, from peer: 106
update messages to peer: 6, from peer: 4
Tx queue length 0, Tx queue HWM: 1
route-refresh messages to peer: 0, from peer: 0
last reset 00:05:33 ago, due to BGP send Notification(Hold Timer Expired)(code 4 : subcode 0)
number of total successful connections: 4
connected: 2 minutes 6 seconds
Elapsed time since last update: 2 minutes 6 seconds
```
BGP 피어링이 가동되면 고객 게이트웨이 디바이스가 VPC에 기본 경로(0.0.0.0/0)를 알리는지 확인합니다. 이 명령은 ScreenOS 버전 6.2.0 이상에 적용됩니다.
```
ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 advertised
```
```
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
--------------------------------------------------------------------------------------
>i 0.0.0.0/0 0.0.0.0 32768 100 0 IGP
Total IPv4 routes advertised: 1
```
그 밖에도, 가상 프라이빗 게이트웨이에서 VPC에 해당하는 접두사를 받아야 합니다. 이 명령은 ScreenOS 버전 6.2.0 이상에 적용됩니다.
```
ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 received
```
```
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
--------------------------------------------------------------------------------------
>e* 10.0.0.0/16 169.254.255.1 100 100 100 IGP 7224
Total IPv4 routes received: 1
```
# Yamaha 고객 게이트웨이 디바이스와의 AWS Site-to-Site VPN 연결 문제 해결
Yamaha 고객 게이트웨이 디바이스의 연결 문제를 해결할 때는 IKE, IPsec, 터널 및 BGP의 네 가지 사항을 고려하십시오. 이런 영역의 문제는 어떤 순서로든 해결할 수 있지만, (네트워크 스택의 맨 아래에 있는) IKE부터 시작해서 위로 올라가는 것이 좋습니다.
**참고**
IKE의 2단계에서 사용된 `proxy ID` 설정은 Yamaha 라우터에서 기본적으로 사용 중지됩니다. 이로 인해 Site-to-Site VPN에 연결하는 데 문제가 발생할 수 있습니다. 라우터에 `proxy ID`가 구성되지 않은 경우 Yamaha가 올바르게 설정할 수 있도록 AWS제공된 예제 구성 파일을 참조하세요.
## IKE
다음 명령을 실행합니다. 응답에는 IKE가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
# show ipsec sa gateway 1
```
```
sgw flags local-id remote-id # of sa
--------------------------------------------------------------------------
1 U K YOUR_LOCAL_NETWORK_ADDRESS 72.21.209.225 i:2 s:1 r:1
```
터널에 지정된 원격 게이트웨이의 `remote-id` 값이 포함된 줄이 나타날 것입니다. 터널 번호를 생략하여 보안 연결(SA)을 전부 나열할 수 있습니다.
추가적인 문제 해결을 위해서는 다음 명령을 실행하여 진단 정보를 제공하는 DEBUG 수준 로그 메시지를 활성화합니다.
```
# syslog debug on
# ipsec ike log message-info payload-info key-info
```
로그에 기록된 항목을 취소하려면 다음 명령을 실행합니다.
```
# no ipsec ike log
# no syslog debug on
```
## IPsec
다음 명령을 실행합니다. 응답에는 IPsec가 올바로 구성된 고객 게이트웨이 디바이스가 표시됩니다.
```
# show ipsec sa gateway 1 detail
```
```
SA[1] Duration: 10675s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Protocol: IKE
Algorithm: AES-CBC, SHA-1, MODP 1024bit
SPI: 6b ce fd 8a d5 30 9b 02 0c f3 87 52 4a 87 6e 77
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[2] Duration: 1719s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Direction: send
Protocol: ESP (Mode: tunnel)
Algorithm: AES-CBC (for Auth.: HMAC-SHA)
SPI: a6 67 47 47
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[3] Duration: 1719s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Direction: receive
Protocol: ESP (Mode: tunnel)
Algorithm: AES-CBC (for Auth.: HMAC-SHA)
SPI: 6b 98 69 2b
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[4] Duration: 10681s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Protocol: IKE
Algorithm: AES-CBC, SHA-1, MODP 1024bit
SPI: e8 45 55 38 90 45 3f 67 a8 74 ca 71 ba bb 75 ee
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
```
각 터널 인터페이스에 대해 `receive sas` 및 `send sas`가 모두 나타나야 합니다.
추가적인 문제 해결을 위해서는 다음 명령을 사용하여 디버깅을 활성화합니다.
```
# syslog debug on
# ipsec ike log message-info payload-info key-info
```
디버깅을 비활성화하려면 다음 명령을 실행합니다.
```
# no ipsec ike log
# no syslog debug on
```
## 터널
우선, 필요한 방화벽 규칙이 있는지 확인합니다. 규칙 목록은 [AWS Site-to-Site VPN 고객 게이트웨이 디바이스에 대한 방화벽 규칙](FirewallRules.md) 단원을 참조하십시오.
방화벽 규칙이 올바로 설정되어 있으면 다음 명령으로 문제 해결을 계속합니다.
```
# show status tunnel 1
```
```
TUNNEL[1]:
Description:
Interface type: IPsec
Current status is Online.
from 2011/08/15 18:19:45.
5 hours 7 minutes 58 seconds connection.
Received: (IPv4) 3933 packets [244941 octets]
(IPv6) 0 packet [0 octet]
Transmitted: (IPv4) 3933 packets [241407 octets]
(IPv6) 0 packet [0 octet]
```
`current status` 값이 온라인이고 `Interface type`이 IPsec인지 확인하십시오. 양쪽 터널 인터페이스에서 모두 명령을 실행해야 합니다. 여기서 문제를 해결하려면 구성을 검토하십시오.
## BGP
다음 명령을 실행합니다.
```
# show status bgp neighbor
```
```
BGP neighbor is 169.254.255.1, remote AS 7224, local AS 65000, external link
BGP version 0, remote router ID 0.0.0.0
BGP state = Active
Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Connection established 0; dropped 0
Last reset never
Local host: unspecified
Foreign host: 169.254.255.1, Foreign port: 0
BGP neighbor is 169.254.255.5, remote AS 7224, local AS 65000, external link
BGP version 0, remote router ID 0.0.0.0
BGP state = Active
Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Connection established 0; dropped 0
Last reset never
Local host: unspecified
Foreign host: 169.254.255.5, Foreign port:
```
두 인접 라우터가 모두 나열되어야 합니다. 각각에 대해 `BGP state` 값이 `Active`로 표시되어야 합니다.
BGP 피어링이 가동되면 고객 게이트웨이 디바이스가 VPC에 기본 경로(0.0.0.0/0)를 알리는지 확인합니다.
```
# show status bgp neighbor 169.254.255.1 advertised-routes
```
```
Total routes: 1
*: valid route
Network Next Hop Metric LocPrf Path
* default 0.0.0.0 0 IGP
```
그 밖에도, 가상 프라이빗 게이트웨이에서 VPC에 해당하는 접두사를 받아야 합니다.
```
# show ip route
```
```
Destination Gateway Interface Kind Additional Info.
default ***.***.***.*** LAN3(DHCP) static
10.0.0.0/16 169.254.255.1 TUNNEL[1] BGP path=10124
```