खाजगी मार्ग ठेवा आणि पुनर्निर्देशन सोडा: OpenVPN विभाजित बोगदा
फक्त खाजगी नेटवर्कसाठीच्या बोगद्याला दोन नियम लागतात: खाजगी प्रीफिक्स त्यातून जातात, सामान्य ब्राउझिंग आपला स्थानिक मार्ग ठेवते. डीफॉल्ट मार्ग हटवणे ही धोरण नाही.
बोगदा वर येतो, अॅप्लिकेशन लोड होते, आणि मग लॅपटॉपवरील बाकी सर्व विचित्र वागू लागते। एक ओळ हटवून अमलात आणलेल्या फक्त-खाजगी धोरणाचा हा नेहमीचा आकार आहे। ढकललेला डीफॉल्ट मार्ग काढल्याने रहदारी कुठे जाते हे खरंच बदलतं, पण रहदारीने त्याऐवजी कुठे जायला हवे हे ते सांगत नाही, आणि नाव निराकरणाला ते अजिबात स्पर्श करत नाही। धोरणाची चाचणी घेण्यापूर्वी त्याला दोन सकारात्मक अर्धे भाग लागतात.
पुनर्निर्देशन हटवणे हा बदलाचा फक्त अर्धा भाग आहे
संपूर्ण-बोगदा पुनर्निर्देशन आणि फक्त-खाजगी धोरण जगाबद्दल जे दावा करतात त्यात वेगळे आहेत. पुनर्निर्देशन प्रत्येक गंतव्यस्थानाचा दावा करते, तर खाजगी धोरण यादीचा दावा करते आणि बाकीचे शांत ठेवते। यादी न लिहिता दावा हटवल्यास स्थानिक नेटवर्कबाहेर कुठेही न पोहोचणारा क्लायंट तयार होतो, जो धोरणातील त्रुटीपेक्षा मार्गनिर्देशन बिघाडासारखा दिसतो। दावा काढण्यापूर्वी यादी लिहा, मग त्या दोन पायऱ्यांचा क्रम महत्त्वाचा राहत नाही।
दोन्ही अर्धे भाग डीफॉल्ट नाहीत, आवश्यकता आहेत. खाजगी प्रीफिक्सना बोगद्यात प्रवेश करावा लागतो, आणि सामान्य गंतव्यस्थानांनी जोडणीपूर्वीचा मार्ग ठेवावा लागतो।
संस्था संपूर्ण बोगदा बंधनकारक करत असेल, तर यातले काहीही लागू होत नाही। फक्त-खाजगी रचना अशा तैनातींसाठी आहे जिथे विभाजित मार्गनिर्देशन मंजूर आहे।
pull-filter एक जुळणी आहे, स्विच नाही
pull-filter निर्देश अशा ढकललेल्या पर्याय काढून टाकतो ज्यांची नावे प्रीफिक्सशी जुळतात, आणि तेवढेच करतो। पुनर्निर्देशन दुर्लक्षित केल्यास बाकीचा प्रत्येक ढकललेला पर्याय जागेवरच राहतो, जे सहसा तुम्हाला हवे असते: मार्ग, DNS संयोजना आणि मार्ग-गेटवे मूल्य सर्व येतात. स्थानिक प्रोफाइलमध्ये लिहिलेला निर्देशही तो काढू शकत नाही, कारण गाळणी सर्व्हर ढकलतो त्यावर लागू होते।
route ने सुरू होणाऱ्या प्रत्येक पर्यायाकडे दुर्लक्ष करण्याच्या मोहाला तोंड द्या। तो नमुना जोडणीला आवश्यक असलेले खाजगी मार्गही फेकून देतो, आणि बोगदा ज्या गेटवे माहितीवर अवलंबून आहे ती गमावू शकतो।
route-nopull दिसते त्यापेक्षा मोठा निर्णय आहे। तो क्लायंटला ढकललेले मार्ग आणि DHCP शैलीचे पर्याय एक गट म्हणून स्वीकारण्यापासून थांबवतो, जे एक पर्याय गाळण्यापेक्षा वेगळे धोरण आहे।
मार्ग यादी अॅप्लिकेशनपासून बाहेरच्या दिशेने लिहा
वापरकर्ता प्रत्यक्षात जे उघडतो त्यापासून सुरुवात करा, मग आधार देणारे भाग जोडा। 10.60.20.15 वरील अॅप्लिकेशन त्याचे सबनेट 10.60.0.0/16 सूचित करते, आणि खाजगी नाव त्याला उत्तर देणाऱ्या निराकारकाचे सूचित करते। म्हणून एक अॅप्लिकेशन मागणाऱ्या वापरकर्त्याला दोन गंतव्ये आणि एक DNS निर्णय लागतो। त्या यादीपलीकडील सर्व रचनेनेच कक्षेबाहेर आहे, आणि हेच धोरण पुनरावलोकनयोग्य ठेवते।
सहकार्य करणाऱ्या सर्व्हरवर ते दोन ढकललेले मार्ग बनतात, आणि त्यातले एकही पुनर्निर्देशन नाही। विद्यमान सेवा जे बोगदा स्थळविन्यास आणि मार्ग-गेटवे मूल्य देते ते ठेवा।
हे धोरण फक्त काही वापरकर्त्यांना हवे असल्यास ते प्रति क्लायंट किंवा प्रति गट लागू करा। एका संघाची आवश्यकता भागवण्यासाठी सर्वांचे मार्गनिर्देशन बदलणे हाच विभाजित बोगदा खंडात बदलण्याचा मार्ग आहे।
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
DNS ला तोच मार्ग घेऊ द्या
निराकारकापर्यंतचा मार्ग निराकारक धोरण नाही। systemd-resolved क्लायंटवर अर्थपूर्ण निकाल म्हणजे खाजगी नावस्थानासाठीचे मार्गनिर्देशन क्षेत्र असते जे अंतर्गत निराकारकाकडे निर्देश करते, आणि त्यामुळेच फक्त ती नावे ते वापरतात. Windows क्लायंटला त्याऐवजी स्वतःची नावस्थान धोरण यंत्रणा लागते। प्रोफाइलमधील DNS सर्व्हर ओळ स्वतः कोणतेही स्थापित करत नाही।
प्रोफाइलने काय मागितले नाही, ऑपरेटिंग सिस्टमने काय निवडले ते तपासा। Linux वर resolvectl status प्रत्येक जोडणीसाठी क्षेत्र आणि सर्व्हर दाखवते; Windows वर नावस्थान धोरण सारणी समतुल्य पुरावा आहे।
निराकारक बोगद्यातून पोहोचण्यायोग्य ठेवा, नाहीतर धोरण अशा पत्त्याकडे निर्देश करते ज्याला विचारता येत नाही। बोगदा ज्या निराकारक पत्त्यापर्यंत पोहोचत नाही तो कार्यरत धोरणाचे कालबाह्यत्वात रूपांतर करतो।
पुन्हा जोडणीत दोन्ही अर्धे तपासा
बदलानंतर क्लायंट पुन्हा जोडा आणि खाजगी पत्ता व सार्वजनिक पत्ता यांचा प्रभावी मार्ग तपासा। मग खाजगी नाव आणि सार्वजनिक नाव निराकरण करा आणि प्रत्येकाने इच्छित निराकारक वापरल्याची खात्री करा। सार्वजनिक संकेतस्थळ लोड होणे फक्त दुसरा अर्धा भाग सिद्ध करते, आणि सहसा तोच अर्धा भाग योगायोगाने कार्यरत असतो।
तयार धोरण एका वाक्यात नोंदवा: हे प्रीफिक्स आणि नावे ही जोडणी वापरतात, बाकी सर्व स्थानिक मार्गाचे अनुसरण करते। मग प्रत्येक लॉगिननंतर अॅडॉप्टर संयोजना दुरुस्त करण्याऐवजी ते प्रोफाइलमध्ये ठेवा।