बसणारा VPN क्लायंट पत्ता पूल कसा नियोजित करावा

VPN सर्व्हरवरील पूल फील्डपासून सुरुवात करा, स्प्रेडशीटपासून नाही। तिथे तुम्ही टाइप करता ते नंतर जोडणाऱ्या प्रत्येक क्लायंटसाठी अंतर्गत पत्ता जागा बनते, आणि ते त्या क्लायंट्स पोहोचतात त्या LAN, त्यामागील मार्गित साइट्स आणि क्लायंटकडे घरी आधीच असलेल्या कोणत्याही पत्त्यासोबत एकत्र राहिले पाहिजे। पूल जतन होताच एक क्लायंट जोडा, कारण तो पहिला कनेक्शन मूल्य प्रत्यक्षात चालते का हे सांगतो। तिथून फेरी बाहेरच्या दिशेने सरकते: क्लायंटला मिळालेला पत्ता, प्रतिसाद ज्या मार्गाने जातो आणि तुम्ही मागे ठेवणारी नोंद।

कोणताही क्लायंट जोडण्यापूर्वी पूल फील्डपासून सुरुवात करा

प्रत्येक उत्पादन हे वेगळ्या पद्धतीने दाखवते, म्हणून पत्ते खरोखर वाटून देणारी वस्तू शोधा। OpenVPN मध्ये पुढील मोकळा पत्ता देणारे सर्व्हर-बाजूचे पूल निर्देश आहे, IKEv2 गेटवेमध्ये पीअर कॉन्फिगरेशनशी बांधलेला पूल विभाग आहे, आणि WireGuard मध्ये दोन्ही नाहीत कारण प्रत्येक पीअर आपला पत्ता आपल्या कॉन्फिगरेशन फाइलमध्ये घेऊन फिरतो। पूल निर्देश आणि प्रत्येक पीअरचा पत्ता परस्पर बदलण्यायोग्य नाहीत, आणि चुकीचा संपादित केल्यास उर्वरित फेरी वाया जाते।

फील्ड मिळाल्यावर आधीच अस्तित्वात असलेल्या श्रेणी सूचीबद्ध करा: कार्यालयीन LAN, प्रत्येक मार्गित साइट, क्लाउड VPC आणि सेवेत असलेला इतर कोणताही पूल। आच्छादन प्रीफिक्स अंकगणिताने ठरते, होस्ट क्रमांक परिचित वाटतात का यावरून नाही, म्हणून एकूण बेरीज त्या प्रत्येक श्रेणीशी तुलना करा। दोन्ही 10.x सारख्या दिसणाऱ्या दोन श्रेणी त्यांच्या बेरजा छेदत नाहीत तेव्हा निरुपद्रवी आणि छेदतात तेव्हा सपोर्ट घटना असतात।

नंतर पत्ता कोण जोडतो याचे कार्य आहे की ते कधी जोडतात याचे, हे ठरवा। गतिशील वाटप जे मोकळे आहे ते देते, तर ओळखीनुसार वाटप स्थिर पत्ता क्रेडेन्शियलला बांधते। निवड लिहून ठेवा, कारण ती नंतर पुन्हा जोडणे कसे दिसावे हे बदलते।

क्लायंटला प्रत्यक्षात मिळालेला पत्ता वाचा

एक क्लायंट जोडा आणि पूलने वचन दिलेले नाही, तर टनेल काय कळवते ते वाचा। क्लायंट कनेक्शन स्थितीत आपला अंतर्गत पत्ता दाखवतो, आणि Linux वर इंटरफेस तो थेट घेऊन जातो।

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

ip -4 addr show tun0
ip route get 192.168.50.20

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

तेच क्लायंट पुन्हा जोडा आणि पत्त्याकडे लक्ष द्या। गतिशील पूल तेच मूल्य किंवा वेगळे मूल्य परत देऊ शकतो आणि दोन्ही बरोबर आहेत, तर पत्ता बदलणारा ओळखीनुसार पूल बांधणीचे पालन करत नाही। ती तपासणी सेकंदांत होते आणि पहिल्या विभागात नोंदवलेला मोड अंमलात असलेला मोड आहे का हे ठरवते।

सेवेकडून प्रतिसाद मागे पाठपुरावा करा

