आपके 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, सार्वजनिक और टनल पूल — और नोट करें कि कौन सा सिस्टम किसका मालिक है। अगले महीने कोई कनेक्शन विफल हो तो तीनों को एक साथ बदलने के बजाय आपको पता होगा कि किसे जाँचना है।