LAN राउटर आणि VPN क्लायंट: दोन उपकरणे, दोन रूट टेबल

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

रूटला हात लावण्यापूर्वी दोन हॉप काढा

एक उदाहरणात्मक मांडणी घ्या: LAN होस्ट 192.168.50.0/24 वर, सामान्य राउटर 192.168.50.1 वर, समर्पित क्लायंट 192.168.50.15 वर, आणि दूरचे LAN 10.60.0.0/24 वर जे फक्त त्या क्लायंटकडील टनेलमधून पोहोचण्यायोग्य आहे. दोन खाजगी श्रेणींपैकी एकही दुसऱ्याला ओव्हरलॅप करत नाही, आणि टनेलची स्वतःची पत्ता योजना आहे.

दोन्ही खाजगी श्रेणी महत्त्वाच्या आहेत कारण कोणते उपकरण उत्तर देऊ शकते हे त्या ठरवतात. दूरची बाजू पॅकेट क्लायंटच्या टनेल पत्त्यावरून येताना पाहील, आणि तिच्या उत्तराला 192.168.50.0/24 कडे परत जाण्याचा मार्ग शोधावा लागेल. फक्त बाहेर जाणारी दिशा कॉन्फिगर केली तर विनंती कार्य करू शकते तर उत्तर गायब होते.

पायरी 1: राउटर टनेलकडे नाही, क्लायंटकडे वळवा

LAN राउटरवर, पुढील हॉप क्लायंटचा LAN पत्ता असलेला गंतव्य रूट जोडा:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

तो रेकॉर्ड सांगतो “ते अशा मशीनला पोहोचवा जी टनेल करू शकते”. टनेल कसा बांधला जातो याबद्दल ते काहीही सांगत नाही, आणि ते क्लायंटच्या स्वतःच्या रूटची जागा घेत नाही. व्यवस्थापित राउटरवर समतुल्य गोष्ट उपकरणाच्या स्थिर रूट पानावर असते; Linux राउटरवर ती LAN ची मालकी असलेल्या इंटरफेसच्या कॉन्फिगरेशनमध्ये असते, तुम्ही बंद करणाऱ्या शेलमध्ये नाही.

दुसऱ्या कमांडचे उत्तर तपासा. जर ते क्लायंटला gateway आणि LAN इंटरफेसला device म्हणून नोंदवते, तर पहिला हॉप बरोबर आहे आणि उर्वरित काम दुसऱ्या मशीनवर आहे.

पायरी 2: क्लायंटला टनेलच्या बाजूला त्याचा स्वतःचा रूट द्या

क्लायंट आता 10.60.0.0/24 साठी पॅकेट घेतो आणि स्वतःचे टेबल पाहतो. त्याच्या टनेल कॉन्फिगरेशनने त्या प्रीफिक्ससाठी रूट इन्स्टॉल केले असेल तर पॅकेट एन्क्रिप्टेड राहून पुढे जाते. नसेल तर पॅकेट सामान्य डीफॉल्टशी जुळते आणि 192.168.50.1 कडे परत जाते, जे ते पुन्हा क्लायंटकडे पाठवते.

काहीही जोडण्यापूर्वी पहा:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

प्रत्येक टेबलमध्ये प्रीफिक्स रूट नसणे हाच तुम्ही शोधत असलेला निष्कर्ष आहे. तो टनेलच्या स्वतःच्या कॉन्फिगरेशनद्वारे जोडा, जेणेकरून पुढील पुनर्कनेक्शन तो पुन्हा इन्स्टॉल करेल; हाताने केलेला ip route add सत्रासोबत नाहीसा होतो आणि सर्वात गैरसोयीच्या वेळी दोष परत आणतो. पुढील हॉप टनेल इंटरफेस आहे किंवा VPN त्याचा पीअर म्हणून देत असलेला पत्ता आहे, क्लायंटवर अवलंबून, आणि पीअर पत्ता जुन्या नोंदीतून नाही तर सध्याच्या प्रोफाइलमधून आला पाहिजे.

लूप, जेव्हा होतो, तेव्हा प्रत्यक्षात अमर्याद नसतो: प्रत्येक पासवर TTL कमी होतो आणि पॅकेट वेळ संपल्याच्या संदेशासह मरते. म्हणूनच वारंवार केलेला traceroute चक्र दर्शवू शकतो, तर फक्त फॉर्वर्ड न करणारा क्लायंट तोच पॅकेट शांतपणे टाकून देतो.

