साइट-देखि-साइट VPN मा दोस्रो सबनेट थप्ने: दुई बाटो
नीति-आधारित टनेललाई दुवैतर्फ मिल्ने सिलेक्टर चाहिन्छ; रुट-आधारितलाई रुट चाहिन्छ। सही बाटो छान्नुहोस् र पहिले फर्कने रुट सुधार्नुहोस्।
चलिरहेको साइट-देखि-साइट टनेलमा दोस्रो सबनेट थप्न एक डिजाइनमा पाँच मिनेट र अर्कोमा लगभग सारा दिउँसो लाग्छ। टनेलले तपाईंले नाम दिनुभएका प्रिफिक्सका लागि रुट बसाल्यो भने रुट थप्नुहुन्छ र ट्राफिक त्यसैलाई पछ्याउँछ। एक स्थिर सिलेक्टर जोडीमा वार्ता गर्दा, दुवै पक्ष मिल्ने जोडीमा सहमत नभएसम्म नयाँ प्रिफिक्स असुरक्षित रहन्छ। तीन कुराले निर्धारण गर्छ: प्रत्येक पक्षको कन्फिगरेशनले वास्तवमा के वर्णन गर्छ, वार्ता भएको ट्राफिक सानोभन्दा सानो मिल्ने जोडीसम्म खुम्चन्छ कि, र नयाँ दायराको फर्कने बाटो कसको हो।
स्थिति लेबल होइन, कर्नेल पढ्नुहोस्
जोडिएको भनी जानकारी दिने टनेलले कम्तीमा एउटा चाइल्ड एसोसिएसन बसालेको हुन्छ, तर तपाईंले सोचेको नहुन पनि सक्छ। Linux मा कर्नेलले के लागू हुन्छ देखाउँछ: ip xfrm policy ले सिलेक्टर जोडीहरू सूचीबद्ध गर्छ र swanctl --list-sas (वा पुरानो ipsec statusall) ले दुवै पक्ष के मा सहमत भए देखाउँछ, प्रत्येक दिशाको ट्राफिक सिलेक्टरसहित। नयाँ प्रिफिक्स दुवैमा नभए, कन्फिग फाइल के भने पनि त्यो असुरक्षित छ।
यसलाई रुट तालिकासँग तुलना गर्नुहोस्। रुट-आधारित व्यवस्थामा टनेल यन्त्र सुरक्षित प्रिफिक्सका लागि अर्को हप हो। नीति-आधारित व्यवस्थामा दूरको सबनेटका लागि छुट्टै रुट प्रायः हुँदैन, डिफल्ट रुट मात्र, किनकि ट्राफिक तालिकाले होइन नीतिले छान्छ।
नीति-आधारित: दुवै पक्षले नयाँ प्रिफिक्स सूचीबद्ध गर्नुपर्छ
strongSwan शब्दावलीमा सिलेक्टर चाइल्ड कन्फिगको local_ts र remote_ts मा बस्छ, leftsubnet र rightsubnet का उत्तराधिकारी। नयाँ प्रिफिक्स दुवै पक्षमा ऐनाजस्तै देखिनुपर्छ: साइट A ले स्थानीय भन्नेलाई साइट B ले दूर भन्छ। भिन्नताले सफा त्रुटि विरलै दिन्छ। दुवै पक्ष प्रतिच्छेदसम्म खुम्चिन्छन्, पुरानो प्रिफिक्स चलिरहन्छ र नयाँ मात्र चुपचाप असफल हुन्छ।
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense वा OPNsense मा यसको अर्थ नयाँ स्थानीय सबनेटलाई नयाँ दूरको सबनेटसँग जोड्ने दोस्रो Phase 2 प्रविष्टि र त्यसपछि लागू गर्नु हो। पुरानो प्रविष्टि राख्नुहोस्; बदल्दा मूल सबनेट थपिनुको सट्टा सर्छ। विद्यमान Phase 2 ले पहिले नै 0.0.0.0/0 जस्तो सुपरनेट वा संक्षिप्त दायरा ढाकेको छ भने छेउमा साँघुरो प्रविष्टि नथप्नुहोस्: ओभरल्याप सिलेक्टरले प्रतिस्पर्धी नीति बसाल्छन् र मूल्यांकन क्रमले विजेता तय गर्छ।
IKEv1 ले हरेक सबनेट जोडीलाई आफ्नै Phase 2 बनाउँछ, र प्रत्येक आदानप्रदानमा एउटा जोडी लिने पक्षले बाँकी छोड्छ। IKEv2 ले एउटा चाइल्डमा धेरै सिलेक्टर जोडी राख्न सक्छ, तर दुवै कार्यान्वयनले स्वीकारे मात्र। swanctl --list-sas को सूची सत्य हो; तपाईंले लेखेको अनुरोध हो।
रुट-आधारित: रुट नै नीति हो
XFRM इन्टरफेस वा VTI यन्त्रले रुट तालिकाअनुसार ट्राफिक बोक्छ। नयाँ प्रिफिक्स दुवै साइटमा यन्त्रतर्फ देखाउनुहुन्छ र इन्टरफेसको रूपान्तरणसँग बाँधिएको अवस्था लागू हुन्छ। सिंक गर्न सिलेक्टर जोडी छैन, त्यसैले सबनेट बढ्दा यो डिजाइन राम्रोसँग स्केल हुन्छ। strongSwan फर्वार्डिङ गाइड ले कर्नेल पक्ष विस्तारमा बताउँछ।
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard अझ अगाडि जान्छ। AllowedIPs एकै समयमा क्रिप्टो अनुमति सूची र wg-quick मार्फत रुट तालिका प्रविष्टि हो। एउटै पक्षमा प्रिफिक्स थप्नुहोस् त ह्यान्डशेक, बाहिर जाने प्याकेट र मौनता पाइन्छ, किनकि दूरको पक्षले स्रोत आफ्नो सूचीमा नभएका प्याकेट फ्याँक्छ। wg set रूपले सारा सूची बदल्छ, त्यसैले पहिले चलेका प्रिफिक्स फेरि लेख्नुहोस्, नत्र तिनी काटिनेछन्:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0wg-quick सट्टा wg set प्रयोग गर्नुभयो भने त्यो दोस्रो आदेश वैकल्पिक होइन। कर्नेलले नयाँ सूची तुरुन्तै स्वीकार्छ, तर कसैले त्यसका लागि रुट थप्दैन, त्यसैले स्थानीय रूपमा बनेको ट्राफिक अझै डिफल्ट गेटवेबाट बाहिर जान्छ। नयाँ WireGuard सबनेट टनेल होस्टबाट चल्ने र ल्यापटपबाट नचल्ने सबैभन्दा सामान्य कारण यही हो।
फर्कने बाटो टनेलभन्दा बढी असफल हुन्छ
नयाँ दूरको सबनेटका होस्टले जवाफ VPN गेटवेबाट फर्काउनुपर्छ। त्यो गेटवे तिनको डिफल्ट राउटर नभए जवाफ LAN राउटरकहाँ जान्छ, जसले त्यो फ्याँक्छ वा निजी स्रोत ठेगानासहित इन्टरनेटमा पठाउँछ। गेटवेबाट होइन, दूर पक्षको होस्टबाट परीक्षण गर्नुहोस्: Linux मा ip route get 10.30.20.15 वा PowerShell मा Find-NetRoute -RemoteIPAddress 10.30.20.15 ले होस्टले साँच्चै प्रयोग गर्ने अर्को हप देखाउँछ। जवाफ टनेलको अन्त्य बिन्दु होइन भने त्यहाँ नयाँ प्रिफिक्सका लागि स्थिर रुट थप्नुहोस्।
फर्कने रुट नभएको साइटमा स्रोत NAT वैध विकल्प हो र धेरै hub-and-spoke परिनियोजनले हरेक सर्भर छुनबाट यसै गरी बच्छन्। गन्तव्य पक्षको गेटवेमा पनि नयाँ प्रिफिक्समा यो लागू गर्नुहोस्:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEलागत वास्तविक छ। दूरका लगले व्यक्तिगत स्रोत ठेगाना देखाउन छोड्छन् र मूल सबनेटमा आधारित फायरवाल नियम गेटवेका लागि एउटै नियममा मिल्छन्। रुट नभएकाले होइन, जानाजान छान्नुहोस्।
फायरवाल फर्कने बाटोको अर्को आधा हो। जोन-आधारित यन्त्रले विद्यमान टनेल इन्टरफेसको जोन नयाँ सबनेटसम्म स्वतः विस्तार गर्दैन र पुरानो प्रिफिक्सका लागि लेखिएको नियम मिल्दैन। IPsec लाई दोष दिनुअघि नयाँ सबनेट जोनमा वा दुवै दिशाको नियम जोडीमा थप्नुहोस्।
तीन प्रश्नले निर्णय गर्नुहोस्, त्यसपछि ट्राफिकले प्रमाणित गर्नुहोस्
छोटो रूप: पक्षको कन्फिगरेशनले प्रिफिक्सको नाम दिन्छ (नीति-आधारित), वा ट्राफिक इन्टरफेसमा रुट हुन्छ (रुट-आधारित)? दुवै छेउले नयाँ प्रिफिक्स सूचीबद्ध गर्छन्? नयाँ सबनेटबाट मूल स्रोत दायरासम्म फर्कने बाटो छ?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
प्रमाणीकरण त्यही ठाउँ हो जहाँ धेरै परिवर्तन धेरै चाँडै बन्द हुन्छन्। गेटवेबाट पिंगले थोरै प्रमाणित गर्छ, किनकि गेटवे आफैंबाट पठाउँछ र होस्टभन्दा फरक नीतिसँग मिल्छ। नयाँ सबनेटको होस्टबाट पिंग गर्नुहोस्, त्यसपछि परिवर्तनको कारण बनेको एप्लिकेसन चलाउनुहोस् र स्थिति आइकन होइन काउन्टर हेर्नुहोस्।
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showनीति-आधारित टनेलमा ip xfrm state का काउन्टर दुवै दिशामा बढ्नुपर्छ; समतल काउन्टर भनेको प्याकेट रुट भयो तर छानिएन। WireGuard मा wg show ले प्रत्येक पक्षको स्थानान्तरण देखाउँछ र शून्य प्राप्त बाइटको ह्यान्डशेकले दूर पक्षको सूची वा त्यसको फर्कने रुटतर्फ संकेत गर्छ।
प्रिफिक्स, पक्षको सिलेक्टर वा रुट, फर्कने बाटोको निर्णय र फायरवाल प्रविष्टि बाँकी टनेल सूचीसँगै अभिलेख गरेर अन्त्य गर्नुहोस्। त्यसपछि एउटा गेटवे रिबुट गरी फेरि परीक्षण गर्नुहोस्: हातले थपिएको रुट हराउँछ र अर्को व्यक्तिले त्यो फेरि पत्ता लगाउनु नपर्ने हुनुपर्छ।