राउटिंग टेबल विरुद्ध वास्तविक लुकअप: VPN रहदारी कुठे जाते

राउटिंग टेबलचा डंप VPN समस्या निवारणातील सर्वात कमी उपयुक्त निदान आहे आणि सर्वात जास्त पेस्ट केला जातो। चाळीस ओळींचे प्रीफिक्स तुम्हाला सांगतात मशीन काय करू शकली असती, अयशस्वी विनंतीसाठी काय केले हे नाही। तुम्हाला प्रत्यक्षात हवी असलेली यंत्रणा म्हणजे लुकअप: हा स्रोत आणि हे गंतव्यस्थान दिल्यास कोणता नियम जुळला, कोणते टेबल पाहिले गेले, आणि कोणते इंटरफेस व पुढील हॉप बाहेर पडले। एका गंतव्यस्थानापासून आणि एका स्रोतापासून सुरुवात करा, नंतर तो प्रश्न हातात घेऊन टेबल वाचा, आणि तेच आउटपुट गोंगाटाऐवजी पुरावा बनते।

टेबल उमेदवारांचा संच आहे, निर्णय नाही

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

लुकअप आधी नियमांमधून, नंतर टेबलांमधून जातो

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

IPv6 ला स्वतःचे नियम आणि टेबल आहेत। दोन्ही कुटुंबे चालवणाऱ्या डिझाइनला दोन्ही लुकअप हवेत, आणि कार्यरत IPv4 उत्तर v6 मार्गाबद्दल काहीही सांगत नाही जो दुहेरी-स्टॅक क्लायंटला आवडू शकतो।

VPN क्लायंट काय स्थापित करतो

क्लायंट सहसा डीफॉल्ट रूट बदलत नाहीत, कारण त्यामुळे टनेलचा स्वतःचा बाह्य मार्ग तुटेल। ते अधिक विशिष्ट असे काही स्थापित करतात जे प्रीफिक्स लांबीने जिंकते: 0.0.0.0/1 आणि 128.0.0.0/1 व्यापणारी अर्ध-डीफॉल्ट जोडी ही क्लासिक युक्ती आहे, कारण दोन्ही 0.0.0.0/0 पेक्षा लांब प्रीफिक्स आहेत आणि एकत्रितपणे संपूर्ण जागा व्यापतात। इतर विशिष्ट खाजगी प्रीफिक्स आणि धोरण नियम स्थापित करतात, आणि काही फक्त निवडलेली रहदारी पकडली जावी म्हणून मार्क जोडतात।

म्हणूनच "VPN ने माझा डीफॉल्ट रूट बदलला नाही" हा अपयशाचा पुरावा नाही। त्याने प्रत्यक्षात काय जोडले आणि प्रश्नातील गंतव्यस्थान त्या प्रीफिक्समध्ये येते का ते तपासा:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

बाह्य मार्गही टिकून राहिला पाहिजे

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

पीअरचा पत्ता आतील गंतव्यस्थान तपासल्याप्रमाणे तपासा, आणि तो टनेलऐवजी भौतिक इंटरफेसवर सोडवला जातो याची खात्री करा:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

पुनरावृत्ती मार्ग, पीअर पकडणारा धोरण नियम, किंवा पूर्ण-टनेल क्लायंटने बदललेला डीफॉल्ट ही तीन सामान्य कारणे आहेत। तीनही बाह्य लुकअपमध्ये दिसतात, आणि घटनेनंतर घेतलेल्या मुख्य टेबलच्या डंपमध्ये एकही दिसत नाही।

राउटिंग आउटपुट तुम्हाला काय सांगू शकत नाही

योग्य लुकअप म्हणजे कर्नेल पॅकेट कुठेतरी योग्य ठिकाणी पाठवेल। याचा अर्थ फायरवॉल परवानगी देतो, IPsec धोरण ते व्यापते, NAT नियम त्याचे भाषांतर करतो, किंवा दूरच्या बाजूला परतीचा मार्ग आहे असा नाही। त्यातील प्रत्येक पुढील टप्पा आहे, आणि strongSwan च्या फॉरवर्डिंग नोट्स दोन्ही टोकांवर पॅकेटने पार कराव्या लागणाऱ्या साखळीचे वर्णन करतात।

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

म्हणून निदान क्रमाने ठेवा: गंतव्यस्थान आणि स्रोताचे नाव घ्या, लुकअप चालवा, लुकअपने नाव दिलेले टेबल आणि नियमच वाचा, नंतर पुढील टप्पा तपासा। हा क्रम राउटिंग तपासणी मिनिटांत ठेवतो आणि दुसऱ्याला अनुसरता येणारी नोंद ठेवतो, जे पेस्ट केलेले टेबल कधीही करत नाही।