route -interface लिंक के बाहर के होस्ट तक क्यों नहीं पहुँचता

route Wi-Fi इंटरफ़ेस का नाम स्वीकार करता है, बिना शिकायत बाहर निकलता है, और होस्ट अभी भी अगम्य रहता है। कुछ भी खराब नहीं है; रूट में संबंध बस ग़लत है: इंटरफ़ेस फ़्लैग बताता है कि गंतव्य किस लिंक पर है, यह नहीं कि किसी और जगह रहने वाले गंतव्य के लिए कौन-सा राउटर ट्रैफ़िक पाएगा। कमांड सफल होता है क्योंकि यह वाक्य-रचना की दृष्टि से वैध है, इसलिए नहीं कि यह काम करने वाला मार्ग बताता है।

यही अंतर तय करता है कि VPN के साथ रूट अपवाद काम करेगा या केवल विश्वसनीय दिखेगा।

इंटरफ़ेस निकास है, अगला हॉप सौंपना है

192.168.50.20 पते वाले Mac पर और 192.168.50.1 पर राउटर के साथ, उसी लिंक की दूसरी मशीन सीधे पहुँच में है। फ़्रेम उसी मशीन को संबोधित करके तार पर रखा जाता है। कोई राउटर शामिल नहीं है, और इंटरफ़ेस-सीमित रूट ठीक यही व्यक्त करता है। दूर के सिरे को दूसरी इमारत के होस्ट में बदलिए और वही कमांड अर्थहीन हो जाता है। Mac के पास तार पर रखने के लिए दूसरी परत का पता नहीं है, इसलिए इंटरफ़ेस फ़्लैग के पास बताने को कुछ नहीं है।

लिंक के बाहर का गंतव्य अलग है। Mac उस होस्ट को संबोधित फ़्रेम तार पर नहीं रख सकता जहाँ तक वह दूसरी परत पर नहीं पहुँचता; वह पैकेट ऐसे राउटर को सौंपता है जो पहुँच सकता है। इसलिए रूट को गेटवे चाहिए, और गेटवे स्वयं जुड़े लिंक पर पहुँचने योग्य होना चाहिए।

लिंक के बाहर के गंतव्य के लिए इंटरफ़ेस फ़्लैग का उपयोग macOS को कहता है कि उस गंतव्य को तार पर माने। तब कर्नेल उसके लिए दूसरी परत का पता हल नहीं कर पाता, और पैकेट त्रुटि में कुछ भी उपयोगी बिना छोड़ दिया जाता है।

इंटरफ़ेस फ़्लैग वास्तव में क्या दावा करता है

Apple का रूट संदर्भ उन गंतव्यों के लिए इंटरफ़ेस रूप परिभाषित करता है जो बिना मध्यस्थ के सीधे पहुँच योग्य हैं। यह लिंक मॉडल के बारे में कथन है, यह वरीयता नहीं कि कौन-सा एडाप्टर उपयोग करें। Wi-Fi से इंटरनेट होस्ट तक पहुँचने के लिए उस Wi-Fi लिंक पर राउटर अभी भी ज़रूरी है, और रूट को उसका नाम लेना चाहिए।

इंटरफ़ेस स्कोप एक अलग गुण है। यह स्कोपिंग निर्णयों के लिए, जैसे कौन-सा स्रोत पता लागू होता है, रूट को किसी विशेष इंटरफ़ेस से जोड़ता है, परंतु ऐसे गंतव्य के लिए पहुँच नहीं बनाता जहाँ इंटरफ़ेस स्वयं नहीं पहुँच सकता। दोनों गुण अलग-अलग प्रश्नों के उत्तर देते हैं।

इसीलिए कमांड स्वीकार हो सकता है, तालिका में दिख सकता है और फिर भी विफल हो सकता है। कर्नेल आपके इरादे की पुष्टि नहीं करता; यह दर्ज करता है कि आपने क्या दावा किया, और दावा यह था कि गंतव्य लिंक पर है। मौन सफलता के बाद मौन त्याग अपेक्षित परिणाम है, दोष नहीं। नेटवर्क को दोष देने से पहले दावा दोबारा पढ़िए।

