VPN से केवल एक निजी सबनेट कैसे भेजें

टनल से एक निजी सबनेट और बाकी सब कुछ आपके सामान्य मार्ग से भेजना एक छोटी मांग है जिसे गलत करने के बहुत से तरीके हैं। नतीजा split tunneling नाम का चेकबॉक्स तय नहीं करता, बल्कि यह तय करता है कि निर्णय कहाँ लागू होता है: क्लाइंट की अपनी मार्ग तालिका, सर्वर द्वारा भेजा गया मार्ग, या दोनों सिरों के बीच तय नीति। गलत परत चुनें और आपको या तो वह पूरी टनल मिलेगी जो आपने कभी नहीं चाही, या ऐसी टनल की ओर मार्ग मिलेगा जिसे दूसरा पक्ष स्वीकार करने से इनकार करता है। कोई भी कॉन्फ़िगरेशन खोलने से पहले मैं तीन शर्तों वाला परीक्षण इस्तेमाल करता हूँ और फिर नीचे दिए गए किसी एक तंत्र को चुनता हूँ।

डिज़ाइन तय करने वाली तीन शर्तें

पहला, आपको नेटवर्क के मालिक से सटीक प्रीफ़िक्स और मास्क चाहिए। 10.x नेटवर्क प्रीफ़िक्स नहीं है; 10.20.0.0/16 प्रीफ़िक्स है। पुष्टि करें कि यह आपके घरेलू LAN, Docker ब्रिज या चलाए जा रहे किसी अन्य VPN से ओवरलैप नहीं करता, क्योंकि ओवरलैप मार्ग को अस्पष्ट कर देता है और कर्नेल वह प्रविष्टि चुन लेता है जो आपका इरादा नहीं था।

दूसरा, लौटने वाले ट्रैफ़िक का जवाब कौन देता है। पैकेट को टनल में भेजना उसे केवल VPN सर्वर तक पहुँचाता है। अगर सबनेट ऐसे अन्य राउटर के पीछे है जिसके पास आपके क्लाइंट पूल तक वापसी मार्ग नहीं है, तो सर्वर को ट्रैफ़िक मास्करेड करना होगा, या उस राउटर को आपका पूल सीखना होगा। क्लाइंट की ओर का कोई मार्ग गायब वापसी पथ को ठीक नहीं करता।

तीसरा, प्रवर्तन बिंदु। कुछ क्लाइंट मार्ग स्थापित करते हैं और बाकी काम ऑपरेटिंग सिस्टम करता है। दूसरे नीति पर बातचीत करते हैं, और गेटवे जो नीति स्वीकार नहीं करता वह कोई टनल ही नहीं बनाती: पैकेट बिना स्पष्ट त्रुटि के गिरा दिए जाते हैं। कुछ भी लिखने से पहले पता करें कि इन दोनों में से आपका मामला कौन-सा है।

WireGuard: AllowedIPs ही मार्ग तालिका है

क्लाइंट पर, AllowedIPs उन गंतव्यों की सूची देता है जो टनल में आ सकते हैं, और wg-quick हर प्रविष्टि को सामान्य मार्ग बना देता है। इसलिए इस काम का क्लाइंट वाला आधा हिस्सा एक पंक्ति है।

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

अब उसी क्लाइंट के लिए सर्वर की प्रविष्टि से तुलना करें। वह बताती है कि सर्वर क्लाइंट को क्या भेजेगा, जो आमतौर पर क्लाइंट का टनल पता होता है, निजी सबनेट नहीं।

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

इन दोनों को बदलना वह गलती है जो मैं सबसे ज़्यादा देखता हूँ। सर्वर के peer खंड के नीचे 10.20.0.0/16 रखना कहता है कि पूरा सबनेट उस क्लाइंट के पीछे है, और यह साइट-से-साइट दावा है, अनुमति नहीं। जो पैकेट किसी भी peer के AllowedIPs से मेल नहीं खाते वे चुपचाप गिरा दिए जाते हैं, इसलिए गलत प्रविष्टि बिल्कुल फ़ायरवॉल समस्या जैसी दिखती है।

