GCE वर OpenVPN: रूट push करण्यापूर्वी alias IP जोडा

एक क्लायंट Compute Engine VM वरच्या OpenVPN सर्व्हरला डायल करतो, स्टेटस विंडो म्हणते जोडलेले, आणि VPC मधील होस्टला ping अजूनही कुठेही पोहोचत नाही. सहज प्रवृत्ती म्हणते अजून एक push ओळ जोडा, आणि त्याने कधीच बरा होत नाही. Compute Engine स्वतःच्या रूट तक्त्यावर आणि VM इंटरफेसकडे प्रत्यक्षात असलेल्या पत्त्यांवरून पॅकेट कुठे जातील हे ठरवते, म्हणून जो tunnel pool VM च्या मालकीचा नाही तो असा pool आहे जिथे कोणी पोहोचवत नाही.

कॉन्फिगरेशन फाइलऐवजी अयशस्वी होणाऱ्या पॅकेटचा मागोवा घ्या, आणि गहाळ भाग क्रमाने दिसतील.

मरणाऱ्या पॅकेटपासून सुरुवात करा

SYN क्लायंट सोडतो, tunnel मध्ये प्रवेश करतो आणि VPC मधील गंतव्यासाठी encapsulated पॅकेट म्हणून VM पर्यंत पोहोचतो. OpenVPN ते decapsulate करते आणि eth0 मधून पाठवण्याचा प्रयत्न करते, जिथे fabric सर्वांपूर्वी एक प्रश्न विचारते: हे instance गंतव्य पत्त्याचे मालक आहे का. दुसऱ्याच्या subnet मधून कापलेला tunnel pool त्या प्रश्नात अयशस्वी होतो, आणि कोणताही रूट किंवा firewall नियम पाहण्यापूर्वी पॅकेट टाकून दिले जाते.

म्हणून क्लायंटकडून VPC कडे जाणाऱ्या दिशेला दोन वेगळ्या आवश्यकता आहेत, आणि त्यातील एकही push सूचना नाही. VM ला tunnel pool व्यापणारी alias श्रेणी हवी, आणि तीच त्याला त्या पत्त्यांचा कायदेशीर मालक बनवते. VPC ला असा रूट हवा जो प्रत्येक संरक्षित prefix साठी VM ला next hop म्हणून नाव देईल. एकही गहाळ झाला तर पॅकेट दुसरीकडे मरते, तर क्लायंटला तीच शांतता दिसते.

बिघाड त्याच क्रमाने वाचा, कारण क्लायंटच्या बाजूने दोन्ही अटी सारख्याच दिसतात. जो tunnel जोडलेले सांगतो पण काहीही उत्तर देत नाही तो टोपोलॉजी समस्येचा संकेत आहे, वाईट cipher चा नाही.

instance tunnel pool चा मालक आहे का

VM ला त्याच्या स्वतःच्या subnet मध्ये दुय्यम श्रेणी द्या, मग OpenVPN नेमके त्याच श्रेणीतून पत्ते वाटू द्या. ज्या instance चा प्राथमिक पत्ता 10.156.0.10/20 आहे, तिथे /28 alias pool ला इतर instance जवळ आधीच असलेल्या पत्त्यांपासून वेगळे ठेवतो:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

मग server सूचनेने तोच ब्लॉक वर्णन केला पाहिजे. तिचा पहिला पत्ता tunnel चा gateway होतो, आणि उर्वरित पत्ते क्लायंटना दिले जातात. इथे दोन संख्या एक ब्लॉक वर्णन करतात, एक नेटवर्क आणि एक netmask, आणि हाच तो pool सिंटॅक्स आहे ज्याची OpenVPN अजूनही अपेक्षा करते.

server 10.156.1.0 255.255.255.240

पत्ता खरोखर इंटरफेसवर पोहोचला आहे याची खात्री करा, केवळ OpenVPN कॉन्फिगरेशनमध्ये नाही. fabric जे NIC कळवते ते पाठवते, daemon जे मानते ते नाही. एक आदेश हे ठरवतो:

ip -4 addr show dev eth0

