तपाईंको VPN सर्भरका लागि DHCP आरक्षण स्थिर IP किन होइन

मैले घरायसी VPN बक्स Wi-Fi बाट Ethernet मा सारें र यसको “स्थायी” ठेगाना त्यही साँझ बदलियो। राउटरमा केही पनि बिग्रेको थिएन। आरक्षण ताररहित एडाप्टरसँग मिलिरहेको थियो, र त्यो एडाप्टर अब बाटोमा थिएन।

यही गलत बुझाइको दोस्रो आधा पनि छ। LAN ठेगाना ठीक गर्नाले तपाईंका साथीहरू जोडिने ठेगानामा केही गर्दैन, र VPN ले ग्राहकलाई दिने निजी पोखरीसँग यसको कुनै सम्बन्ध छैन। तीन ठेगाना, तीन छुट्टै असफलताका तरिका, र तीमध्ये एउटा मात्र आरक्षणको काम हो।

आरक्षण ग्राहकसँग मिल्छ, यन्त्रसँग होइन

DHCPv4 मा आरक्षण ग्राहकको हार्डवेयर ठेगानामा आधारित हुन्छ; DHCPv6 मा ग्राहकले राख्नुपर्ने DUID मा आधारित हुन्छ। hostname फिल्ड मानिसका लागि लेबल हो। राउटरले वास्तवमा अनुरोधमा आउने पहिचानको तुलना गर्छ।

प्रविष्टिलाई सर्तका रूपमा पढ्नुहोस्: यो पहिचानले माग्दा यसलाई यो ठेगाना दिनुहोस्। मिलान टिकेसम्म नवीकरणले उही लिज राख्छ, र रिबुटले फेरि माग्छ। पहिचान बदलिएमा अनुरोधले आरक्षण छुटाउँछ र ग्राहकले गतिशील पोखरीले दिने लिन्छ। कुनै त्रुटि छैन, कुनै चेतावनी छैन, बस अर्को ठेगाना।

OpenWrt ले आकार स्पष्ट देखाउँछ। /etc/config/dhcp मा एउटा config host ब्लकले नाम, MAC र ठेगाना एकैसाथ बाँध्छ, र स्थिर लिजको कागजात ले त्यो प्रविष्टि पोखरीसँग कसरी व्यवहार गर्छ भनेर व्याख्या गर्छ। अन्य राउटरहरूले तीही तीन फिल्ड फरक लेबलपछाडि लुकाउँछन्।

जहाँ मिलान चुपचाप टुट्छ

हार्डवेयर बदल्नु सामान्य केस हो। NIC बदल्नुहोस्, वा मेसिनलाई Ethernet र Wi-Fi बीच सार्नुहोस्, र राउटरले देख्ने ठेगाना पनि सँगै बदलिन्छ। पुरानो आरक्षण सूचीमा रहन्छ, अझै ठीक देखिन्छ।

पुनःस्थापना दोस्रो केस हो, र यसले IPv6 मा सबैभन्दा बढी टोक्छ। नयाँ स्थापनाले नयाँ DUID बनाउन सक्छ, जबकि पुरानो IPv4 लिज अझै वैध हुन्छ, त्यसैले v4 ठेगाना केही समय बाँच्छ र v6 प्रविष्टि कुनै देखिने सम्पादनबिना लागू हुन छोड्छ।

तेस्रो पिन गरिएको ग्राहक पहिचान हो। धेरै DHCP ग्राहकले MAC प्रयोग गर्नुको सट्टा पहिचान स्ट्रिङ सेट गर्न दिन्छन्। यदि अपग्रेड वा कन्फिग पुनर्लेखनले त्यो सेटिङ छोडिदियो भने मेसिन नसरे पनि मिलान हराउँछ।

चौथो दोहोरोपन हो: एउटै होस्टका लागि पुरानो ब्लक र नयाँ ब्लक। सर्भरले मिल्ने नियमअनुसार जवाफ दिन्छ, प्रायः तपाईं बच्न चाहेको पोखरीको ठेगानाले। दोस्रो थप्नुको सट्टा पुरानो प्रविष्टि मेट्नुहोस्।

होस्टतर्फको कन्फिगरेसन र यसको मूल्य

होस्टमै ठेगाना सेट गर्दा मिलानको प्रश्न पूर्ण रूपमा हट्छ। DHCP ले जवाफ देओस् वा नदेओस्, इन्टरफेस त्यही ठेगानासँग माथि आउँछ, र राउटर रिबुटपछि पनि पुग्न सकिने मेसिनबाट तपाईंले यही चाहनुहुन्छ।

