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 च्या फॉरवर्डिंगवरील टिपा परतीचा मार्ग सतत अयशस्वी होणारा भाग असेल तर वाचण्यासारख्या आहेत।