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 राउटिंगबद्दल वारंवार विचारले जाणारे प्रश्न स्थापित आवृत्तीसाठी तोच सिद्धांत सांगते, जिचा समर्थित कॉन्फिगरेशन इंटरफेस जुन्या मार्गदर्शकांपेक्षा वेगळा असू शकतो।