VPN मार्गमा अर्को हप: गेटवे स्थानीय रूपमा पुग्न योग्य किन हुनुपर्छ

VPN सञ्जालमा जाने मार्गले दुई ठेगाना बोक्छ जसलाई भ्रमित गर्न सजिलो छ: प्याकेट पुग्न खोजिरहेको गन्तव्य प्रिफिक्स र त्यसलाई एक कदम नजिक सार्ने अर्को हप। LAN होस्टमा त्यो अर्को हप त्यस्तो राउटर हुनुपर्छ जहाँ तपाईं साँच्चै त्यही लिङ्कमा पुग्न सक्नुहुन्छ। टाढाको VPN ठेगाना अर्को हप होइन, तपाईंको मनको गन्तव्यसँग जति राम्ररी मिले पनि।

यो रनबुकले सामान्य अवस्था समेट्छ: 192.168.20.0/24 मा ल्यापटप, LAN ठेगाना 192.168.20.5 भएको VPN गेटवे, र त्यो गेटवे पछाडि 10.70.0.0/24 टाढाको सञ्जाल। तलका सबै आदेशले तपाईं ल्यापटपमा हुनुहुन्छ भनी मान्छन्, अन्यथा भनिएको छैन भने।

दुई ठेगाना, एउटा मार्ग

अभिप्रेत प्रविष्टि 10.70.0.0/24 via 192.168.20.5 हो। प्रिफिक्सले प्याकेट कहाँ जाँदैछ भन्छ; via ठेगानाले त्यसलाई त्यहाँ को लैजाँदैछ भन्छ। कर्नेलले तपाईंले नाम दिएको इन्टरफेसबाट गेटवेमा पुग्न नसक्ने मार्ग स्थापना गर्न अस्वीकार गर्छ, र त्यो अस्वीकार नै पूरै कुरा हो: पुग्न योग्य हुन सुरुङ चाहिने अर्को हप सुरुङ बनाउने अर्को हप हुन सक्दैन।

त्यसैले पहिलो जाँच «गेटवे चलिरहेको छ» होइन, «गेटवे यो लिङ्कमा छ» हो। ल्यापटपको आफ्नै सबनेट, त्यसको ARP वा छिमेकी प्रविष्टि, र मार्गमा भएको इन्टरफेस सबै मिल्नुपर्छ। जो ठेगाना केवल 10.70.0.0/24 भित्र अवस्थित छ त्यो दोस्रो मार्गको गन्तव्य हुन सक्छ, तर पहिलोको via कहिल्यै हुन सक्दैन।

अर्को हपले गेटवेलाई के गर्न बाध्य गर्छ

ल्यापटपमा मार्ग स्थापना गर्नुले पहिलो हस्तान्तरण मात्र निर्धारण गर्छ। त्यसपछि गेटवेलाई आफ्नै बाटो चाहिन्छ: सक्षम गरिएको फर्वार्डिङ, 10.70.0.0/24 का लागि सुरुङ मार्ग, र को प्रयोग गर्न पाउँछ भन्ने निर्धारण गर्ने कुनै पनि पहुँच नीति। Linux मा त्यो net.ipv4.ip_forward=1 र सुरुङ मार्ग हो; त्यसको अगाडिको फायरवाललाई फर्वार्ड हुने प्रवाहलाई अनुमति दिने नियम चाहिन्छ।

फर्कने दिशा त्यो भाग हो जुन मानिसहरू बिर्सन्छन्। टाढाको पक्षसँग 192.168.20.0/24 तर्फ फर्कने मार्ग हुनुपर्छ, वा डिजाइनले ल्यापटपको स्रोतलाई टाढाको पक्षले चिन्ने कुनै चीजमा अनुवाद गर्नुपर्छ। गेटवेबाट काम गर्ने ping ले गेटवे टाढाको सञ्जालमा पुग्न सक्छ भनी प्रमाणित गर्छ; ल्यापटपका प्याकेट फर्कने यात्रामा बाँच्छन् कि भन्नेबारे यसले केही भन्दैन।

पठाउने होस्टबाट खोजी जाँच्नुहोस्

कर्नेललाई कुन अर्को हप छान्छ भनी सोध्नुहोस्, र उत्तरमा भएको इन्टरफेस पढ्नुहोस्:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

यदि खोजीले गेटवे र LAN इन्टरफेस रिपोर्ट गर्छ भने पहिलो खण्ड अभिप्रेत रूपमा कन्फिगर छ। यदि यसले सुरुङ उपकरण रिपोर्ट गर्छ भने, तालिकामा अगाडिको कुनै कुरा बढी विशिष्ट छ र जितिरहेको छ। यदि मार्ग नै स्थापना हुँदैन भने, कर्नेलले तपाईंलाई गेटवे पुग्न योग्य छैन भनी भन्दैछ, र त्यो सन्देश कुनै पनि प्याकेट क्याप्चरभन्दा उपयोगी छ।

