राउटेड VPN क्लायंट सर्व्हरपर्यंत पोहोचतो पण LAN होस्टपर्यंत नाही

टनेल वर येते, क्लायंट VPN सर्व्हरला पिंग करतो, आणि एक पाऊल पुढच्या मशीनवरील सामायिक फोल्डर कधीही उत्तर देत नाही। क्लायंट कॉन्फिगरेशनमध्ये हे स्पष्ट करणारे काहीही नाही, कारण विनंती क्लायंटमधून खरोखर गेली आणि खरोखर पोहोचली। अयशस्वी झालेला परतीचा प्रवास आहे, आणि अयशस्वी झालेले उपकरण सहसा VPN होस्ट नसून LAN गेटवे असते। उत्तर पॅकेटचा मागोवा घेतल्यास हा संपूर्ण लक्षणवर्ग स्पष्ट होतो।

विनंती नाही, उत्तराचा मागोवा घ्या

VPN सर्व्हर क्लायंट पॅकेट डिक्रिप्ट करतो आणि क्लायंटचा पत्ता स्रोत फील्डमध्ये ठेवून ते LAN वर पाठवतो। गंतव्य होस्ट त्या पत्त्याला उत्तर देतो, आणि आता त्याचे स्वतःचे राउटिंग टेबल सर्व काही ठरवते। त्याच्या डीफॉल्ट गेटवेला टनेल पूलबद्दल काहीही माहीत नाही, म्हणून उत्तर इंटरनेट प्रदात्याकडे जाते आणि त्या मार्गावर कुठेतरी टाकून दिले जाते।

क्लायंटवर लक्षण शांत टाइमआउट आहे: नकार नाही, रीसेट नाही, फक्त काहीही नाही। सामायिक फोल्डर ब्राउझ करणे अडकते, पिंग उत्तर नसल्याचे सांगते, आणि सर्व्हर लॉग निरोगी दिसतात कारण सर्व्हरने आपले काम केले।

रिटर्न रूट तिथे ठेवा जिथे होस्ट पाहतात

प्रत्येक LAN होस्ट आपल्या डीफॉल्ट गेटवेचा सल्ला घेतो, म्हणून टनेल पूल कुठे आहे हे माहीत असणे आवश्यक असलेले एकमेव उपकरण गेटवे आहे। तिथे स्थिर रूट जोडा आणि प्रत्येक होस्टला स्पर्श न करता योग्य मार्ग मिळतो।

गेटवे आपला पत्ता DHCP पर्याय म्हणून वाटत असल्यास, रूट त्याच पद्धतीने वाटा जेणेकरून नवीन मशीन तो स्वयंचलितपणे घेतील। अन्यथा रूट एका कॉन्फिगरेशन फाइलमध्ये राहतो आणि पुढील पुनर्बांधणीत नाहीसा होतो।

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

स्रोत NAT ते दुरुस्त करत असल्यासारखे का वाटते

क्लायंट पूल VPN सर्व्हरच्या पत्त्यामागे मास्क करणे पॅकेटमधून क्लायंटचा पत्ता काढून समस्या दूर करते। मग उत्तरे टनेलपर्यंत कसे पोहोचायचे हे आधीच माहीत असलेल्या सर्व्हरकडे परत जातात, आणि सर्व काही चालते। किंमत ही आहे की अंतर्गत होस्टना क्लायंट कोण आहे हे दिसत नाही, आणि प्रत्येक कनेक्शन एका मशीनमधून आल्यासारखे दिसते।

ही अदलाबदल कधीकधी योग्य असते, उदाहरणार्थ जेव्हा विक्रेत्याच्या उपकरणाला स्थिर रूट देता येत नाही। नियम सध्याच्या पूलपेक्षा रुंद करू नका, कारण /24 साठी लिहिलेला नियम पूल /16 वर पुनर्क्रमांकित होणाऱ्या दिवशी जुळणे थांबवतो, आणि पहिले चिन्ह म्हणजे जोडले जातात पण कुठेही पोहोचत नाहीत अशा नवीन क्लायंटचा समूह।

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

क्लाउड मार्गाला तीन सेटिंग्ज लागतात

VPC मध्ये तीच पोकळी वेगळ्या स्वरूपात परत येते, कारण सबनेटकडे क्लायंट श्रेणीसाठी अजिबात रूट नाही। रूट टेबलला टनेल पूलसाठी इन्स्टन्सच्या नेटवर्क इंटरफेसकडे निर्देशित नोंद हवी, आणि इंटरफेसवर स्रोत व गंतव्य तपासणी बंद असणे आवश्यक आहे जेणेकरून प्लॅटफॉर्म स्वतःचा पत्ता नसलेल्या स्रोताचे पॅकेट स्वीकारेल। सुरक्षा गट आणि नेटवर्क ACL नेही पूल दोन्ही दिशांनी मंजूर केला पाहिजे।

प्रत्येक वगळणे वेगळे आंशिक अपयश निर्माण करते। रूट टेबलातील नोंद वगळली तर खाजगी इन्स्टन्स उत्तर पूलकडे परत नेऊ शकणाऱ्या सबनेटमध्ये उत्तर देतात। तपासणी सुरू असताना, इन्स्टन्सने आधीच पाठवल्यानंतर प्लॅटफॉर्म उत्तर टाकून देते। सुरक्षा गट नियमाशिवाय विनंतीच कधीही पोहोचत नाही, आणि क्लायंटला टाइमआउट एका स्तर आधी दिसतो।

तपासण्या याच क्रमाने करा

राउटिंगला दोष देण्यापूर्वी फॉरवर्डिंग आणि फिल्टर धोरणाची खात्री करा, कारण फॉरवर्ड न करणारा होस्टही त्याच शांत पद्धतीने अपयशी होतो। नंतर टनेल वाहून नेणाऱ्या इंटरफेसवर प्रभावी रिव्हर्स-पाथ सेटिंग वाचा, कारण कडक फिल्टर अनपेक्षित दिशेने येणारी उत्तरे टाकून देऊ शकतो।

क्लायंट LAN होस्टला पिंग करत असताना तिथे घेतलेल्या कॅप्चरने समारोप करा। जुळणारे उत्तर नसताना येणारी विनंती परतीचा मार्ग सिद्ध करते, आणि कधीही न येणारी विनंती दोष सर्व्हर किंवा टनेलकडे परत पाठवते।

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

स्रोत आणि गंतव्य तपासणी लवचिक नेटवर्क इंटरफेस मार्गदर्शकात नोंदवली आहे। ती टनेल ट्रॅफिक प्रत्यक्षात वाहून नेणाऱ्या इंटरफेसवर सेट करा, त्याच इन्स्टन्सला जोडलेल्या असंबंधित अडॅप्टरवर नाही।