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

त्यही रुट 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 पढ्नुहोस्, त्यसपछि इन्स्ट्यान्सको विवरण पढेर यसको 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 थप्दा चारैवटा एकै ठाउँमा चाहिन्छ, र त्यो नोट साँझभन्दा सस्तो छ।

सम्बन्धित लेखहरू