VPN पत्ता विरुद्ध LAN DHCP भाडे: टनेलचा IP कोण देतो?

क्लायंट जोडा आणि Wi-Fi चिन्हाऐवजी अडॅप्टर पहा। 10.80.0.14 सारखा पत्ता टनेलवर असू शकतो, तरी ऑफिस LAN मधील कोणत्याही DHCP सर्व्हरने ते भाडे कधीही नोंदवले नाही। कोणत्या प्रक्रियेने क्रमांक निवडला हे ठरवते की समस्या शोध कुठून सुरू होईल।

क्लायंटवर सर्व काही सारखेच दिसते: एक IPv4 पत्ता, एक मास्क, कधीकधी डीफॉल्ट गेटवे। फरक तेव्हाच दिसतो जेव्हा तुम्ही विचारता की त्या पत्त्याला कोण उत्तर देते आणि त्याची नोंद कोण ठेवते।

क्लायंटच्या बाजूने टनेलचा पत्ता वाचा

पहिल्या ओळीऐवजी संपूर्ण ब्लॉक वाचल्यास Windows फरक दाखवते। ipconfig /all अडॅप्टर वर्णन, भौतिक पत्ता आणि DHCP ओळ छापते। PPP किंवा IKEv2 डायल-अप अडॅप्टर सामान्यतः DHCP निष्क्रिय असल्याचे सांगते, कारण कनेक्शनने LAN सर्व्हरकडून भाड्याने घेण्याऐवजी डायलिंगच्या वेळीच आपल्या पत्त्यावर बोलणी केली होती। DHCP सक्रिय असलेला टनेल अडॅप्टर असामान्य आहे आणि स्वतंत्र तपासणीस पात्र आहे।

Linux तीच माहिती दोन साधनांत विभागतो। ip -4 addr show dev tun0 पत्ता आणि प्रीफिक्सची लांबी देते। nmcli -f IP4 connection show work मूल्य कनेक्शन प्रोफाइलमधून, लिंकवरील DHCP देवघेवीतून की ढकललेल्या कॉन्फिगरेशनमधून आले हे उघड करते। WireGuard सर्वात स्पष्ट उदाहरण आहे, कारण इंटरफेस दिसताच wg-quick कॉन्फिग फाइलमधील Address ओळ लागू करते आणि जोडणीच्या वेळी कोणताही पीअर काहीही वाटप करत नाही।

प्रीफिक्सही काहीतरी सांगते। /32, किंवा 255.255.255.255 चा मास्क, म्हणजे गेटवे एका होस्ट पत्त्याकडे मार्गनिर्देशन करण्याची अपेक्षा करते, तर रुंद मास्क टनेलच्या मागे कुठेतरी ऑन-लिंक सबनेटचा संकेत देते।

IKEv2 कॉन्फिगरेशन पेलोड काय वाहते

या कामासाठी IKEv2 कडे समर्पित यंत्रणा आहे। RFC 7296, कलम 3.15.1 मध्ये वर्णन केलेले कॉन्फिगरेशन पेलोड INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS आणि त्यांचे IPv6 समकक्ष यांसारखी गुणवैशिष्ट्ये वाहते। पसंती नसल्यास क्लायंट शून्य लांबीच्या मूल्याचे गुणवैशिष्ट्य पाठवतो, आणि उत्तरदाता वापरायचे असलेले मूल्य परत देतो। ती देवघेव आधीच कूटबद्ध IKE_AUTH च्या आत चालते, त्यामुळे कोणतेही DHCP प्रसारण टनेल ओलांडत नाही।

यातून दोन परिणाम येतात। प्रथम, पत्ता उत्तरदाता किंवा तो सल्ला घेणारा कोणताही अधिकृतता बॅकएंड निवडतो, म्हणूनच पूल गेटवेवर, RADIUS उत्तरात किंवा ओळख पुरवठादाराच्या मॅपिंगमध्ये राहू शकतो। दुसरे, DNS गुणवैशिष्ट्य पत्त्याच्या गुणवैशिष्ट्यापासून वेगळे आहे। 10.80.0.14 मिळणे हे कोणता रिझॉल्व्हर परत आला किंवा काहीच आले का याबद्दल काहीही सांगत नाही।

