किन /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 तीन महिनापछि बगबाट छुट्याउन सकिँदैन, र अर्को व्यक्तिले यसमा के निर्भर थियो भन्ने नजानी त्यसलाई मेटाइदिनेछ।