Ubuntu 14.04.2 LTS를 실행하는 두 Amazon AWS EC2 인스턴스 간에 StrongSwan 5.1.2를 사용하여 VPN 터널을 설정하려고 합니다. StrongSwan을 사용하기 전에는 Amazon RedHat AMI에서 open(libre)swan을 사용했는데 잘 작동했습니다. 어떤 이유로 저는 IKE를 StrongSwan에서 일하게 할 수도 없습니다. AWS 구성을 세 번 확인했는데 모두 괜찮아 보였으므로 StrongSwan 구성에 문제가 있는 것 같습니다.
아래에서 볼 수 있듯이 내가 받고 있는 오류는 다음과 같습니다."소켓에 쓰는 중 오류 발생: 잘못된 인수". 나는 온라인에서 보았지만 실제로 이에 대한 해결책을 찾을 수 없습니다. 내 Strongswan ipsec.conf가 부적절하게 구성되었다고 확신합니다.
제가 작업하는 내용은 다음과 같습니다.
Instance #1: N.Virginia - 10.198.0.164 with public EIP 54.X.X.X
Instance #2: Oregon - 10.194.0.176 with public EIP 52.Y.Y.Y
(간단한) 토폴로지는 다음과 같습니다.
[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]
다음 AWS 구성이 올바른지 확인했습니다.
Security groups permit all
IP information is correct
Src/Dest disabled on both instances
ACLs permit all
routes are present and correct (route to 10.x will point to that local instance in order to be routed out to the VPN tunnel)
아래는/etc/ipsec.conf (이것은 오레곤 출신이지만 왼쪽|오른쪽 값이 반대라는 점을 제외하면 N.Virginia 인스턴스에서도 동일합니다.):
config setup
charondebug="dmn 2, mgr 2, ike 2, chd 2, job 2, cfg 2, knl 2, net 2, enc 2, lib 2"
conn aws1oexternal-aws1nvexternal
left=52.Y.Y.Y (EIP)
leftsubnet=10.194.0.0/16
right=54.X.X.X (EIP)
rightsubnet=10.198.0.0/16
auto=start
authby=secret
type=tunnel
mobike=no
dpdaction=restart
다음은 /etc/ipsec.secrets *입니다(다른 인스턴스에서는 반대임).
54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"
아래는 /etc/strongswan.conf입니다:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
다음은 /etc/sysctl.conf입니다:
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
다음은 /var/log/syslog의 디버그 출력입니다.여기서 문제는 "소켓에 쓰기 오류: 잘못된 인수입니다. 모든 것을 시도한 후에도 동일한 오류가 계속 발생합니다.":
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[IKE] retransmit 5 of request with message ID 0
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500] (1212 bytes)
Jun 17 17:34:48 ip-10-198-0-164 charon: 03[JOB] next event in 75s 581ms, waiting]
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] checkin IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] check-in of IKE_SA successful.
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] error writing to socket: Invalid argument
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] got event, queuing job for execution
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] no events, waiting
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkout IKE_SA
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] IKE_SA aws1vexternal-aws1oexternal[1] successfully checked out
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] giving up after 5 retransmits
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] establishing IKE_SA failed, peer not responding
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkin and destroy IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] IKE_SA aws1vexternal-aws1oexternal[1] state change: CONNECTING => DESTROYING
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] check-in and destroy of IKE_SA successful
아래는 지금까지 시도한 것입니다.
1) 검증된 레이어 3
2) 재부팅된 머신
3) leftid=에 추가해 보았습니다.
4) IPsec 업데이트를 시도한 다음 IPsec 다시 시작을 시도했습니다.
5) confif 설정에서 nat_traversal=yes를 추가해 보았습니다(문서에 따르면 자동으로 nat_traversal을 사용하는 IKEv2를 사용하여 ipsec 상태가 확인되었으므로 이는 중요하지 않습니다).
6) virtual_private 생략 시도 <-- AWS openswan 문서에 따라 사용되었으므로 Strongswan 구성에 포함했습니다.
7) /etc/sysctl.conf에서 net.ipv4.conf.all.send_redirects = 0 및 net.ipv4.conf.all.accept_redirects = 0 비활성화를 시도했습니다.
8) EIP 대신 개인 IP를 사용해 보았습니다. 더 이상 소켓 오류가 발생하지 않지만 분명히 두 IP가 서로 통신할 수 없습니다.
9) 이것을 Strongswan.conf에 추가해 보았습니다: load = aes des sha1 sha2 md5 gmp random nonce hmac 스트로크 kernel-netlink 소켓-기본 updown
10) leftfirewall=yes를 사용해 보았지만 작동하지 않았습니다.
도와주세요! 감사해요!
편집 #1:
Michael의 답변으로 원래 문제가 해결되었지만 라우팅과 관련된 새로운 문제가 생겼습니다. 두 VPN 인스턴스 모두 서로 ping할 수 없습니다. 또한 두 서브넷의 임의 인스턴스에서 다른 임의 인스턴스나 맨 끝 VPN 인스턴스로 ping을 시도하면 다음과 같은 ping 응답을 받습니다.
root@ip-10-194-0-80:~# ping 10.198.0.164
PING 10.198.0.164 (10.198.0.164) 56(84) bytes of data.
From 10.194.0.176: icmp_seq=1 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=2 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=3 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=4 Redirect Host(New nexthop: 10.194.0.176)
분명히 이것은 Oregon 서브넷의 10.194.0.80 호스트가 Oregon VPN 인스턴스로부터 응답을 받을 수 있기 때문에 두 VPN 인스턴스 간의 라우팅 문제임이 틀림없습니다(대개 Strongswan 구성 또는 인스턴스 라우팅 테이블로 인해 발생함). 라우팅 테이블 + 인스턴스의 경로 추적:
root@ip-10-194-0-80:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.194.0.1 0.0.0.0 UG 0 0 0 eth0
10.194.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
root@ip-10-194-0-80:~# traceroute 10.198.0.164
traceroute to 10.198.0.164 (10.198.0.164), 30 hops max, 60 byte packets
1 10.194.0.176 (10.194.0.176) 0.441 ms 0.425 ms 0.409 ms^C
openswan을 사용할 때는 각 인스턴스의 라우팅 테이블을 수동으로 수정할 필요가 없었습니다.
Oregon VPN 인스턴스의 라우팅 테이블은 다음과 같습니다.
root@ip-10-194-0-176:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.194.0.1 0.0.0.0 UG 0 0 0 eth0
10.194.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
나는 조금 어리둥절하다.
편집 #2:
VPN 인스턴스 간의 라우팅이 문제가 아닐 수도 있는 것 같습니다. /var/log/syslog는 한 VPN 인스턴스 공용 IP에서 다른 VPN 인스턴스로 수신되는 패킷을 보여줍니다.
Jun 23 19:57:49 ip-10-194-0-176 charon: 10[NET] received packet: from 54.X.X.X[4500] to 10.194.0.176[4500] (76 bytes)
아동 보안 협회와 관련된 문제인 것 같습니다.
aws1oexternal-aws1nvexternal: child: 10.194.0.0/16 === 10.198.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 **connecting**):
/var/log/syslog:
Jun 23 19:52:19 ip-10-194-0-176 charon: 02[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE] queueing CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE] activating CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 06[IKE] establishing CHILD_SA aws1oexternal-aws1nvexternal
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] received FAILED_CP_REQUIRED notify, no CHILD_SA built
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] looking for a child config for 10.194.0.0/16 === 10.198.0.0/16
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] found matching child config "aws1oexternal-aws1nvexternal" with prio 10
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] configuration payload negotiation failed, no CHILD_SA built
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] failed to establish CHILD_SA, keeping IKE_SA
***수정 #3: 문제 해결됨(어, 실제로 아래 수정 #4를 참조하세요...)****
문제가 해결되었습니다.
1) Michael의 구성 지침을 제대로 따르지 않았습니다. 또한 rightsourceip와 leftsourceip를 함께 구성하여 두 인스턴스 모두 둘 다 개시자라고 믿게 만들었습니다. 한 명은 개시자이고 다른 한 명은 요청자임을 확인했습니다. 이로 인해 IKE 문제가 해결되었습니다.
2) esp 매개변수도 명시적으로 설정해야 한다는 것을 알았습니다. 이미 기본값(aes128-sha1,3des-sha1)이 있더라도 인스턴스가 esp OR ah(둘 다는 아님)를 사용하도록 알 수 있도록 esp 매개변수를 설정해야 합니다. 결국 aes128-sha1-modp2048을 사용했습니다.
이 게시물이 다음 Linux 초보자가 이를 설정하는 데 도움이 되기를 바랍니다!!
건배!
편집 #4: 문제(실제로는 아님)가 해결되었습니다.
Strongswan과 관련된 별도의 문제를 해결하는 동안 "leftfirewall" 매개변수를 변경하고 테스트했지만 별도의 문제를 해결하지 못한 다음 사전에 원래 구성으로 되돌렸습니다(leftfirewall에 주석 처리됨). 나는 이제 터널을 가로질러 핑을 할 수 없다는 것을 깨달았습니다. 무슨 일이 일어났는지 알아내려고 몇 시간 동안 미친 듯이 노력한 후, 무슨 일이 일어날지 알아보기 위해 esp 매개변수에 주석을 달았습니다. 이제 다시 터널을 가로질러 핑을 보낼 수 있습니다! <- 따라서 일부 IPsec 유령이 나에게 장난을 치고 esp 매개변수가 실제로 TS_UNACCEPTABLE 오류에 대한 수정 사항이 아닐 가능성이 있습니다(온라인의 다른 리소스에서는 esp 매개변수가 수정 사항이라고 명시하지만...).
편집 #5: 문제가 완전히 해결되었습니다.
결국 모든 것을 테스트 환경으로 옮기고 처음부터 시작했습니다. Ubuntu 저장소(5.1.2)에 있던 이전 버전이 아닌 최신 버전(5.3.2)을 사용하여 소스에서 설치했습니다. 이로써 위에서 겪었던 문제가 해결되었고 VPN 터널을 통해 여러 서브넷 간에 netcat(훌륭한 도구!!)을 사용하여 레이어 7 연결이 확인되었습니다.
또한: 그것은아니다VPC에 대한 DNS 호스트 이름을 활성화하는 데 필요합니다(Amazon에서 잘못 믿게 되었기 때문에). 참고>
이것이 모두 도움이 되기를 바랍니다!!!!!
2017년 2월 11일 추가 편집:
JustEngland의 요청에 따라 아래 작업 구성을 복사합니다(식별을 방지하기 위해 특정 세부 정보는 생략).
A면:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# Add connections here.
conn %default
ikelifetime= You choose; must match other side
keylife= You choose; must match other side
rekeymargin= You choose; must match other side
keyingtries=1
keyexchange= You choose; must match other side
authby=secret
mobike=no
conn side-a
left=10.198.0.124
leftsubnet=10.198.0.0/16
leftid=54.y.y.y
leftsourceip=10.198.0.124
right=52.x.x.x
rightsubnet=10.194.0.0/16
auto=start
type=tunnel
# Add connections here.
root@x:~# cat /etc/ipsec.secrets
A.A.A.A B.B.B.B : PSK "Your Password"
B면:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
conn %default
ikelifetime= You choose; must match other side
keylife= You choose; must match other side
rekeymargin= You choose; must match other side
keyingtries=1
keyexchange= You choose; must match other side
authby=secret
mobike=no
conn side-b
left=10.194.0.129
leftsubnet=10.194.0.0/16
leftid=52.x.x.x
right=54.y.y.y
rightsubnet=10.198.0.0/16
rightsourceip=10.198.0.124
auto=start
type=tunnel
root@x:~# cat /etc/ipsec.secrets
B.B.B.B A.A.A.A : PSK "Your Password"
답변1
VPC에서는 인스턴스의 퍼블릭 IP 주소가 인스턴스 스택에 바인딩되지 않으므로 내부 프라이빗 주소와 외부 퍼블릭 주소를 모두 구성해야 합니다. 그만큼잘못된 인수이는 인스턴스에 알려지지 않은 퍼블릭 IP 주소에서 직접 트래픽을 소싱하려고 시도했기 때문에 발생한 것으로 추정됩니다.
left=10.10.10.10 # instance private IP of local system
leftsourceip=10.10.10.10 # instance private IP of local system
leftid=203.x.x.x # elastic IP of local system
leftsubnet=10.x.x.x/xx
rightsubnet=10.x.x.x/xx
right=198.x.x.x # elastic IP of remote system
답변2
문제가 해결되었습니다.
1) Michael의 구성 지침을 제대로 따르지 않았습니다. 또한 rightsourceip와 leftsourceip를 함께 구성하여 두 인스턴스 모두 둘 다 개시자라고 믿게 만들었습니다. 한 명은 개시자이고 다른 한 명은 요청자임을 확인했습니다. 이로 인해 IKE 문제가 해결되었습니다.
2) esp 매개변수도 명시적으로 설정해야 한다는 것을 알았습니다. 이미 기본값(aes128-sha1,3des-sha1)이 있더라도 인스턴스가 esp OR ah(둘 다는 아님)를 사용하도록 알 수 있도록 esp 매개변수를 설정해야 합니다. 결국 aes128-sha1-modp2048을 사용했습니다.