अगर आप मार्ग खुद प्रबंधित करते हैं, तो [Interface] के नीचे Table = off सेट करें और चाहा गया मार्ग जोड़ें। तब कुछ भी अपने आप नहीं जुड़ता, इसलिए मार्ग उसी में रहना चाहिए जो इंटरफ़ेस को ऊपर उठाता है।

OpenVPN: मार्ग भेजें, फिर सुनिश्चित करें कि वह पहुँचे

सामान्य सर्वर पर बदलाव सर्वर कॉन्फ़िग में क्लाइंट पूल के पास एक निर्देश है।

push "route 10.20.0.0 255.255.0.0"

क्लाइंट जुड़ते समय उसे जोड़ता है। विफलता तब दिखती है जब वही प्रोफ़ाइल redirect-gateway भी भेजता है, या जब किसी ने पहले ही route-nopull जोड़ दिया है: पहला सत्र को पूरी टनल बना देता है, और दूसरा आपका सहित हर भेजे गए मार्ग को त्याग देता है।

पूरी-टनल सर्वर के सामने संकीर्ण व्यवहार चाहने वाले क्लाइंट को केवल वे हिस्से अनदेखा करने चाहिए जो उसे नहीं चाहिए। OpenVPN 2.4 और बाद में, pull-filter ठीक इसी के लिए है।

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

पता परिवारों को अलग रखें: भेजा गया IPv4 मार्ग IPv6 में हल होने वाली आंतरिक सेवा के लिए कुछ नहीं करता, और वह सेवा टनल से विफल हो जाती है जबकि बाकी सब ठीक दिखता है।

जब निजी सबनेट VPN सर्वर पर नहीं बल्कि किसी अन्य क्लाइंट के पीछे हो, तो सर्वर को बताना पड़ता है। client-config-dir के ज़रिए हर क्लाइंट के लिए एक फ़ाइल जोड़ें जिसमें iroute 10.20.0.0 255.255.0.0 हो, साथ में मेल खाता route ताकि दूसरे क्लाइंट वह पथ सीखें। iroute के बिना सर्वर के पास उस प्रीफ़िक्स को ठीक उसी टनल से भेजने का कोई कारण नहीं है।

IPsec: ट्रैफ़िक चयनकर्ताओं को सहमत होना पड़ता है

IPsec में भेजने के लिए कोई मार्ग नहीं है। दोनों सिरे तय करते हैं कि कौन से पते टनल के भीतर रहते हैं, और सहमत चयनकर्ताओं के बाहर का ट्रैफ़िक न तो एन्क्रिप्ट होता है और न ही उससे होकर भेजा जाता है। strongSwan क्लाइंट पर चयनकर्ता स्पष्ट होते हैं।

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

अगर गेटवे दोनों ओर 0.0.0.0/0 के साथ कॉन्फ़िगर है, तो IKEv2 का संकुचन आमतौर पर चाइल्ड SA को दोनों प्रस्तावों के प्रतिच्छेद तक घटा देता है, जो चाहा गया परिणाम है। कुछ गेटवे इसके बजाय ऐसा प्रस्ताव अस्वीकार कर देते हैं जो उनके कॉन्फ़िगर किए गए चयनकर्ताओं से मेल नहीं खाता, और तब लॉग मार्ग शिकायत की जगह विफल चाइल्ड SA दिखाता है। जब ऐसा हो, बदलाव गेटवे का है, क्योंकि क्लाइंट मार्ग ऐसे चयनकर्ता के लिए टनल नहीं बना सकता जिसे दूसरा पक्ष स्वीकार नहीं करेगा।