पायरी 3: फॉर्वर्डिंगला परवानगी द्या आणि परतण्याचा मार्ग निवडा

घेणे आणि फॉर्वर्ड करणे वेगवेगळ्या परवानग्या आहेत. क्लायंटवरचे net.ipv4.ip_forward=1 कर्नेल स्तरावर ट्रान्झिटला परवानगी देते, आणि फायरवॉल नियमाला ते LAN इंटरफेस आणि टनेलमध्ये परवानगी द्यावी लागतेच. क्लायंटच्या स्वतःच्या व्यवस्थापन पानात प्रवेशाला परवानगी देणारा नियम दूरच्या LAN मध्ये ट्रान्झिटला परवानगी देणार नाही, आणि तोच होस्ट स्थानिक पातळीवर ping ला उत्तर देत असताना हा फरक चुकणे सोपे आहे.

दूरच्या बाजूला आरशासारखी समस्या आहे. 192.168.50.0/24 या प्रमाणित क्लायंटमार्फत पोहोचण्यायोग्य आहे हे तिला माहीत असले पाहिजे. OpenVPN सोबत हे सहसा सर्व्हर कॉन्फिगरेशन ढकलत असलेला प्रति-क्लायंट रूट, किंवा सर्व्हरवर क्लायंटच्या मागील LAN घोषित करणारी क्लायंट-विशिष्ट फाइल असा अर्थ होतो. ते नसेल तर दूरचे LAN एकतर उत्तर टाकून देते किंवा ते त्याच्या स्वतःच्या डीफॉल्ट गेटवेवर, म्हणजे इंटरनेटवर पाठवते.

LAN प्रीफिक्स घोषित करता येत नाही तेव्हा स्रोत भाषांतर हा पर्याय आहे. क्लायंटवरील मर्यादित masquerade नियम स्रोत टनेल पत्त्यावर पुन्हा लिहितो, आणि उत्तरे नंतर नैसर्गिकपणे परत येतात. कोणत्या LAN होस्टने विनंती केली हेही तो लपवतो, आणि स्वतःच दूरच्या बाजूला आत जाणाऱ्या कनेक्शन्स सुरू करण्याची परवानगी देत नाही. सर्वव्यापी masquerade जोडून नंतर दुष्परिणाम शोधण्याऐवजी हा तडजोड जाणीवपूर्वक निवडा.

पायरी 4: दोन्ही निर्णय टिकाऊ करा, नंतर प्रत्यक्ष मार्ग तपासा

प्रत्येक रूटला मालक असतो, आणि मालक म्हणजे बूट किंवा पुनर्कनेक्शनला पुन्हा तयार होणारे कॉन्फिगरेशन. राउटरवर तो स्थिर रूट नोंद असू शकतो; क्लायंटवर तो VPN प्रोफाइल, NetworkManager किंवा systemd-networkd असू शकतो. टनेल पुन्हा जोडून आणि क्लायंट रीबूट करून पडताळा, नंतर बदलावर विश्वास ठेवण्याऐवजी टेबल पुन्हा वाचा.

टनेलचे बाह्य कनेक्शन वाहणारा डीफॉल्ट रूट अभंग ठेवा. सेटअप “सोपा” करण्यासाठी तो बदलल्यास कोणताही अंतर्गत रहदारी तो वापरण्यापूर्वीच एन्क्रिप्टेड मार्ग तुटतो, आणि लक्षण म्हणजे बदलानंतर पुन्हा कधीही स्थापित न होणारा टनेल.

सामान्य LAN होस्टवरून तपासा, क्लायंटवरून नाही, कारण क्लायंटवर सुरू झालेली विनंती कधीही राउटरचा पहिला हॉप वापरत नाही. फक्त दूरच्या LAN वर असलेली सेवा आणा आणि उत्तराचा मुख्य भाग पुष्टी करा, नंतर ट्रान्झिट होत असल्याचे पाहण्यासाठी क्लायंटचे काउंटर किंवा लॉग पहा. खाजगी हॉप दाखवणारा अंतर्गत traceroute फॉर्वर्डिंग सिद्ध करतो, एन्क्रिप्शन नाही: बाह्य मार्ग वेगळे निरीक्षण आहे, आणि फक्त टनेलच्या स्वतःच्या इंटरफेस काउंटरवरून काय बाहेर गेले हे दिसते.