क्यों /32 होस्ट रूट VPN एंडपॉइंट को पहुँच-योग्य रखता है

कनेक्ट होने के बाद रूटिंग तालिका खोलते हैं तो दिखता है कि एक पता टनल से जा रहा है, जबकि उसके आसपास का सबनेट अब भी स्थानीय गेटवे की ओर जाता है। वह प्रविष्टि होस्ट रूट है: एक पता, जो सभी एक के प्रीफ़िक्स से मेल खाता है। यह मायने रखता है क्योंकि रूटिंग निर्णय सबसे लंबे मेल खाते प्रीफ़िक्स का उपयोग करते हैं, इसलिए /32 किसी को भी बदले बिना /24 या डिफ़ॉल्ट को पछाड़ सकता है। यह सावधान अपवाद है या भविष्य की रुकावट, यह इस पर निर्भर करता है कि यह किस पते का नाम लेता है और इसे कौन बनाए रखता है।

एक पता, तालिका में एक प्रविष्टि

IPv4 होस्ट रूट /32 प्रीफ़िक्स रखता है और IPv6 होस्ट रूट /128 रखता है, यानी प्रविष्टि ठीक एक गंतव्य पते से मेल खा सकती है। तालिका में और कुछ नहीं हिलता: ढकने वाला सबनेट और डिफ़ॉल्ट रूट जहाँ थे वहीं रहते हैं। संकीर्ण प्रविष्टि उस पते के लिए जीतती है क्योंकि उसका प्रीफ़िक्स लंबा है, इसलिए नहीं कि वह बाद में जोड़ी गई।

यही गुण होस्ट रूट को अच्छा अपवाद और बुरी आदत बनाता है। किसी सेवा के मुख्य द्वार को नाम देने वाली दो /32 प्रविष्टियाँ उसका दूसरा पता, उसका IPv6 पता या अगले महीने जिस पते पर वह जाती है, उसे नहीं ढकतीं। अस्पष्ट एक-पता प्रविष्टियों से भरी तालिका का अर्थ आमतौर पर यह होता है कि कोई सबनेट निर्णय लेने के बजाय उसके इर्द-गिर्द पैबंद लगाता रहा। पहले प्रीफ़िक्स की लंबाई पढ़ें, फिर पूछें कि प्रविष्टि किस चीज़ की रक्षा करनी है।

प्रविष्टि को क्लाइंट से बाहर की ओर पढ़ें

समस्या वाले मशीन से शुरू करें, क्योंकि वही पता लैपटॉप पर और उसके सामने के गेटवे पर अलग तरह से रूट हो सकता है। तालिका को ऊपर से पढ़ने के बजाय कर्नेल से पूछें कि एप्लिकेशन जो ठीक वही पता उपयोग करता है उसके लिए वह कौन-सा मार्ग चुनेगा। उत्तर में इंटरफ़ेस और अगला हॉप शामिल हैं, जो मिलकर वही निर्णय हैं।

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

उस पता-परिवार के लिए क्वेरी दोहराएँ जो एप्लिकेशन वास्तव में चुनता है, क्योंकि क्लाइंट IPv6 को प्राथमिकता देकर IPv4 अपवाद को चुपचाप बायपास कर सकता है। टनल उठने से पहले और बाद का परिणाम तुलना करें, और दोनों आउटपुट रखें। यह तुलना दिखाती है कि क्लाइंट ने कनेक्ट के समय प्रविष्टि जोड़ी थी या वह पहले से मौजूद थी।

स्थायी प्रविष्टि और रनटाइम प्रविष्टि अलग तरह से विफल होती हैं। रनटाइम वाली सत्र के साथ गायब हो जाती है, जबकि स्थायी वाली रीबूट के बाद भी बनी रहती है और ऐसे गेटवे पर ट्रैफ़िक भेजती रहती है जो अब मौजूद नहीं है।

एंडपॉइंट अपवाद और रिकर्शन जाल

VPN क्लाइंट आमतौर पर डिफ़ॉल्ट रूट बदलने से पहले मूल गेटवे के ज़रिए सर्वर के बाहरी पते पर होस्ट रूट स्थापित करते हैं. उस प्रविष्टि के बिना एन्क्रिप्टेड पैकेट उसी टनल में भेज दिए जाते जिसे वे बनाने की कोशिश कर रहे हैं, और कनेक्शन समय समाप्त होने तक लूप में घूमता रहता।

जाल तब प्रकट होता है जब टनल के स्वीकृत सबनेट में संयोग से वह एंडपॉइंट पता आ जाए, या जब दूसरी प्रोफ़ाइल बाद में अधिक चौड़ा रूट जोड़ दे। तब एंडपॉइंट प्रविष्टि लंबे प्रीफ़िक्स से हार जाती है और ट्रैफ़िक गुज़रना शुरू होते ही सत्र ढह जाता है। स्वीकृत सबनेट के बगल में एंडपॉइंट पता लिखना उपयोगकर्ताओं से पहले टकराव देखने का सबसे सस्ता तरीका है। यह यह भी समझाता है कि वही प्रोफ़ाइल एक नेटवर्क से क्यों काम करती है और दूसरे से क्यों विफल होती है।

जिस मार्ग का एप्लिकेशन वास्तव में उपयोग करता है उसे सत्यापित करें

होस्टनेम पर सफल ping कमज़ोर साक्ष्य है जब एप्लिकेशन किसी दूसरे पते या दूसरे परिवार से जुड़ता है। क्लाइंट चलाने वाली मशीन से पता, परिवार, पोर्ट और इंटरफ़ेस का ठीक संयोजन सत्यापित करें।

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

यदि मार्ग गलत है, तो कुछ भी संपादित करने से पहले तय करें कि आवश्यकता नेटवर्क है या एक पता। एक-पते की आवश्यकता टिप्पणी और मालिक के साथ होस्ट रूट को उचित ठहराती है; बदलते पतों वाली सेवा को डोमेन-आधारित रूटिंग या ईमानदार सबनेट निर्णय चाहिए।

जो प्रविष्टियाँ अब किसी वास्तविक गंतव्य से मेल नहीं खातीं उन्हें हटाएँ और जो रख रहे हैं उन्हें नोट करें। अस्पष्ट /32 तीन महीने बाद बग से अलग नहीं पहचाना जा सकता, और अगला व्यक्ति यह जाने बिना उसे मिटा देगा कि उस पर क्या निर्भर था।