साइट-से-साइट VPN के आर-पार IPv6 प्रीफ़िक्स डेलीगेशन: जाँच-सूची

साइट-से-साइट VPN के आर-पार डेलीगेट किए गए IPv6 प्रीफ़िक्स को रूट करने की जाँचें: प्रीफ़िक्स मैप, ट्रैफ़िक सिलेक्टर, फ़ॉरवर्डिंग, MTU, वापसी पथ और पुनः-क्रमांकन।

टनल खड़ी करना आसान आधा है। मैंने साइट-से-साइट लिंक को दिनों तक स्थापित रहते देखा है, जबकि दूर के LAN पर हर होस्ट को जवाब में ख़ामोशी ही मिलती रही, क्योंकि उस गेटवे के पीछे का डेलीगेट किया गया प्रीफ़िक्स किसी इंटरफ़ेस पर कॉन्फ़िगर था, पर कभी टनल में रूट नहीं हुआ। टनल के पते पूरे समय पिंग का जवाब देते रहे, और इसी वजह से किसी ने प्रीफ़िक्स की ओर नहीं देखा। जब किसी डेलीगेट किए गए IPv6 प्रीफ़िक्स को साइट VPN पार करना हो, तो मैं यह क्रम जाँचता हूँ: प्रीफ़िक्स मैप, ट्रैफ़िक सिलेक्टर, फ़ॉरवर्डिंग और फ़ायरवॉल, और फिर वापसी पथ।

टनल को छूने से पहले प्रीफ़िक्स मैप लिखें

प्रीफ़िक्स डेलीगेशन उस राउटर को ब्लॉक देता है जिसने उसका अनुरोध किया है। यह पीयर पर रूट नहीं लगाता, उस ब्लॉक को लिंक पर नहीं फैलाता, और दूर के गेटवे को नहीं बताता कि अनुरोध करने वाले राउटर के पीछे क्या है। ये तीन काम आपके हैं, और कोई भी कॉन्फ़िग फ़ाइल बदलने से पहले इनकी जगह पता-योजना में है।

हर साइट के लिए डेलीगेट किया गया प्रीफ़िक्स, LAN पर वास्तव में इस्तेमाल होने वाला /64, टनल के पते और हर रूट का मालिक दर्ज करें। प्रोवाइडर साइट A को 2001:db8:a1::/56 डेलीगेट करता है, जो अपने LAN पर 2001:db8:a1:10::/64 परोसता है; साइट B 2001:db8:b2::/64 रखता है। अगर साइट A केवल उसी एक /64 को परोसता है, तो दोनों सिरों को पूरे /56 के बजाय 2001:db8:a1:10::/64 लिखना चाहिए।

लगभग हर बार दो ग़लतियाँ दिखती हैं। एक यह कि दूर के प्रीफ़िक्स को लिंक पर मौजूद मान लिया जाए, उसे ब्रिज किया जाए या टनल इंटरफ़ेस पर रखा जाए ताकि गेटवे उन होस्टों के लिए पड़ोसी अनुरोध का जवाब दे जिन तक वह पहुँच नहीं सकता। दूसरी यह कि जब केवल एक /64 कॉन्फ़िगर है तब पूरा /56 घोषित किया जाए: रूट तालिका दावा करती है कि ब्लॉक पहुँच-योग्य है और ज़्यादातर पते काले गड्ढे में गिर जाते हैं।

दोनों सिरों के ट्रैफ़िक सिलेक्टर रूटों से मिलाएँ

IKEv2 और WireGuard दोनों बेमेल ट्रैफ़िक ठुकराते हैं, इतने चुपचाप कि टनल अब भी स्वस्थ दिखे।

strongSwan में सिलेक्टर स्पष्ट होते हैं। साइट A पर:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

साइट B का conn दोनों सबनेट का दर्पण है। जब वे मेल नहीं खाते, तो उत्तरदाता CHILD_SA को TS_UNACCEPTABLE के साथ ठुकरा देता है, इसलिए IKE_SA बनने पर भी चाइल्ड SA कभी नहीं उठता। दोनों ओर कॉन्फ़िगर किया गया सबनेट उसी के बराबर होना चाहिए जिसे स्थानीय कर्नेल टनल की ओर रूट करता है।

WireGuard वही जानकारी AllowedIPs में ले जाता है, एक मोड़ के साथ: AllowedIPs स्वीकार में स्रोत फ़िल्टर है और भेजने में रूट भी। अगर साइट B की साइट A के लिए पीयर प्रविष्टि 2001:db8:a1:10::/64 छोड़ देती है, तो साइट A के पैकेट मान्य हैंडशेक पर पहुँचते हैं और अनुमति न होने से गिरा दिए जाते हैं। इससे वही जानी-पहचानी पैटर्न बनती है: हैंडशेक बार-बार नवीनीकृत होता है पर कोई जवाब कभी बाहर नहीं जाता। दोनों सिरों की तुलना wg show wg0 allowed-ips से करें। डेलीगेशन बदलने पर वह सूची फिर जाँचें; पुराना /64 सत्र को चालू रखता है और नया प्रीफ़िक्स पहुँच से बाहर।

पहले फ़ॉरवर्डिंग, फ़ायरवॉल और MTU को बाहर करें

अगली लॉग पंक्ति पढ़ने से पहले पुष्टि करें कि गेटवे फ़ॉरवर्ड भी करते हैं। sysctl net.ipv6.conf.all.forwarding को दोनों पर 1 लौटाना चाहिए, टनल और LAN इंटरफ़ेस पर भी लागू। साथ में एक जाल आता है: फ़ॉरवर्डिंग चालू होते ही accept_ra=1 वाला इंटरफ़ेस प्रोवाइडर के राउटर विज्ञापन स्वीकार करना बंद कर देता है, इसलिए बॉक्स टनल के भीतर बखूबी रूट करते हुए भी अपना अपस्ट्रीम डिफ़ॉल्ट रूट खो सकता है। जहाँ प्रोवाइडर RA अब भी ज़रूरी हो वहाँ accept_ra=2 रखें।