त्यसपछि सही ठाउँबाट परीक्षण दोहोर्याउनुहोस्। गेटवेमा बनाइएको अनुरोधले गेटवेको आफ्नै स्रोत ठेगाना प्रयोग गर्छ, जसले हराएको फर्कने मार्ग वा केही स्रोतलाई मात्र अनुमति दिने नीति लुकाउन सक्छ। ip-route पुस्तिका ले गन्तव्य, गेटवे र onlink ओभरराइड अलग गर्छ, र ओभरराइड प्रयोग गर्नुअघि बुझ्नु उचित छ।

पुग्न योग्यता नक्कली बनाउन onlink प्रयोग नगर्नुहोस्

onlink ले कर्नेललाई गेटवेको पुग्न योग्यता जाँच छोड्न र त्यसै पनि त्यहाँ पठाउन भन्छ। यसले बाटो बनाउँदैन, त्यहाँ नभएको ठेगानाका लागि ARP समाधान गर्दैन, र तपाईंको Ethernet खण्डमा टाढाको राउटरलाई जवाफ दिन बाध्य गर्दैन। जवाफ दिने तर जोडिएको सबनेटमा नबस्ने गेटवेका लागि यो वैध छ, र तपाईंले व्याख्या नगरेको त्रुटि शान्त गर्न प्रयोग गर्दा यो जाल हो।

यदि मार्ग onlink सँग मात्र स्थापना हुन्छ भने, अर्को प्रश्न यो हो कि गेटवे तपाईंले सोचेको ठाउँमा किन छैन। गलत VLAN, गलत इन्टरफेसमा दोस्रो ठेगाना, वा अन्तिम अक्टेटमा टाइपो — यी सबैले यो उत्पन्न गर्छन्, र तीमध्ये प्रत्येकले ट्राफिक बहन थालेपछि फर्कने बाटो पनि तोड्छ।

बिन्दु-देखि-बिन्दु सुरुङहरू Ethernet होइनन्

सुरुङ उपकरणले ARP गर्दैन र प्रायः छिमेकीको अर्थपूर्ण सबनेट हुँदैन। यसका मार्गहरू प्रायः 10.70.0.0/24 dev tun0 जस्तो देखिन्छन्, कुनै via बिना, किनकि सहकर्मी नै अर्को एकमात्र अन्त्य बिन्दु हो। त्यो तालिकामा LAN शैलीको via प्रतिलिपि गर्दा कर्नेलले अस्वीकार गर्न सक्ने मार्ग, वा अझ नराम्रो, सहकर्मीले कहिल्यै जवाफ नदिने ठेगानातर्फ देखाउने मार्ग बन्छ।

रनबुकमा दुवै मोडेल अलग राख्नुहोस्: LAN मार्गसँग पुग्न योग्य गेटवे हुन्छ, सुरुङ मार्गसँग इन्टरफेस र सहकर्मी हुन्छ। WireGuard, OpenVPN र IPsec सबै अलि फरक आकार देखाउँछन्, त्यसैले एउटा होस्टबाट सामान्यीकरण गर्नुको सट्टा तपाईंले साँच्चै प्रयोग गरेको आकार लेख्नुहोस्।

थप्नुहोस्, पुष्टि गर्नुहोस्, फर्काउनुहोस्

सम्पूर्ण परिवर्तन तीन आदेश र एउटा जाँच हो, र यसलाई त्यही क्रममा लेख्नुपर्छ:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

मार्ग पुष्टि गर्नुहोस्, एउटा गन्तव्य पुष्टि गर्नुहोस्, त्यसपछि परिवर्तनले होस्टलाई तपाईंले अपेक्षा नगरेको तरिकाले अगम्य बनाए मेट्ने लाइन तयार राख्नुहोस्। यदि मार्ग पुनः सुरु गरेपछि पनि रहनुपर्छ भने, यसलाई shell प्रोफाइलमा होइन, होस्टको सञ्जाल कन्फिगरेसनमा राख्नुहोस्, र यसमा भर पर्नुअघि पुनः सुरुको परीक्षण गर्नुहोस्। जो मार्ग केवल यो थप्ने shell भित्र मात्र अवस्थित छ त्यो त्यस्तो मार्ग हो जसलाई तपाईं दुई पटक डिबग गर्नुहुनेछ।