मूल्य स्वामित्व हो। अब प्रिफिक्स, गेटवे र रिजोल्भर तपाईं आफैं दिनुहुन्छ, र ठेगाना गतिशील पोखरीबाहिर तपाईं आफैं राख्नुपर्छ। netplan सहित Ubuntu मा यसलाई /etc/netplan/01-vpn.yaml बोक्छ:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

NetworkManager प्रयोगकर्ताहरू nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1 सँग, त्यसपछि nmcli con up "Wired connection 1" सँग उही अवस्थामा पुग्छन्। पहिलो प्रयासमै netplan apply सट्टा netplan try सँग netplan लागू गर्नुहोस्; गलत टाइप गरिएको गेटवेले बक्सलाई नेटवर्कबाट झिक्छ र तपाईंलाई कन्सोल खोज्न छोड्छ।

तैपनि मिल्ने आरक्षण राख्नुहोस्। यो बढी होइन। प्रविष्टिले राउटरतर्फ ठेगाना रेकर्ड गर्छ र कसैले पछि पोखरी फराकिलो बनाएमा DHCP सर्भरलाई त्यो ठेगाना अतिथि यन्त्रलाई दिनबाट रोक्छ।

स्थिर LAN ठेगाना सार्वजनिक अन्त्य बिन्दु होइन

पोर्ट फर्वार्डलाई 192.168.50.10 तिर फर्काउनुहोस् र नियम LANतर्फको हरेक परिवर्तनमा टिक्छ। तर यसले तपाईंलाई स्थिर इन्टरनेट ठेगाना दिँदैन। तपाईंको सार्वजनिक IP ISP को हो र पुनःजडान वा मोडेम फेरबदलमा सर्न सक्छ, गतिशील DNS यहीका लागि हो।

क्यारियर-ग्रेड NAT पछाडि फर्वार्ड गर्न सार्वजनिक IPv4 नै हुँदैन, र कुनै आरक्षणले त्यो बनाउँदैन। सबैभन्दा पहिले राउटरको WAN पृष्ठ हेर्नुहोस्: ठेगाना साझा दायरामा छ भने आरक्षण जतिसुकै सफा भए पनि भित्र आउने फर्वार्डिङ काम गर्न सक्दैन।

तेस्रो ठेगाना सुरुङ पोखरी हो, प्रायः 10.8.0.0/24 जस्तो केही। ती ठेगाना सुरुङभित्र मात्र हुन्छन् र LAN मा कहिल्यै देखिँदैनन्। तिनलाई सर्भरको LAN ठेगानासँग मिसाउनु भनेको पोर्ट अन्ततः जोडिएको बेलामा मात्र अनलाइन हुने ग्राहकतिर फर्वार्ड हुने बाटो हो।

बाटो जुन क्रममा टुट्छ त्यही क्रममा जाँच्नुहोस्

राउटरबाट सुरु गर्नुहोस्। लिज तालिकाको प्रविष्टि आरक्षणको लक्ष्यसँग तुलना गर्नुहोस्; सर्भरले पोखरीको ठेगाना लिएको छ भने पहिचान गलत छ, र होस्टमा ip link show ले तुलनाका लागि मान दिन्छ।

त्यसपछि होस्ट। ip -4 addr show eth0 ले अपेक्षित ठेगाना र प्रिफिक्स देखाउनुपर्छ। उही इन्टरफेसमा दोस्रो ठेगाना हुनु सामान्यतया DHCP अझै तपाईंको स्थिर कन्फिगको छेउमा चलिरहेको अर्थ हुन्छ।

त्यसपछि फर्वार्ड। गन्तव्य अझै तपाईंले भर्खर जाँचेको ठेगाना बराबर छ र केही ss -lntp सँग सुनिरहेको छ भनी पुष्टि गर्नुहोस्। बन्द पोर्टतिर फर्किएको फर्वार्ड बाहिरबाट ठ्याक्कै बिग्रेको फर्वार्डजस्तै देखिन्छ।

बाहिरबाट सक्नुहोस्, Wi-Fi बन्द भएको फोनमा। त्यही एउटा परीक्षणले “स्थानीय ठेगाना गलत छ” र “सार्वजनिक पहुँच बिग्रेको छ” छुट्याउँछ, यो सेटअपले बारम्बार मिसाउने दुई समस्या।

तीनै ठेगाना लेख्नुहोस् — LAN, सार्वजनिक र सुरुङ पोखरी — र कुन प्रणाली कुनको मालिक हो टिप्नुहोस्। अर्को महिना कुनै जडान असफल भए तीनै एकैचोटि बदल्नुको सट्टा कुन जाँच्ने भन्ने तपाईंलाई थाहा हुनेछ।