Windows पर अंतर्निहित क्लाइंट वही निर्णय दो सेटिंग्स के पीछे छिपाता है। टनल विभाजन चालू होना चाहिए, और प्रीफ़िक्स प्रोफ़ाइल पर पंजीकृत होना चाहिए।

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

प्रीफ़िक्स का पंजीकरण ही उसे पुनः कनेक्ट के बाद टिकाए रखता है, जो हाथ से जोड़ा गया मार्ग नहीं करता।

एंडपॉइंट और DNS को निर्णय से बाहर रखें

VPN एंडपॉइंट टनल के बिना पहुँच योग्य रहना चाहिए, वरना टनल खुद में ढह जाती है। जब केवल 10.20.0.0/16 का मार्ग बनता है तब यह अपने आप होता है, क्योंकि एंडपॉइंट सार्वजनिक पता है। पूरी-टनल प्रोफ़ाइल में ऐसा नहीं है, और टनल उठने से पहले क्लाइंट को एंडपॉइंट तक स्पष्ट होस्ट मार्ग चाहिए।

DNS दूसरा निर्णय है जो मार्ग भेजना आपके लिए नहीं लेता। आंतरिक नाम आमतौर पर ऐसे रिज़ॉल्वर से हल होते हैं जहाँ केवल निजी नेटवर्क पहुँच सकता है। अगर सर्वर DNS सर्वर भेजता है तो हर नाम उससे होकर जाता है; अगर नहीं, तो आंतरिक नाम या तो विफल होते हैं या सार्वजनिक रूप से किसी ऐसी चीज़ में हल हो जाते हैं जो आपका इरादा नहीं था। विभाजित DNS आंतरिक रिज़ॉल्वर पर एक खोज डोमेन रखता है, पर यह क्लाइंट समर्थन पर निर्भर है, इसलिए इसे मार्ग का दुष्प्रभाव नहीं बल्कि अलग काम मानें।

जाँचें, फिर रीबूट करें और फिर जाँचें

तीन परीक्षण मार्ग का सवाल ढक देते हैं। कर्नेल से पूछें कि दूर का पता कहाँ जाएगा, सबनेट के अंदर से कुछ लाएँ, फिर पुष्टि करें कि सामान्य सार्वजनिक अनुरोध अब भी आपके सामान्य कनेक्शन से बाहर जा रहा है।

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

पहली पंक्ति किसी इंटरफ़ेस का नाम बताती है। अगर वह आपके भौतिक इंटरफ़ेस का नाम बताती है, तो मार्ग कभी पहुँचा ही नहीं। Windows पर Find-NetRoute -RemoteIPAddress 10.20.5.7 उसी सवाल का जवाब देता है, और अंतिम परीक्षण में अब भी आपका सामान्य पता दिखना चाहिए, VPN सर्वर का नहीं।

फिर रीबूट करें। हाथ से जोड़े गए मार्ग गायब हो जाते हैं, जबकि प्रोफ़ाइल, भेजे गए कॉन्फ़िग या AllowedIPs से आए मार्ग लौट आते हैं। अगर संकीर्ण पहुँच रीबूट से पहले काम करती है और बाद में विफल होती है, तो दोष मार्ग में नहीं, टनल के शुरू होने के तरीके में है।

इसे पूरा कहने से पहले चार बातें पुष्टि करें: प्रीफ़िक्स नेटवर्क मालिक से आया है और स्थानीय किसी चीज़ से ओवरलैप नहीं करता, वापसी पथ मौजूद है या मास्करेड नियम उसकी जगह लेता है, आपने जो तंत्र कॉन्फ़िगर किया है वही आपके प्लेटफ़ॉर्म पर मार्ग लागू करता है, और साफ़ रीबूट के बाद वही परीक्षण पास होते हैं। strongSwan की फ़ॉरवर्डिंग टिप्पणियाँ पढ़ने लायक हैं अगर वापसी पथ ही वह हिस्सा है जो बार-बार विफल होता है।