GCE पर OpenVPN: रूट push करने से पहले alias IP जोड़ें

push किया गया रूट VM को next hop नहीं बनाता। alias IP रेंज जोड़ें, उसे सर्वर के pool से मिलाएँ और क्लाइंट जाँचने से पहले VPC में वापसी रूट बनाएँ।

एक क्लाइंट Compute Engine VM पर OpenVPN सर्वर को डायल करता है, स्टेटस विंडो कहती है जुड़ा हुआ, और VPC के अंदर एक होस्ट को ping अब भी कहीं नहीं पहुँचता। सहज प्रवृत्ति कहती है एक और push लाइन जोड़ें, और इससे कभी ठीक नहीं होता। Compute Engine अपनी ही रूट तालिका और VM इंटरफ़ेस के पास वास्तव में मौजूद पतों के आधार पर तय करता है कि पैकेट कहाँ जाएँगे, इसलिए जो tunnel pool VM के स्वामित्व में नहीं है वह ऐसा pool है जहाँ कोई पहुँचाता नहीं।

कॉन्फ़िगरेशन फ़ाइल की जगह असफल हो रहे पैकेट का पीछा करें, और गायब हिस्से क्रम में दिखेंगे।

मरते पैकेट से शुरू करें

SYN क्लाइंट छोड़ता है, tunnel में प्रवेश करता है और VPC के अंदर किसी गंतव्य के लिए encapsulated पैकेट के रूप में VM तक पहुँचता है। OpenVPN इसे decapsulate करता है और eth0 से आगे भेजने की कोशिश करता है, जहाँ fabric सबसे पहले एक सवाल पूछता है: क्या यह इंस्टेंस गंतव्य पते का मालिक है। किसी और के subnet से काटा गया tunnel pool उस सवाल में असफल होता है, और किसी भी रूट या firewall नियम को देखने से पहले पैकेट गिरा दिया जाता है।

इसलिए क्लाइंट से VPC दिशा की दो अलग आवश्यकताएँ हैं, और उनमें से कोई push निर्देश नहीं है। VM को tunnel pool को ढकने वाली alias रेंज चाहिए, और यही उसे उन पतों का वैध स्वामी बनाता है। VPC को ऐसा रूट चाहिए जो हर संरक्षित prefix के लिए VM को next hop के रूप में नाम दे। एक भी छूटे तो पैकेट कहीं और मरता है, जबकि क्लाइंट को वही खामोशी दिखती है।

खराबी को उसी क्रम में पढ़ें, क्योंकि क्लाइंट की ओर से दोनों शर्तें एक जैसी दिखती हैं। जो tunnel जुड़ा हुआ बताता है जबकि कुछ भी जवाब नहीं देता, वह टोपोलॉजी समस्या का संकेत है, खराब cipher का नहीं।

क्या इंस्टेंस tunnel pool का मालिक है

VM को उसके अपने subnet के अंदर गौण रेंज दें, फिर OpenVPN ठीक उसी रेंज से पते बाँटे। जिस इंस्टेंस का प्राथमिक पता 10.156.0.10/20 है, वहाँ /28 alias pool को दूसरे इंस्टेंस के पास पहले से मौजूद पतों से अलग रखता है:

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 तक नहीं पहुँचता, या pool जो किसी दूसरे subnet से ओवरलैप करता है, बाद में शुरुआती गलती के रूप में नहीं बल्कि रुक-रुक कर पैकेट हानि के रूप में दिखता है। daemon शुरू होता है, क्लाइंट जुड़ते हैं, और केवल कुछ गंतव्य गलत व्यवहार करते हैं। alias रेंज छोटी रखें ताकि रूट तालिका में pool आसानी से पहचाना जाए। इसे कभी उस 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

वही रूट हर उस prefix के लिए चाहिए जो VPC के अंदर नहीं बल्कि क्लाइंट के पीछे है। उन prefix को उस क्लाइंट की ccd फ़ाइल में iroute प्रविष्टि भी चाहिए। वह प्रविष्टि सर्वर पक्ष की बहीखाता है: वह सर्वर को बताती है कि कौन सा क्लाइंट prefix का मालिक है, और क्लाइंट पर स्वयं कुछ स्थापित नहीं करती।

push सूची बातचीत के क्लाइंट पक्ष के लिए रखें, क्योंकि वह केवल जुड़ने वाली मशीन पर रूट जोड़ती है। VPC subnet के लिए push लाइन और pool की ओर वापस VPC रूट एक ही मार्ग के दो आधे हैं, और कोई भी आधा अकेला ऐसा tunnel बनाता है जो अनुरोध ले जाता है पर जवाब नहीं।

Firewall, forwarding और बीच के hop

VPC का firewall decapsulated पैकेट का मूल्यांकन करता है, इसलिए ingress नियम को tunnel pool और हर उस site prefix की अनुमति देनी चाहिए जो उस रास्ते VM तक पहुँचता है। default-deny रवैया यहाँ चुपचाप असफल होता है: decapsulation के बाद पैकेट गिरा दिया जाता है, और OpenVPN लॉग स्वस्थ सत्र दिखाता है।

हर उस Linux होस्ट पर जो terminate करने की जगह forward करता है, देखें कि net.ipv4.ip_forward चालू है। स्वामित्व का नियम वहाँ भी लागू होता है: जो मशीन ऐसे subnet के लिए forward करती है जो उसके पास नहीं है वह VM की तरह पैकेट गिरा देती है। tunnel को दोष देने से पहले मान पढ़ें।

जब ठीक एक prefix असफल हो

आंशिक विफलता पढ़ने का सबसे आसान मामला है, क्योंकि रास्ते की बाकी हर चीज़ पहले ही सिद्ध हो चुकी है। रूट सूची से शुरू करें और उस प्रविष्टि की गंतव्य रेंज और next hop पढ़ें जिसे prefix ढकना चाहिए, फिर इंस्टेंस का विवरण पढ़ें और उसकी 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 जोड़ेगा चारों एक ही जगह चाहिए, और यह नोट शाम से सस्ता है।

संबंधित लेख