लिंक के बाहर के गंतव्य को जिस रूट की ज़रूरत है

LAN राउटर के ज़रिए 198.51.100.25 जैसे दस्तावेज़ी पते तक मंज़ूर मार्ग के लिए, इच्छित संबंध है गंतव्य, 192.168.50.1 का अगला हॉप, और वह LAN इंटरफ़ेस जो उस अगले हॉप तक पहुँचता है। इंटरफ़ेस अगले हॉप की खोज से निकलता है, रूट कमांड से थोपा नहीं जाता।

macOS में केवल-पढ़ने वाला निरीक्षण route -n get 198.51.100.25 है। गेटवे और इंटरफ़ेस की पंक्तियाँ साथ पढ़ें और जाँचें कि गेटवे वह पता है जहाँ Mac वास्तव में पहुँच सकता है। दूसरे सबनेट पर गेटवे, या पिछले नेटवर्क परिवर्तन के बाद से चला गया गेटवे, ऐसा रूट बनाता है जो सही दिखता है और कुछ भी फ़ॉरवर्ड नहीं करता।

टिकाऊ निर्देश में en0 को हार्डकोड न करें। एडाप्टर, डॉक और VPN क्लाइंट के साथ इंटरफ़ेस के नाम बदलते हैं, और ग़लत नाम लेने वाला रूट ऐसे विफल होता है जिसे व्यापक नेटवर्क खराबी के रूप में आसानी से पढ़ा जा सकता है।

बदलने से पहले वर्तमान चयन पढ़ें

कुछ भी जोड़ने से पहले देखें कि सिस्टम ने पहले से क्या चुना है और क्यों। वह आउटपुट बताता है कि ट्रैफ़िक सुरंग से, LAN राउटर से या कहीं नहीं जा रहा, और बदलाव के बाद तुलना के लिए आधार देता है। इसके बिना आप नहीं बता सकते कि नया रूट लागू हुआ या नहीं।

फिर पता परिवार जाँचें। IPv4 के लिए जोड़ा गया रूट IPv6 गंतव्य के लिए कुछ नहीं करता, और दोनों परिवारों में हल होने वाली सेवा रुक-रुक कर पहुँचने योग्य लग सकती है। रूट तालिका और रिज़ॉल्वर अलग-अलग प्रश्नों के उत्तर देते हैं, और दोनों को इच्छित मार्ग से मेल खाना चाहिए।

अंत में, याद रखें कि रूट एक चयन है, अनुमति नहीं। प्रबंधित VPN प्रोफ़ाइल या क्लाइंट फ़िल्टर सीधा मार्ग तब भी मना कर सकता है जब तालिका उसकी ओर इशारा करे, इसलिए यह मानने के बजाय कि सफल तालिका प्रविष्टि जाँच समाप्त कर देती है, वास्तविक एप्लिकेशन से परीक्षण करें।

सुरंगें और नीति आकार बदलती हैं

पॉइंट-टू-पॉइंट इंटरफ़ेस अपना अलग मामला हैं। सुरंग Ethernet-शैली के गेटवे पते के बिना रूट ले जा सकती है, और यह अपने आप ग़लत नहीं है। हर दिखने वाली तालिका प्रविष्टि पर Wi-Fi उदाहरण बढ़ाने के बजाय इंटरफ़ेस का वास्तविक लिंक मॉडल लागू करें।

परिवर्तन अनुरोधों के लिए गंतव्य, मंज़ूर नेटवर्क मार्ग, वर्तमान गेटवे और इंटरफ़ेस, और अपवाद कौन बनाए रखेगा, लिखें। मालिक महत्वपूर्ण है क्योंकि प्रॉम्प्ट पर टाइप किया गया एकबारगी रूट नीति नहीं है, और अगला पुनःकनेक्शन उसे मिटा देगा।

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