VPN क्लाइन्टपछाडिको सर्भर किन सुरुङबाट जवाफ दिन्छ

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

जवाफ राउट हुन्छ, सम्झिइँदैन

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

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

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

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

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

फर्कने मार्ग जोगाउने तीन तरिका

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

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

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

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

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

बाकसले LAN का लागि पनि राउट गर्दा

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

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

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

कारणहरू अलग गर्ने तीन जाँच

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

पहिले राउटिङको प्रश्न सुधार्नुहोस्, त्यसपछि नाम हेर्नुहोस्। दुवै मिसाउनु भनेको काम गरिरहेको सर्भरलाई बिग्रिएको रिजोल्भरको दोष दिनु हो।

अपवादले कुन इन्टरफेसको नाम लिन्छ लेख्नुहोस् र कन्फिगरेसनलाई संस्करण नियन्त्रणमा राख्नुहोस्। अपग्रेडपछि नाम बदलिने इन्टरफेसविरुद्ध लेखिएको नियम आज पास हुन्छ र अर्को रिबुटपछि असफल हुन्छ।