Access Server के क्लाइंट LAN से क्यों पहुँच से बाहर हैं

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

सेवा जो स्रोत पता देखती है, उसे पढ़ें

वही एक फ़ील्ड बाकी सब तय करता है। अगर आंतरिक सेवा को पूल पता दिखता है, तो Access Server क्लाइंट ट्रैफ़िक छिपाने के बजाय रूट कर रहा है, और हर उत्तर को पूल तक वापस रूट करना होगा। अगर उसे इसके बजाय सर्वर का अपना निजी पता दिखता है, तो सर्वर मास्करेड कर रहा है और वापसी मार्ग पहले से काम करता है, पर सेवा के लॉग और एक्सेस नियमों में प्रत्येक क्लाइंट की पहचान खोने की कीमत पर।

कुछ भी बदलने से पहले दोनों सिरों की तुलना करें। सर्वर पर टनल इंटरफ़ेस और उनके पते सूचीबद्ध करें; क्लाइंट पर पुष्टि करें कि वह वास्तव में इनमें से कौन-सा पता रखता है; आंतरिक होस्ट पर एक जीवंत कनेक्शन देखें।

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

आखिरी कमांड वही है जो टूटी स्थिति में विफल होती है: वह या तो टनल प्रीफ़िक्स को अप्राप्य बताती है, या, इससे बुरा, आपका डिफ़ॉल्ट गेटवे लौटा देती है, और इसी तरह उत्तर इंटरनेट पर पहुँच जाते हैं।

यह न मानें कि एक ही पूल है। सर्वर में गतिशील रेंज के साथ प्रति-उपयोगकर्ता स्थिर मैपिंग भी हो सकती है, और स्थिर पता गतिशील प्रीफ़िक्स से पूरी तरह बाहर हो सकता है। अगर आप केवल वही रेंज रूट करते हैं जो आपको याद है, तो स्थिर पतों वाले उपयोगकर्ता टूटे रहते हैं और बाकी सब समस्या हल होने की रिपोर्ट करते हैं।

जहाँ उत्तर तय होता है, वहाँ मार्ग जोड़ें

मार्ग उस गेटवे पर है जो आंतरिक सेवा पहले से उपयोग करती है, सेवा पर नहीं, जब तक कि वह अपना ट्रैफ़िक स्वयं रूट न करे। इसे Access Server के पहुँच-योग्य निजी पते की ओर इंगित करें, जो क्लाइंट के टनल पते से भिन्न मान है।

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

क्लाउड नेटवर्क में वही कथन रूट तालिका की प्रविष्टि बन जाता है जिसका लक्ष्य वह इंस्टेंस या नेटवर्क इंटरफ़ेस है जिस पर सर्वर चलता है, और उस इंटरफ़ेस पर स्रोत और गंतव्य जाँच बंद रहती है। ध्यान दें कि वह प्रविष्टि क्या नहीं करती: मार्ग एक्सेस देने का साधन नहीं है, इसलिए सुरक्षा समूह, नेटवर्क ACL और होस्ट फ़ायरवॉल को अब भी ट्रैफ़िक की अनुमति देनी होगी।

इसे स्थायी बनाएँ, और पूल के आकार ईमानदार रखें। दो असंयुक्त पूलों को दो मार्ग चाहिए, और कॉन्फ़िगर किए गए प्रीफ़िक्स से आगे बढ़ता पूल चुपचाप ऐसे क्लाइंट बनाता है जिनके उत्तरों के पास जाने की कोई जगह नहीं होती। अगर आप पूल रेंज नियंत्रित करते हैं, तो ऐसा सारांश चुनें जिसे एक बार रूट करके छोड़ा जा सके।

फ़ॉरवर्डिंग और फ़िल्टर मार्ग से सहमत होने चाहिए

