VPN मार्गातील पुढील हॉप: गेटवे स्थानिक पातळीवर पोहोचण्यायोग्य का असावा

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

ही रनबुक सामान्य प्रकरणाचा समावेश करते: 192.168.20.0/24 वर लॅपटॉप, 192.168.20.5 LAN पत्ता असलेला VPN गेटवे, आणि त्या गेटवेमागील दूरचे नेटवर्क 10.70.0.0/24। खालील सर्व आदेश तुम्ही लॅपटॉपवर आहात असे गृहीत धरतात, अन्यथा सांगितले नसल्यास।

दोन पत्ते, एक मार्ग

इच्छित नोंद 10.70.0.0/24 via 192.168.20.5 आहे। प्रीफिक्स सांगतो पॅकेट कुठे जात आहे; via पत्ता सांगतो ते तिथे कोण नेत आहे। कर्नल तुम्ही नाव दिलेल्या इंटरफेसद्वारे ज्याच्या गेटवेपर्यंत पोहोचू शकत नाही असा मार्ग स्थापित करण्यास नकार देते, आणि तो नकार हाच संपूर्ण मुद्दा आहे: पोहोचण्यायोग्य होण्यासाठी ज्याला बोगदा लागतो तो पुढील हॉप बोगदा बांधणारा पुढील हॉप असू शकत नाही।

त्यामुळे पहिली तपासणी «गेटवे सुरू आहे का» नाही, तर «गेटवे या लिंकवर आहे का» ही आहे। लॅपटॉपचे स्वतःचे सबनेट, त्याची ARP किंवा शेजारी नोंद, आणि मार्गातील इंटरफेस — सर्वांनी जुळले पाहिजे। जो पत्ता फक्त 10.70.0.0/24 च्या आत अस्तित्वात आहे तो दुसऱ्या मार्गाचे गंतव्य असू शकतो, पण पहिल्याचा via कधीही नाही।

पुढील हॉप गेटवेवर काय बंधन टाकतो

लॅपटॉपवर मार्ग स्थापित करणे फक्त पहिले हस्तांतरण ठरवते। त्यानंतर गेटवेला स्वतःचा मार्ग लागतो: सक्षम केलेले फॉरवर्डिंग, 10.70.0.0/24 साठी बोगदा मार्ग, आणि कोण वापरू शकतो हे ठरवणारे कोणतेही प्रवेश धोरण। Linux वर ते net.ipv4.ip_forward=1 आणि बोगदा मार्ग आहे; त्यापुढील फायरवॉलला फॉरवर्ड होणाऱ्या प्रवाहास परवानगी देणारा नियम लागतो।

परतीची दिशा हा लोक विसरतात तो भाग आहे। दूरच्या बाजूला 192.168.20.0/24 कडे परतीचा मार्ग असावा, किंवा रचनेने लॅपटॉपचा स्रोत दूरच्या बाजूला माहीत असलेल्या एखाद्या गोष्टीत रूपांतरित केला पाहिजे। गेटवेवरून काम करणारा ping सिद्ध करतो की गेटवे दूरच्या नेटवर्कपर्यंत पोहोचू शकतो; लॅपटॉपची पॅकेट्स परतीच्या प्रवासात टिकतात का याबद्दल तो काहीही सांगत नाही।

जो होस्ट पाठवतो त्याच्याकडून लुकअप तपासा

कर्नलला विचारा की तो कोणता पुढील हॉप निवडेल, आणि उत्तरातील इंटरफेस वाचा:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

जर लुकअप गेटवे आणि LAN इंटरफेस नोंदवत असेल, तर पहिला टप्पा इच्छेप्रमाणे संरचित आहे। जर तो बोगदा उपकरण नोंदवत असेल, तर तक्त्यातील आधीची एखादी गोष्ट अधिक विशिष्ट आहे आणि जिंकत आहे। जर मार्ग अजिबात स्थापित होत नसेल, तर कर्नल तुम्हाला सांगत आहे की गेटवे पोहोचण्यायोग्य नाही, आणि तो संदेश कोणत्याही पॅकेट कॅप्चरपेक्षा अधिक उपयुक्त आहे।

नंतर योग्य ठिकाणाहून चाचणीची पुनरावृत्ती करा। गेटवेवर तयार केलेली विनंती गेटवेचा स्वतःचा स्रोत पत्ता वापरते, ज्यामुळे गहाळ परतीचा मार्ग किंवा फक्त काही स्रोतांना परवानगी देणारे धोरण लपू शकते। ip-route पुस्तिका गंतव्य, गेटवे आणि onlink ओव्हरराइड वेगळे करते, आणि ओव्हरराइड वापरण्यापूर्वी तो समजून घेणे योग्य आहे।

पोहोचण्याची क्षमता बनावट करण्यासाठी onlink वापरू नका

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

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

पॉइंट-टू-पॉइंट बोगदे Ethernet नाहीत

बोगदा उपकरण ARP करत नाही आणि बऱ्याचदा शेजाऱ्यांचे अर्थपूर्ण सबनेट नसते। त्याचे मार्ग बऱ्याचदा 10.70.0.0/24 dev tun0 सारखे दिसतात, कोणत्याही via शिवाय, कारण सहकारी हाच दुसरा एकमेव टोकबिंदू आहे। त्या तक्त्यात LAN शैलीचा via कॉपी केल्यास असा मार्ग तयार होतो जो कर्नल नाकारू शकतो किंवा, त्याहून वाईट, असा जो सहकाऱ्याने कधीही उत्तर न दिलेल्या पत्त्याकडे निर्देश करतो।

रनबुकमध्ये दोन्ही मॉडेल वेगळी ठेवा: LAN मार्गाला पोहोचण्यायोग्य गेटवे असतो, बोगदा मार्गाला इंटरफेस आणि सहकारी असतो। WireGuard, OpenVPN आणि IPsec सर्व थोड्या वेगळ्या आकारात दिसतात, म्हणून एका होस्टवरून सामान्यीकरण करण्याऐवजी तुम्ही खरोखर वापरलेला आकार नोंदवा।

जोडा, पुष्टी करा, मागे घ्या

संपूर्ण बदल तीन आदेश आणि एक तपासणी आहे, आणि तो त्याच क्रमाने लिहून ठेवावा:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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