फिर फ़ायरवॉल नियमों को प्रीफ़िक्स को दोनों दिशाओं में अनुमति देनी होगी, और ICMPv6 को बचना होगा: पड़ोसी खोज, पैकेट-बहुत-बड़ा और गंतव्य-अपहुँच्य वैकल्पिक नहीं हैं। इन्हें गिरा दें तो पथ MTU खोज टूट जाती है, और ऐसे कनेक्शन मिलते हैं जो खुलते हैं और फिर पहले बड़े जवाब पर अटक जाते हैं। न्यूनतम नियम-जोड़ी ऐसी दिखती है:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU इसके पीछे है। टनल उपयोगी MTU को 1500 से नीचे घटाता है, और IPv6 माँगता है कि हर लिंक कम से कम 1280 ढोए। छोटे पिंग निकल जाते हैं, बड़े फटाके पर SSH सत्र जम जाता है, और /proc/net/snmp6 ऐसे पैकेट-बहुत-बड़ा संदेश दिखाता है जो कभी वापस नहीं आते। टनल का MTU स्पष्ट रूप से सेट करें, या mangle तालिका में TCP MSS क्लैंप करें, और छोटा MTU बताने वाले ICMPv6 को लौटने दें।

टनल का पता नहीं, वापसी पथ जाँचें

सबसे ज़्यादा समय लेने वाली विफलता एकतरफ़ा रूटिंग है। हर गेटवे दूर के प्रीफ़िक्स को टनल में रूट करता है, पर होस्ट अपने ही डिफ़ॉल्ट गेटवे से जवाब देते हैं क्योंकि उनका /64 वहीं रहता है। पैकेट को गंतव्य तक पहुँचाना आधा ही रास्ता है।

What you seeLikely causeFirst check
Tunnel up, every host silentremote prefix not routed into the tunnelip -6 route get on both gateways
Handshake renews, no repliessource prefix missing from selectors or AllowedIPsipsec statusall, wg show allowed-ips
Small pings pass, transfers stallMTU or ICMPv6 packet-too-big filtered/proc/net/snmp6 counters
Old prefix still worksstale /64 left in routes or selectorsdelegation lease and route table

दो कमांड ज़्यादातर मामला तय कर देते हैं। साइट A पर ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 दिखाता है कि उस स्रोत से आने वाला जवाब कौन-सा इंटरफ़ेस इस्तेमाल करेगा; साइट B पर दर्पण जाँच करें। फिर गेटवे के बजाय होस्ट से ट्रैफ़िक पैदा करें और दोनों सिरों के काउंटर मिलाएँ।

अगर दूर के प्रीफ़िक्स के लिए पड़ोसी अनुरोध टनल पर दिखे, तो वह प्रीफ़िक्स कहीं ऐसी जगह लिंक पर है जहाँ उसे नहीं होना चाहिए; रूट बदलने से पहले उसे ठीक करें। Proxy NDP उन मामलों को कवर करता है जहाँ ब्रिजिंग सचमुच ज़रूरी है, वह रूट का विकल्प नहीं है।

अपने पैरों तले प्रीफ़िक्स बदलने की योजना बनाएँ

प्रीफ़िक्स डेलीगेशन डेलीगेट करने वाले और अनुरोध करने वाले राउटर के बीच पट्टा है, और नवीनीकरण अलग ब्लॉक लौटा सकता है: प्रोवाइडर माइग्रेशन के बाद अलग /56, या टनल जितने समय से चालू है उससे छोटा पट्टा। पुराने प्रीफ़िक्स का नाम लेने वाली हर जगह एक साथ पुरानी हो जाती है: रूट, सिलेक्टर, AllowedIPs, फ़ायरवॉल नियम, DNS रिकॉर्ड और कोई भी मॉनिटरिंग जो शाब्दिक पते हार्डकोड करती है। संदेश प्रवाह यहाँ है: RFC 8415।

जहाँ प्रीफ़िक्स के खिसकने की उम्मीद हो, वहाँ ऐसी आंतरिक पता-योजना रखें जो उस पर निर्भर न हो और सीमा पर अनुवाद करें। NPTv6 स्टेटलेस विकल्प है और आंतरिक नीति को पढ़ने योग्य रखता है, पर यह प्रीफ़िक्स अनुवाद है, कोई जादुई परत नहीं: /64 सीमाएँ मेल खानी चाहिए, चेकसम समायोजित होते हैं, और शाब्दिक पते एम्बेड करने वाले अनुप्रयोग फिर भी टूटते हैं। अगर आप प्रोवाइडर के पते शुरू से अंत तक रखते हैं, तो पट्टे का व्यवहार और बदलाव प्रक्रिया पता-योजना में दर्ज करें।

समय की कसौटी पर टिकने वाली परीक्षा से समाप्त करें: हर LAN का अनुमत होस्ट दूसरे LAN की सेवा तक पहुँचता है, जवाब टनल से लौटता है, और वही जोड़ी टनल रीस्टार्ट तथा डेलीगेशन नवीनीकरण के बाद भी काम करती है। अगर आख़िरी हिस्सा विफल हो, तो डिज़ाइन ऐसी स्थिति पर निर्भर है जो हफ़्ता नहीं टिकेगी।

संबंधित लेख