दुय्यम पत्ता जो कधीच eth0 पर्यंत पोहोचत नाही, किंवा दुसऱ्या subnet शी ओव्हरलॅप होणारा pool, नंतर सुरुवातीची चूक म्हणून नाही तर अधूनमधून पॅकेट हानी म्हणून दिसतो. daemon सुरू होतो, क्लायंट जोडले जातात, आणि फक्त काही गंतव्ये चुकीचे वागतात. रूट तक्त्यात pool सहज ओळखता यावा म्हणून alias श्रेणी लहान ठेवा. दुसरे instance आधीच वापरत असलेल्या subnet मधून ती कधीच कापू नका.

परतीच्या ट्राफिकला next hop द्या

VPC मधील होस्टकडून आलेले उत्तर tunnel pool मधील क्लायंट पत्त्याला पाठवले जाते, जो VPC ला माहीत असलेल्या कोणत्याही subnet चा भाग नाही. त्या pool साठी रूट नसेल तर उत्तर जुळणी नसलेल्या पहिल्या hop वर थांबते, आणि विनंती पलीकडे यशस्वी झाली असेलही.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

तोच रूट VPC मध्ये नाही तर क्लायंटच्या मागे असलेल्या प्रत्येक prefix साठी लागतो. त्या prefix ना त्या क्लायंटच्या ccd फाइलमध्ये iroute नोंदही लागते. ती नोंद सर्व्हर बाजूची हिशोबनोंद आहे: ती सर्व्हरला सांगते कोणता क्लायंट prefix चा मालक आहे, आणि क्लायंटवरच काहीही इन्स्टॉल करत नाही.

push यादी संभाषणाच्या क्लायंट बाजूसाठी ठेवा, कारण ती फक्त जोडणाऱ्या मशीनवर रूट जोडते. VPC subnet साठीची push ओळ आणि pool कडे परत जाणारा VPC रूट एकाच मार्गाचे दोन अर्धे आहेत, आणि कोणताही अर्धा एकटा असा tunnel तयार करतो जो विनंत्या नेतो पण उत्तरे नाही.

Firewall, forwarding आणि मधले hop

VPC चा firewall decapsulated पॅकेटचे मूल्यांकन करतो, म्हणून ingress नियमाने tunnel pool आणि त्या मार्गाने VM पर्यंत पोहोचणाऱ्या प्रत्येक site prefix ला परवानगी दिली पाहिजे. default-deny धोरण इथे शांतपणे अयशस्वी होते: decapsulation नंतर पॅकेट टाकून दिले जाते, आणि OpenVPN लॉग निरोगी सत्र दाखवतो.

terminate न करता forward करणाऱ्या प्रत्येक Linux होस्टवर net.ipv4.ip_forward सुरू आहे का ते तपासा. मालकीचा नियम तिथेही लागू होतो: जे मशीन स्वतःकडे नसलेल्या subnet साठी forward करते ते VM प्रमाणेच पॅकेट टाकून देते. tunnel ला दोष देण्यापूर्वी मूल्य वाचा.

जेव्हा नेमका एक prefix अयशस्वी होतो

अंशतः अयशस्वी होणे हे वाचायला सर्वात सोपे प्रकरण आहे, कारण मार्गावरील बाकी सर्व आधीच सिद्ध झाले आहे. रूट यादीपासून सुरुवात करा आणि जी नोंद prefix व्यापायला हवी तिची गंतव्य श्रेणी आणि next hop वाचा, मग instance चे वर्णन वाचून त्याची alias श्रेणी सर्व्हरने वाटलेल्या pool शी तुलना करा.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

गहाळ रूट prefix साठी next hop नसल्यासारखा दिसतो, तर गहाळ alias इंटरफेसवर टाकून दिलेले पॅकेट असे दिसते; क्लायंटकडून दोन्ही सारखे दिसतात आणि त्या दोन आउटपुटमध्ये पूर्णपणे वेगळे असतात. दोन्ही असतील तर उरलेला संशयित त्या क्लायंटचा ccd iroute आहे जो prefix चा दावा करतो.

चार मूल्ये tunnel जवळ लिहा: alias श्रेणी, सर्व्हरचा pool, push केलेले prefix, VPC रूट. जुना alias pool मधील प्रत्येक पत्ता तोडतो, जुना रूट एक दिशा तोडतो, गहाळ push क्लायंटपासून prefix लपवते, आणि चुकीचा iroute prefix चुकीच्या peer कडे पाठवतो. पुढच्या व्यक्तीला जो subnet जोडेल त्याला चारही एकाच ठिकाणी लागतात, आणि ही नोंद संध्याकाळपेक्षा स्वस्त आहे.