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 का फर्वार्डिङसम्बन्धी टिप्पणीहरू फर्कने बाटो नै बारम्बार असफल हुने भाग हो भने पढ्न लायक छन्।