मी घरगुती 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, सार्वजनिक आणि बोगदा तलाव — आणि कोणती प्रणाली कोणाची मालक आहे ते नोंदवा। पुढच्या महिन्यात कनेक्शन अयशस्वी झाल्यास तीनही एकाच वेळी बदलण्याऐवजी कोणते तपासायचे ते तुम्हाला कळेल।

संबंधित लेख