साइट-टू-साइट 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 प्रत्येक बाजूचे हस्तांतरण सांगते आणि शून्य प्राप्त बाइटची हातमिळवणी दूरच्या बाजूच्या यादीकडे किंवा तिच्या परतीच्या मार्गाकडे निर्देश करते.
प्रीफिक्स, बाजूचा सिलेक्टर किंवा मार्ग, परतीच्या मार्गाचा निर्णय आणि फायरवॉल नोंद उर्वरित टनेल यादीसह नोंदवून संपवा. नंतर एक गेटवे रीबूट करा आणि पुन्हा चाचणी करा: हाताने जोडलेला मार्ग नाहीसा होतो आणि पुढच्या व्यक्तीला तो पुन्हा शोधावा लागू नये.