प्रतिसाद त्याच्याकडे परत जाऊ शकतात तेव्हाच पूल चालतो। LAN वरील सेवा अंतर्गत पत्त्याला उत्तर देते, त्यामुळे तिच्या गेटवेला पूलासाठी मार्ग किंवा सेवेसमोर भाषांतर लागते। विनंती टनेलने आल्यावर प्रतिसाद वेगळ्या मार्गाने बाहेर पडल्यास, स्टेटफुल फायरवॉल किंवा उलट-मार्ग तपासणी ती टाकून देते, आणि क्लायंटला जोडणारी आणि नंतर अडकणारी सेवा दिसते। प्रत्येक होस्टसाठी मार्ग जोडण्याऐवजी पूलाला मार्ग नियोजनात एका सारांशित ब्लॉक म्हणून ठेवा।

भाषांतर उर्वरित प्रणाली काय पाहते ते बदलते। स्रोत पुन्हा लिहिला जातो तेव्हा होस्ट फायरवॉलमधील आणि अनुप्रयोग लॉगमधील पत्ता भाषांतरित असतो, त्यामुळे पूल पत्त्याविरुद्ध लिहिलेला नियम कोणत्याशी जुळत नाही आणि लॉग ओळ क्लायंटपर्यंत शोधता येत नाही। strongSwan चे फॉरवर्डिंग दस्तऐवज IKEv2 गेटवेसाठी त्या मार्गाचा सर्व्हर-बाजूचा अर्धा भाग व्यापते। DNS ही तीच मर्यादा घेऊन जाते, कारण क्लायंट पोहोचू शकत नाही अशा पत्त्यावर सोडवला जाणारा नाव नंतर आणि इतरत्र अयशस्वी होतो।

दोन क्लायंट, नंतर एक रद्दीकरण

एकाच वेळी दोन क्लायंट जोडा आणि दोन्ही पत्ते वाचा। ते वेगळे, वापरण्यायोग्य आणि पूलच्या आत असले पाहिजेत, आणि प्रत्येकाने ज्या सेवेसाठी आहे तिला पोहोचले पाहिजे। दुप्पट पत्ते देणारा पूल सहसा पहिल्या एकल-क्लायंट चाचणीत नाही, तर इथेच दिसतो।

दुसरा क्लायंट जोडलेला असताना एक क्रेडेन्शियल रद्द करा, नंतर टिकून राहिलेल्या क्लायंटवरून सेवा वापरून पहा। दुसऱ्या सत्रात अडथळा आणणारे रद्दीकरण सामायिक स्थितीकडे निर्देश करते, बहुतेक एक क्रेडेन्शियल किंवा उपकरणांमध्ये पुन्हा वापरला जाणारा एक पत्ता। रद्द केलेला क्लायंट पुन्हा जोडा आणि मोकळा झालेला पत्ता देण्याऐवजी त्याला नकार दिला जातो याची खात्री करा।

नाकारले पाहिजे अशा गंतव्याने समाप्त करा। सर्वत्र पोहोचणारा क्लायंट जोडला गेला आहे, तपासला गेलेला नाही।

चार मूल्ये पुढील बदल त्यांना सापडतील तिथे लिहा

नोंद छोटी आहे: पूल श्रेणी आणि प्रीफिक्स, वाटप मोड, परतावा मार्ग किंवा वापरातील भाषांतर, आणि त्या गंतव्यांसाठी उत्तर देणारी DNS व्याप्ती। ती तिकिटात नाही, सर्व्हर कॉन्फिगरेशनजवळ ठेवा आणि तारीख घाला। नंतर चारपैकी एक बदलणाऱ्याला उर्वरित तीन समोर हवेत, कारण पूलचा आकार बदलल्यास मार्ग तुटतो आणि मार्ग बदलल्यास DNS उत्तर तुटते।

त्यासोबत मालकीची नोंद ठेवा: टनेल श्रेणी VPN सर्व्हरची आहे, आणि LAN च्या DHCP व्याप्तीत केलेले आरक्षण टनेलमधील क्लायंटसाठी काहीही आरक्षित करत नाही। ती एकच ओळ सर्वात सामान्य पुनर्काम टाळते, जिथे कोणी आरक्षण जोडते आणि टनेलचा पत्ता त्याचे अनुसरण करेल अशी अपेक्षा करते।