साइट-टू-साइट 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 wg0वह दूसरा कमांड वैकल्पिक नहीं है जब आपने wg-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 प्रति पक्ष स्थानांतरण बताता है, और शून्य प्राप्त बाइट वाला हैंडशेक दूरस्थ पक्ष की सूची या उसके वापसी रूट की ओर इशारा करता है।
अंत में प्रीफ़िक्स, पक्ष का सिलेक्टर या रूट, वापसी रास्ते का निर्णय और फ़ायरवॉल प्रविष्टि को बाकी टनल सूची के साथ दर्ज करें। फिर एक गेटवे रीबूट करें और दोबारा जाँचें: हाथ से जोड़ा रूट गायब हो जाता है और अगले व्यक्ति को उसे फिर से खोजना नहीं पड़ना चाहिए।