रुटेड VPN क्लाइन्ट सर्भरसम्म पुग्छ तर LAN होस्टसम्म पुग्दैन

टनेल माथि आउँछ, क्लाइन्टले VPN सर्भरलाई पिङ गर्छ, र एक कदम परको मेसिनमा रहेको साझा फोल्डरले कहिल्यै जवाफ दिँदैन। क्लाइन्ट कन्फिगरेसनमा यसलाई व्याख्या गर्ने केही छैन, किनकि अनुरोध क्लाइन्टबाट साँच्चै गयो र साँच्चै पुग्यो। असफल भएको फर्कने यात्रा हो, र असफल भएको यन्त्र सामान्यतया VPN होस्ट नभई LAN गेटवे हो। जवाफ प्याकेट ट्रेस गर्दा यो सम्पूर्ण लक्षण वर्ग व्याख्या हुन्छ।

अनुरोध होइन, जवाफ पछ्याउनुहोस्

VPN सर्भरले क्लाइन्ट प्याकेट डिक्रिप्ट गर्छ र क्लाइन्टको ठेगाना स्रोत फिल्डमै राखेर यसलाई LAN मा फर्वार्ड गर्छ। गन्तव्य होस्टले त्यो ठेगानालाई जवाफ दिन्छ, र अब यसको आफ्नै रुटिङ तालिकाले सबै कुरा निर्धारण गर्छ। यसको पूर्वनिर्धारित गेटवेलाई टनेल पूलको बारेमा केही थाहा छैन, त्यसैले जवाफ इन्टरनेट प्रदायकतर्फ जान्छ र त्यो बाटोमा कतै फालिन्छ।

क्लाइन्टमा लक्षण शान्त टाइमआउट हो: कुनै अस्वीकार छैन, कुनै रिसेट छैन, बस केही छैन। साझा फोल्डर ब्राउज गर्दा अडिन्छ, पिङले जवाफ छैन भनी जानकारी दिन्छ, र सर्भर लगहरू स्वस्थ देखिन्छन् किनकि सर्भरले आफ्नो काम गर्यो।

रिटर्न रुट होस्टहरूले हेर्ने ठाउँमा राख्नुहोस्

हरेक LAN होस्टले आफ्नो पूर्वनिर्धारित गेटवेसँग सल्लाह लिन्छ, त्यसैले टनेल पूल कहाँ छ भनी थाहा हुनुपर्ने एक मात्र यन्त्र गेटवे हो। त्यहाँ स्थिर रुट थप्नुहोस् र हरेक होस्टले छुनु नपरी सही बाटो पाउँछ।

यदि गेटवेले आफ्नो ठेगाना DHCP विकल्पका रूपमा बाँड्छ भने, रुट पनि त्यही तरिकाले बाँड्नुहोस् ताकि नयाँ मेसिनहरूले स्वतः लिन्छन्। अन्यथा रुट एउटा कन्फिगरेसन फाइलमा रहन्छ र अर्को पुनर्निर्माणमा हराउँछ।

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

किन स्रोत NAT ले यसलाई सुधारेको जस्तो देखिन्छ

क्लाइन्ट पूललाई VPN सर्भरको ठेगाना पछाडि मास्क गर्दा प्याकेटबाट क्लाइन्टको ठेगाना हटाएर समस्या हटाउँछ। त्यसपछि जवाफहरू टनेलसम्म कसरी पुग्ने भनी पहिल्यै थाहा भएको सर्भरमा फर्कन्छन्, र सबै कुरा चल्छ। मूल्य यो हो कि आन्तरिक होस्टहरूले क्लाइन्ट को हो देख्न सक्दैनन्, र हरेक जडान एउटै मेसिनबाट आएको जस्तो देखिन्छ।

यो अदलबदल कहिलेकाहीँ सही हुन्छ, उदाहरणका लागि जब विक्रेताको उपकरणलाई स्थिर रुट दिन सकिँदैन। नियमलाई हालको पूलभन्दा फराकिलो नबनाउनुहोस्, किनकि /24 का लागि लेखिएको नियम पूल /16 मा पुनःक्रमाङ्कन हुने दिनदेखि मिल्न छाड्छ, र पहिलो संकेत भनेको जोडिने तर कतै नपुग्ने नयाँ क्लाइन्टको समूह हो।

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

क्लाउड बाटोलाई तीन सेटिङ चाहिन्छ

VPC मा त्यही खाली ठाउँ अर्को रूपमा फर्कन्छ, किनकि सबनेटसँग क्लाइन्ट दायराका लागि कुनै रुट छैन। रुट तालिकालाई टनेल पूलका लागि इन्स्टेन्सको नेटवर्क इन्टरफेस लक्षित गर्ने प्रविष्टि चाहिन्छ, र इन्टरफेसमा स्रोत र गन्तव्य जाँच बन्द हुनुपर्छ ताकि प्लेटफर्मले आफ्नै ठेगाना नभएको स्रोत भएका प्याकेट स्वीकार गर्छ। सुरक्षा समूह र नेटवर्क ACL ले पनि पूललाई दुवै दिशामा अनुमति दिनुपर्छ।

हरेक छुटाइले फरक आंशिक असफलता उत्पन्न गर्छ। रुट तालिकाको प्रविष्टि छोड्नुहोस् र निजी इन्स्टेन्सहरू जवाफ पूलमा फर्काउन नसक्ने सबनेटमा जवाफ दिन्छन्। जाँच चालु रहँदा, इन्स्टेन्सले पहिल्यै पठाइसकेपछि प्लेटफर्मले जवाफ फाल्छ। सुरक्षा समूह नियम बिना अनुरोध नै कहिल्यै पुग्दैन, र क्लाइन्टले टाइमआउट एक तह अगाडि देख्छ।

जाँचहरू यही क्रममा गर्नुहोस्

रुटिङलाई दोष दिनुअघि फर्वार्डिङ र फिल्टर नीति पुष्टि गर्नुहोस्, किनकि फर्वार्ड नगर्ने होस्ट पनि त्यही शान्त तरिकाले असफल हुन्छ। त्यसपछि टनेल बोक्ने इन्टरफेसमा प्रभावकारी रिभर्स-पाथ सेटिङ पढ्नुहोस्, किनकि कडा फिल्टरले अप्रत्याशित दिशाबाट आउने जवाफ फाल्न सक्छ।

क्लाइन्टले LAN होस्टलाई पिङ गर्दा त्यहाँ लिएको क्याप्चरसँग अन्त्य गर्नुहोस्। मिल्ने जवाफ बिना आउने अनुरोधले फर्कने बाटो प्रमाणित गर्छ, र कहिल्यै नआउने अनुरोधले दोष सर्भर वा टनेलतर्फ फर्काउँछ।

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

स्रोत र गन्तव्य जाँच इलास्टिक नेटवर्क इन्टरफेस गाइडमा अभिलेख गरिएको छ। यसलाई टनेल ट्राफिक साँच्चै बोक्ने इन्टरफेसमा सेट गर्नुहोस्, त्यही इन्स्टेन्समा जोडिएको असम्बन्धित एडाप्टरमा होइन।