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 रुटिङका बारेमा प्रायः सोधिने प्रश्नहरू स्थापित संस्करणका लागि त्यही सिद्धान्त बताउँछ, जसको समर्थित कन्फिगरेसन इन्टरफेस पुराना मार्गदर्शिकाभन्दा फरक हुन सक्छ।