स्थानिक रूट VPN च्या डीफॉल्ट रूटला का हरवतो

डेस्कवरील प्रिंटर टनेल वर आल्यावरही काम करत राहतो, तर दुसऱ्या कार्यालयातील सर्व्हर शांतपणे काहीतरी स्थानिकावर सोडवला जातो. दोन्ही वर्तन एकाच नियमातून येतात: सर्वात विशिष्ट रूट जिंकतो, आणि थेट जोडलेला प्रिफिक्स जितका विशिष्ट असू शकतो तितका असतो. सहसा तोच हवा असलेला डिझाइन असतो, आणि अशाच प्रकारे डुप्लिकेट खाजगी श्रेणी दूरचा पत्ता चोरते. आधी कर्नेलची निवड वाचल्यास गूढ बिघाड प्रिफिक्स तुलनेत बदलतो.

जोडलेला प्रिफिक्स डीफॉल्ट रूटपेक्षा अधिक विशिष्ट आहे

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

खाजगी पत्ता जागा अद्वितीय नाही, आणि दोन साइट्सनी एकच प्रिफिक्स निवडणे नियोजन करण्याइतके सामान्य आहे. श्रेणी ओव्हरलॅप झाल्यावर स्थानिक उत्तर पटकन येते आणि अधिकृत वाटते, त्यामुळे बिघाडाला लॉगिन समस्या म्हणून चुकीचे वाचणे सोपे आहे. गंतव्याने उत्तर दिले, फक्त तुम्हाला अभिप्रेत असलेले नाही.

कर्नेल जी निवड करेल ती वाचा

टेबल वरून वाचण्याऐवजी कर्नेलला विचारा की अचूक गंतव्यासाठी तो कोणता रूट वापरेल. नंतर दुसरे टेबल निवडू शकणारे धोरण नियम शोधा. दोन आदेश काही सेकंदात दोन्ही प्रश्नांची उत्तरे देतात.

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

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

स्थानिक प्रवेश ही वेगळी परवानगी आहे

रूट असणे म्हणजे तो वापरण्याची परवानगी असणे नव्हे. बहुतेक क्लायंट टनेल वर असताना स्थानिक नेटवर्क संवाद अडवू शकतात, आणि ते सेटिंग राउटिंगचा परिणाम नसून धोरणाचा निर्णय आहे. विश्वासार्ह जवळची सेवा डिझाइनचा भाग असल्यास रूट रचण्याऐवजी समर्थित स्थानिक-प्रवेश पर्याय सुरू करा. उपकरण सार्वजनिक Wi-Fi वर असल्यास तो बंद ठेवा.

दोन्ही थर वेगळ्या प्रकारे अपयशी होतात. अडवलेला स्थानिक मार्ग रूट असूनही कालबाह्यता देतो, तर ओव्हरलॅप होणारा रूट चुकीच्या होस्टकडून उत्तर देतो. त्यांना वेगळे करण्यासाठी एक चौकशी पुरते आणि फायरवॉल बदलांचा एक दुपार वाचतो, आणि फॉर्वर्डिंग व्यवस्था strongSwan च्या फॉर्वर्डिंग नोंदी मध्ये वर्णन केली आहे.

होस्ट रूटचा ढीग न लावता ओव्हरलॅप दुरुस्त करा

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

खरोखर तात्पुरता होस्ट रूट आवश्यक असल्यास, नंतर काढता यावा म्हणून त्याच्या शेजारी कारण, मालक आणि तारीख लिहा. नंतर अचूक पत्ता व सेवा आणि सार्वजनिक गंतव्य तपासा, कारण स्थानिक-प्रवेशातील असा बदल जो निगडित नसलेली अनुप्रयोग टनेलबाहेर ठेवतो तो मूळ दोषापेक्षा वाईट आहे. स्थानिक प्रिफिक्स आणि दूरचा प्रिफिक्स वेगळे लिहून ठेवा; ही सवय काम करणाऱ्या स्थानिक पिंगला दूरचे कार्यालय पोहोचते याचा पुरावा म्हणून फिरवण्यापासून थांबवते.