रूटिंग रास्ते का केवल आधा हिस्सा है। सर्वर को टनल और निजी इंटरफ़ेस के बीच फ़ॉरवर्ड करने की अनुमति होनी चाहिए, जिसका लिनक्स पर अर्थ है net.ipv4.ip_forward के साथ एक फ़ॉरवर्ड श्रृंखला जो इंटरफ़ेस की जोड़ी को अनुमति दे, और कठोर होस्ट पर आमतौर पर हर दिशा के लिए स्पष्ट नियम।

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

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

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

रूटेड या मास्करेड: सचेत रूप से चुनें

रूटेड मोड क्लाइंट का पूल पता सेवा पर सुरक्षित रखता है, जिससे प्रति-क्लाइंट लॉगिंग और प्रति-क्लाइंट नीति संभव होती है, और बदले में हर आंतरिक नेटवर्क जिसे किसी क्लाइंट को उत्तर देना है उसे पूल मार्ग चाहिए। मास्करेड मोड यह आवश्यकता हटा देता है क्योंकि उत्तर सर्वर पर लौटते हैं, पर सेवा अब एक क्लाइंट को दूसरे से अलग नहीं कर सकती और किसी विशेष क्लाइंट की ओर कुछ आरंभ नहीं कर सकती।

चालू सर्वर पर उस व्यवहार को बदलने से मौजूदा सत्र टूट जाते हैं, इसलिए पहले एक क्लाइंट और एक प्रवाह से परीक्षण करें। अगर बदलाव सही उत्तर है, तो यह सर्वर पर कॉन्फ़िगरेशन का निर्णय है, ऐसी चीज़ नहीं जिसे बाद में अनावश्यक हो जाने वाले मार्ग जोड़कर टाला जाए।

क्लाइंट के पीछे का सबनेट अलग कार्य है

लैपटॉप के अपने LAN पर किसी डिवाइस तक पहुँचना लैपटॉप के टनल पते तक पहुँचने के समान नहीं है। इसके लिए क्लाइंट को सबनेट गेटवे की तरह काम करना होगा: क्लाइंट पक्ष का घोषित नेटवर्क, क्लाइंट के ऑपरेटिंग सिस्टम पर फ़ॉरवर्डिंग सक्षम, और उस LAN पर क्लाइंट की ओर वापसी मार्ग। लैपटॉप की घरेलू रेंज के लिए निजी नेटवर्क मार्ग जोड़ने से यह नहीं होता, और जब दो उपयोगकर्ताओं की घरेलू रेंज एक ही हो तो यह टकराव पैदा करता है।

दिशा भी नीति का प्रश्न है। क्लाइंट को आंतरिक सेवा से कनेक्शन खोलने की अनुमति अपने आप आंतरिक होस्ट को उस क्लाइंट से कनेक्शन खोलने की अनुमति नहीं देती। रास्ते को टूटा मानने से पहले सर्वर की एक्सेस नीति और क्लाइंट के होस्ट फ़ायरवॉल की जाँच करें।

एक प्रवाह और एक कैप्चर से सत्यापित करें

सामान्य पहुँच परीक्षण के बजाय एक ही कनेक्शन से मार्ग सिद्ध करें। दोनों सिरों पर वही प्रवाह देखें: सेवा पर पहुँचता अनुरोध और उसे छोड़ता उत्तर।

tcpdump -ni any host 10.90.0.25 and port 443

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

उन चार जाँचों के साथ समाप्त करें जो इसे बंद करती हैं: सेवा पर स्रोत पता आपके इच्छित मोड से मेल खाता है, गेटवे के पास उपयोग में आने वाले हर पूल का मार्ग है, फ़ॉरवर्डिंग और फ़िल्टर दोनों दिशाओं को अनुमति देते हैं, और एक वास्तविक प्रवाह शुरू से अंत तक पूरा होता है। Access Server रूटिंग के अक्सर पूछे जाने वाले प्रश्न स्थापित संस्करण के लिए वही सिद्धांत बताता है, जिसका समर्थित कॉन्फ़िगरेशन इंटरफ़ेस पुरानी मार्गदर्शिकाओं से भिन्न हो सकता है।