LAN सर्भरमा VPN क्लाइन्ट: जवाफहरू किन गलत बाटोबाट बाहिरिन्छन्

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

जवाफ नयाँ प्याकेट हो, बाटोको उल्टो यात्रा होइन

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

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

बाँकी पढ्दा दुई उपसञ्जाल सम्झनुहोस्। एउटा दूरका क्लाइन्टहरू आउने VPN ठेगाना पूल हो, यो उदाहरणमा 10.64.0.0/24। अर्को काम गरिरहनुपर्ने LAN हो, 172.16.24.0/24, यसको राउटर 172.16.24.1 मा। दोष यो हो कि तिनीहरूबीचको ट्राफिक पूर्वनिर्धारित रुटले निर्धारण गर्छ।

क्याप्चर र लुकअपले यो प्रमाणित गर्नुहोस्

केही बदल्नु अघि जवाफले कुन उपकरण प्रयोग गर्ने हो त्यो पुष्टि गर्नुहोस्। लुकअप क्याप्चरभन्दा छिटो हुन्छ र प्याकेट बन्दा कर्नेलले जुन प्रश्नको जवाफ दिन्छ ठ्याक्कै त्यही प्रश्नको जवाफ दिन्छ।

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

जवाफ दुई भागमा पढ्नुहोस्। यदि यसले dev tun0 भन्छ भने, होस्टले जवाफ इन्क्याप्सुलेट गरी प्रदायकलाई दिन्छ, र LAN क्लाइन्टले त्यो कहिल्यै देख्दैन। यदि यसले dev eth0 भन्छ तर क्लाइन्टले अझै समय सकिएको पाउँछ भने, मार्ग पहिले नै सही छ र प्याकेट पछि फ्याँकिन्छ, जुन अर्को समस्या र अर्को समाधान हो।

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

सुरुङलाई उछिन्ने सबैभन्दा साँघुरो मार्ग स्थापना गर्नुहोस्

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

दोस्रो add को सट्टा replace प्रयोग गर्नुहोस्, किनभने फेरि जोडिने क्लाइन्टले पहिले नै आफ्नै प्रविष्टि स्थापना गरिसकेको हुन्छ र दोस्रो add अनुमति समस्याजस्तो पढिने अवस्थित मार्ग त्रुटिले असफल हुन्छ। Windows होस्टमा समतुल्य route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p हो, जहाँ -p रिबुटभरि प्रविष्टि राख्छ, किनभने सुरुङ फेरि माथि आउँदा क्लाइन्टले तालिका पुनर्निर्माण गर्न सक्छ। आधुनिक Windows होस्टमा समर्थित समतुल्य New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore हो, र पुरानो route आदेश लिगेसी रूपमा राखिएको छ।

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

फेरि जोडिएपछि पनि जवाफ कायम राख्नुहोस्

हातले थपिएको मार्ग धेरैमा अर्को पुनःजडानसम्म टिक्छ। क्लाइन्ट पूल गतिशील भए सर्भर कन्फिगरेसनमा पिन गर्नुहोस्, जसले तपाईंले राउट गरेको प्रिफिक्स क्लाइन्टहरूले पाउने प्रिफिक्स नै रहोस्; नत्र प्रविष्टि खाली दायरातर्फ सङ्केत गर्छ र लक्षण हप्ताहरूपछि स्पष्ट कारणबिना फर्किन्छ। मार्ग क्लाइन्टकै up-स्क्रिप्टमा लेख्नु अर्को भरपर्दो विकल्प हो, किनभने क्लाइन्टले तालिका पुनःलेखेपछि त्यो चल्छ।

अवस्था भएको फायरवालले सही मार्गलाई पनि पराजित गर्न सक्छ। क्याप्चरले अब जवाफ eth0 बाट बाहिरिन्छ देखाउँछ र क्लाइन्टले अझै समय सकिएको पाउँछ भने, होस्टले पठाउनुअघि प्याकेट फ्याँकिरहेको छ कि जाँच्नुहोस्। कडा रिभर्स-पाथ फिल्टरिङ र net.ipv4.conf.all.rp_filter लाई 1 मा राख्दा, जुन इन्टरफेसबाट आयो त्यहीँबाट फर्केर राउट नहुने स्रोत भएका प्याकेटहरू फ्याँकिन्छन्, र यो ठ्याक्कै त्यही असममित अवस्था हो जुन तपाईंले भर्खरै बनाएर पछि सुधार्नुभयो, र conntrack अवस्थाले अगाडि पठाइएका पोर्टहरूका लागि पनि त्यही कथा भन्छ।

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