VPN मार्ग ip route च्या आउटपुटमध्ये गेटवे का दाखवत नाही
इंटरफेस असलेली पण गेटवे नसलेली ओळ थेट मार्ग आहे, तुटलेला नाही। गंतव्य, dev आणि scope वाचा, नंतर ip route get ने खात्री करा।
गेटवे स्तंभ रिकामा दिसताच राउटिंग तक्ते तुटलेले म्हणून वाचली जातात, पण ओळ सामान्यतः स्वतःच पूर्ण असते। via फील्ड तेव्हाच दिसते जेव्हा कर्नेल पॅकेट पुढील हॉपच्या पत्त्यावर सोपवते; इंटरफेसशी जोडलेला मार्ग आपली गंतव्ये त्याऐवजी लिंक-स्तर विश्लेषणाद्वारे किंवा पॉइंट-टू-पॉइंट साथीद्वारे गाठतो। स्तंभ डावीकडून उजवीकडे वाचल्यास तुम्ही कोणत्या स्थितीत आहात ते कळते, आणि ते वाचन कोणी डीफॉल्ट मार्ग संपादित करण्यापूर्वीच झाले पाहिजे। हरवलेल्या गेटवेबद्दलची बहुतेक तिकिटे याच फरकावर संपतात।
मार्गाची ओळ स्तंभागणिक वाचा
प्रत्येक नोंद गंतव्य आणि त्याच्या प्रीफिक्स लांबीने सुरू होते, नंतर स्थिर शब्दसंग्रहात सुधारक जोडते: via, dev, proto, scope, src आणि metric। 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 सारखी ओळ घट्ट पण पूर्णपणे निर्दिष्ट आहे। तिच्यात काहीही अनुपस्थित नाही, आणि कोणताही राउटर पत्ता गृहीत धरलेला नाही।
via ची अनुपस्थिती हा मनोरंजक भाग आहे। पुढील हॉप नसल्यास कर्नेल गंतव्य नामनिर्देशित इंटरफेसवर थेट सोडवते, ज्याचा टनेलसाठी अर्थ असा की फ्रेम टनेल उपकरणाला देऊन एन्कॅप्सुलेशनला तिथून पुढे सांभाळू देणे। proto kernel नोंदवते की पत्ता नेमला जाताना नोंद स्वयंचलितपणे स्थापित झाली, कोण्या प्रशासकाने टाइप केलेली नाही। scope link म्हणते की गंतव्य त्या लिंकवर राउटरमधून न जाता पोहोचण्यायोग्य आहे, आणि src त्या पत्त्याचे नाव देते जो कर्नेल जुळणाऱ्या रहदारीसाठी स्रोत म्हणून पसंत करेल।
आता डीफॉल्ट मार्ग त्याच पद्धतीने वाचा: default via 192.0.2.254 dev eth0 proto static metric 100। येथे via आहे कारण पॅकेटला खरोखर पुढील हॉप आवश्यक आहे, आणि तो हॉप स्वतः eth0 वर पोहोचण्यायोग्य असला पाहिजे। त्या दोन ओळी एकमेकांच्या प्रकार नाहीत; त्या रहदारी कुठे जाते याबद्दल वेगवेगळ्या प्रश्नांची उत्तरे देतात।
एकमेकांशी गल्लत होणारे दोन मार्ग आकार
टनेल सबनेट मार्ग आणि डीफॉल्ट मार्ग स्क्रीनशॉटमध्ये सारखे दिसतात आणि पूर्णपणे वेगळे वागतात। खालील तक्ता फील्ड वाचण्यासाठी मदत म्हणून वापरा, नंतर मार्गदर्शकातील नमुन्यावर विश्वास ठेवण्याऐवजी तुम्ही डीबग करत असलेल्या मशीनवरच खरे आकडे तपासा।
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
तक्ता जे सांगू शकत नाही ते म्हणजे हेतू। टनेलमधून खाजगी श्रेणीकडे थेट मार्ग हा जाणीवपूर्वक केलेला स्प्लिट-टनेल डिझाइन आहे; ज्या होस्टने सर्व काही VPN मधून पाठवायला हवे तिथे तोच आकार दिसणे हे लक्षण आहे। हेतू ती नोंद निर्माण करणाऱ्या कॉन्फिगरेशनमध्ये राहतो, म्हणून कर्नेलने काही चूक केली असा निष्कर्ष काढण्यापूर्वी ती स्थापित करणाऱ्या साधनाकडे पाहा।
त्याचप्रमाणे, हरवलेला गेटवे हा एखादा तयार करण्याचा परवाना नाही। जर मार्गाला खरोखर पुढील हॉप आवश्यक असेल, तर तो हॉप त्याला वाहून नेणाऱ्या इंटरफेसवर पोहोचण्यायोग्य असला पाहिजे, आणि पॉइंट-टू-पॉइंट टनेलसाठी साथीचा पत्ता स्थानिक पत्त्यासारखी तीच वस्तू नाही। स्थानिक टनेल पत्त्याला इथरनेट राउटर मानणे हा बरोबर दिसणारा पण काहीही पुढे न पाठवणारा मार्ग तयार करण्याचा सामान्य मार्ग आहे।
कर्नेलला विचारा की ते प्रत्यक्षात कोणती ओळ वापरेल
तक्ता वाचणे हे शोध करण्यासारखे नाही, कारण उत्तर देण्यापूर्वी कर्नेल धोरण नियम, अनेक तक्ते आणि कॅशे केलेल्या नोंदींचा सल्ला घेते। खरा शोध करणारे क्रियापद ip route get आहे, आणि ते त्या गुणधर्मांच्या पॅकेटने घेणारा मार्ग छापते।
ip route get 203.0.113.37 from 198.51.100.2 iif tun0तुम्हाला खरोखर महत्त्वाचे असलेले गंतव्य ठेवा, नंतर रहदारी स्रोतानुसार निवडली गेल्यास किंवा पुढे पाठवली गेल्यास from किंवा iif जोडा, कारण सामान्य स्थानिक शोध पुढे पाठवलेल्या क्लायंटपेक्षा वेगळा मार्ग निवडू शकतो। उत्तर इंटरफेस, निवडलेला स्रोत पत्ता आणि कोणताही पुढील हॉप सांगते, जी त्या क्षणी पॅकेटला राउट करण्यासाठी वापरली जाणारी तीच माहिती आहे।
उत्तर तुम्हाला आश्चर्यचकित करत असेल, तर काहीही बदलण्यापूर्वी नियम छापा: ip -4 rule show ते प्राधान्यक्रमाने सूचीबद्ध करते, आणि स्वतःचे तक्ते किंवा चिन्हांकित पॅकेटसाठी नियम स्थापित करणारा VPN क्लायंट मुख्य तक्त्यात अजिबात दिसणार नाही। प्रत्येक तक्ता सूचीबद्ध केल्यास ती तफावत भरून निघते।
ip -4 route show table all | grep -E 'tun|default'डीफॉल्ट बदलण्यापूर्वी अंडरले तपासा
टनेलची स्वतःची पॅकेट दूरच्या टोकापर्यंत पोहोचली पाहिजेत, आणि ते VPN वर येण्यापूर्वी अस्तित्वात असलेल्या मार्गाचा वापर करून भौतिक इंटरफेसवरून करतात। ते टोक पिन न करता संपूर्ण डीफॉल्ट मार्ग बदलल्यास एन्कॅप्सुलेटेड पॅकेट तयार करायच्या टनेलमध्येच जातात, आणि कनेक्शन कोसळते। आधी फक्त टोकाच्या पत्त्यासाठी शोध घेऊन टोकाचा मार्ग निश्चित करा।
बदल करताना तीन गोष्टी वेगळ्या ठेवा: भौतिक इंटरफेसवर राहिले पाहिजे असलेला टोकाचा मार्ग, टनेलमध्ये जायला हव्यात त्या खाजगी श्रेणी, आणि बाकी सर्व ठरवणारा डीफॉल्ट। त्या क्रमाने वेगळ्या करा, एका वेळी एक लागू करा, आणि प्रत्येक पायरीनंतर शोध पुन्हा चालवा। नंतर अपयशी पिंग स्वतःच फार कमी सिद्ध करतो, कारण परवानग्या, उत्तर राउटिंग, DNS आणि सेवा स्वतः सर्व बरोबर मार्गाच्या खाली बसलेले आहेत।
संपादनापूर्वी ओळीने दिलेली चार मूल्ये लिहून ठेवा: गंतव्य, पुढील हॉप किंवा त्याची अनुपस्थिती, उपकरण, आणि निवडलेला स्रोत। नंतरचा बदल त्यातील कोणतेही हलवत असेल, तर कोणता निर्णय खरोखर बदलला हे तुम्हाला कळेल, आणि संपूर्ण तक्त्याचा अंदाज लावण्याऐवजी एक नोंद पुनर्संचयित करू शकता।