नेटमास्क गुणवैशिष्ट्य प्रत्यक्षात ऐच्छिक आहे। अनेक तैनाती केवळ पत्ता परत देतात आणि क्लायंटला होस्ट मार्ग स्थापित करू देतात, म्हणूनच एकच पूल एका क्लायंटवर /32 आणि दुसऱ्यावर /24 असे दिसू शकते।

LAN DHCP व्याप्ती आणि VPN पूल जिथे आदळतात

दोन्ही वाटपकर्ते एकाच श्रेणीकडे निर्देश करू लागल्यावर अडचण सुरू होते। 10.20.30.0/24 साठीचा DHCP सर्व्हर 10.20.30.128/25 साठी संरचित VPN पूलाबद्दल काहीही जाणत नाही, त्यामुळे गेटवे तोच पत्ता दूरच्या क्लायंटला देत असताना 10.20.30.140 प्रिंटरला भाड्याने देण्यापासून काहीही रोखत नाही। टक्कर अनेक दिवस गुपचूप राहते आणि नंतर अधूनमधून येणारी प्रत म्हणून पुढे येते।

मार्गनिर्देशित साइट-ते-साइट रचना टक्कर टाळते। शाखेतील होस्ट स्थानिक DHCP सर्व्हरने दिलेला पत्ता ठेवतो। दोन्ही गेटवेंवरील टनेल इंटरफेस स्वतःचे लिंक पत्ते वाहतात, आणि पॅकेट कसे प्रवास करतात हे मार्गनिर्देशन तक्ता ठरवते। दूरस्थ प्रवेश क्लायंटचे पत्ते तिसरी श्रेणी आहेत आणि ते गेटवेच्या लिंक पत्त्यांत मिसळू नयेत।

टनेलला LAN वर पूल करून जोडल्यास ते विभाजन दूर होते। रचनेला खरोखर एकच प्रसारण क्षेत्र हवे असल्यास, VPN अंत्यबिंदूने स्वतः पत्ते जारी करण्याऐवजी रिले किंवा सामायिक अधिकृत स्रोतातून DHCP सर्व्हरसारख्याच वाटप निर्णयांत सहभाग घ्यावा।

पत्ता कोणत्या प्रक्रियेच्या मालकीचा आहे ते तपासा

व्याप्ती बदलण्यापूर्वी मालकी सिद्ध करा। क्लायंटवर पत्ता आणि प्रीफिक्स नोंदवा। LAN वर भाडे डेटाबेसमध्ये शोधा। गेटवेवर देण्यासाठी संरचित पूलांची यादी करा। भाडे फाइलमध्ये सापडलेला पत्ता DHCP सर्व्हरचा असतो, म्हणजे टनेल पूल केलेले किंवा रिले केलेले आहे; केवळ गेटवे पूलमध्ये सापडलेला पत्ता टनेल अंत्यबिंदूचा असतो।

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

उत्तर स्पष्ट झाल्यावर चार गोष्टी नोंदवा: कोणता घटक क्लायंटचा पत्ता वाटप करतो, त्यासाठी कोणती श्रेणी राखीव आहे, परतीची रहदारी त्या श्रेणीपर्यंत कशी पोहोचते आणि कोणती संसाधने ती स्वीकारतात। या चार नोंदी व्हर्च्युअल अडॅप्टरची एक ओळ कार्यान्वयन वस्तुस्थितीत बदलतात।

तिथे असतानाच DNS गुणवैशिष्ट्यासाठी तपासणी पुन्हा करा। पत्ते देतो पण रिझॉल्व्हर देत नाही असा पूल क्लायंटला त्याच्या स्थानिक DNS वर ठेवतो, हे LAN आधीच वापरत असलेला पत्ता देणाऱ्या पूलपेक्षा वेगळे अपयश आहे।