मैं Ubuntu के 14.04.2 LTS पर चलने वाले दो अमेज़ॅन AWS EC2 उदाहरणों के बीच StrongSwan 5.1.2 का उपयोग करके एक वीपीएन सुरंग स्थापित करने का प्रयास कर रहा हूं। स्ट्रॉन्गस्वान का उपयोग करने से पहले, मैंने अमेज़ॅन रेडहैट एएमआई पर खुले (लीबरे) हंस का इस्तेमाल किया, जिसने ठीक काम किया। किसी कारणवश मैं यहां स्ट्रॉन्गस्वान के लिए काम करने के लिए IKE भी नहीं कर सकता। मैंने अपने AWS कॉन्फ़िगरेशन की ट्रिपल जाँच की, और यह सब अच्छा लग रहा है, इसलिए इसे 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) वाम में जोड़ने की कोशिश की =
4) ipsec अपडेट करने की कोशिश की गई तब ipsec रिस्टार्ट होता है
5) nif_traversal को जोड़ने की कोशिश की = हां विश्वास के तहत सेटअप (ध्यान दें कि यह बात नहीं होनी चाहिए क्योंकि IKEv2 का उपयोग करके सत्यापित ipsec स्थिती, जो प्रलेखन के अनुसार स्वचालित रूप से nat_traversal का उपयोग करती है)
6) ट्राईड ऑउटिंग वर्चुअल_प्रीयर <- का उपयोग एडब्ल्यूएस ओप्सवान डॉक्यूमेंटेशन के अनुसार किया गया था, इसलिए मैंने इसे स्ट्रांग्सवन कॉन्फिगर में शामिल किया।
7) नेट को निष्क्रिय करने की कोशिश की। net.ipv4.conf.all.send_redirects = 0 और net.ipv4.conf.all.accept_redirects = 0 in /etc/sysctl.conf
8) EIP के बजाय निजी IP का उपयोग करने की कोशिश की। मुझे अब सॉकेट त्रुटि नहीं मिलती है, हालांकि स्पष्ट रूप से दो आईपी एक दूसरे को सहकर्मी से संवाद नहीं कर सकते ...
9) इसे strongswan.conf में जोड़ने की कोशिश की गई: लोड = aes des sha1 sha2 md5 gmp यादृच्छिक नॉन hmac स्ट्रोक कर्नेल-नेटलिंक सॉकेट-डिफ़ॉल्ट अपडाउन
१०) वाममार्ग का उपयोग करने की कोशिश की = हाँ, काम नहीं किया
कृपया सहायता कीजिए! धन्यवाद!
EDIT # 1:
माइकल की प्रतिक्रिया ने मूल समस्या को मंजूरी दे दी, हालांकि मुझे रूटिंग से संबंधित एक नई समस्या है। दोनों वीपीएन उदाहरण एक दूसरे को पिंग करने में असमर्थ हैं। इसके अलावा, जब मैं या तो किसी अन्य यादृच्छिक उदाहरण या दूर के वीपीएन उदाहरण के लिए सबनेट में एक यादृच्छिक उदाहरण से पिंग करने की कोशिश करता हूं, तो मुझे निम्नलिखित पिंग प्रतिक्रिया मिलती है:
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)
जाहिर है कि यह ओरेगन सबनेट में 10.194.0.80 होस्ट के बाद से दो वीपीएन इंस्टेंसेस (स्ट्रॉन्गवान कॉन्फ़िगरेशन या उदाहरण रूटिंग टेबल के कारण सबसे अधिक संभावना) के बीच एक रूटिंग मुद्दा होना चाहिए, ओरेगन वीपीएन इंस्टेंस से प्रतिक्रिया प्राप्त करने में सक्षम है। उदाहरण के लिए मार्ग तालिका + ट्रेसरआउट:
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
जब मैं सलामी बल्लेबाज का उपयोग कर रहा था, तो मुझे प्रत्येक उदाहरण के राउटिंग टेबल के लिए किसी भी मैनुअल संशोधन करने की आवश्यकता नहीं थी।
यहाँ ओरेगन वीपीएन उदाहरण की मार्ग तालिका है:
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
मैं थोड़ा स्टम्प्ड हूं।
EDIT # 2:
ऐसा लगता है कि वीपीएन इंस्टेंसेस के बीच रूटिंग में समस्या नहीं हो सकती है: / var / log / syslog शो पैकेट्स को एक वीपीएन उदाहरण सार्वजनिक आईपी से दूसरे वीपीएन इंस्टेंस पर प्राप्त किया जा रहा है
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
*** EDIT # 3: समस्या हल हो गई (उह, वास्तव में EDIT # 4 नीचे देखें ...) ****
निर्धारित समस्या।
1) मैंने माइकल के विन्यास निर्देशों का ठीक से पालन नहीं किया। मैंने एक राइटसॉर्प और लेफ़्ट्सट्रॉफ़ को भी एक साथ कॉन्फ़िगर किया, जिससे दोनों उदाहरणों को विश्वास हुआ कि वे दोनों सर्जक थे। मैंने सुनिश्चित किया कि एक एक सर्जक था और एक एक निवेदनकर्ता था; यह IKE समस्या को ठीक करता है।
2) मुझे पता चला कि मुझे भी जासूसी पैरामीटर को स्पष्ट रूप से सेट करना था। भले ही पहले से ही एक डिफ़ॉल्ट (aes128-sha1,3des-sha1) है, लेकिन अभी भी एस्प या आह (लेकिन दोनों नहीं) का उपयोग करने के लिए पता करने के लिए जासूसी पैरामीटर अभी भी सेट किया जाना है। मैंने aes128-sha1-modp2048 का उपयोग कर समाप्त किया।
आशा है कि यह पोस्टिंग अगले लिनक्स नौसिखिया को स्थापित करने में मदद करती है !!
चीयर्स!
EDIT # 4: समस्या (वास्तव में नहीं) हल
सशक्त से संबंधित एक अलग समस्या का निवारण करते समय, मैंने "वामपन्थी" पैरामीटर को बदल दिया, परीक्षण किया, मेरे अलग मुद्दे को ठीक नहीं किया, फिर वापस मूल विन्यास पर वापस लौट आया (टिप्पणी छोड़ दिया। मैंने तब देखा कि अब मैं सुरंग के पार नहीं जा सकता। घंटों तक पागल होने के बाद क्या हुआ, यह जानने के लिए मैंने एस्प पैरामीटर पर टिप्पणी की कि क्या होगा: मैं अब टंगनेल को पिंग कर सकता हूं! <- तो, वहाँ एक संभावना है कि कुछ ipsec भूत मुझ पर चालें चलाने के आसपास चल रहे हैं और यह कि एस्प पैरामीटर वास्तव में TS_UNACCEPTABLE त्रुटियों के लिए ठीक नहीं है (हालांकि अन्य संसाधन ऑनलाइन स्थिति esp पैरामीटर फिक्स है ...)
EDIT # 5: समस्या पूरी तरह से हल
मैंने सब कुछ एक परीक्षण के माहौल में जाना और खरोंच से शुरू किया। मैं पुराने संस्करण के बजाय नवीनतम संस्करण (5.3.2) का उपयोग करके स्रोत से स्थापित किया गया था जो उबंटू रेपो (5.1.2) में था। यह मेरे द्वारा ऊपर दी गई समस्या को साफ़ करता है, और वीपीएन सुरंग के ऊपर कई सबनेट्स के बीच नेटकैट (बढ़िया टूल !!) का उपयोग करके परत 7 कनेक्टिविटी को सत्यापित करता है।
यह भी: VPC के लिए DNS होस्टनाम को सक्षम करने के लिए यह आवश्यक नहीं है (जैसा कि मुझे अमेज़ॅन द्वारा गलत तरीके से विश्वास किया गया था), FYI>
आशा है कि यह सब मदद करता है !!!!!!
अतिरिक्त संपादन 2/11/2017:
JustEngland के अनुरोध के अनुसार, नीचे काम कर रहे कॉन्फ़िगरेशन को कॉपी करना (किसी भी तरह से पहचान को रोकने के लिए कुछ विवरणों को छोड़कर):
पक्ष एक:
# 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"
साइड बी:
# 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"