साइट-टू-साइट VPN मधून IPv6 प्रीफिक्स डेलिगेशन: तपासणी सूची

टनेल उभारणे हा सोपा अर्धा भाग आहे। साइट-टू-साइट दुवा दिवसांभर प्रस्थापित राहिला, पण दूरच्या LAN वरील प्रत्येक होस्टला फक्त शांतता परत मिळत होती, असे मी पाहिले आहे, कारण त्या गेटवेमागील डेलिगेट केलेला प्रीफिक्स इंटरफेसवर कॉन्फिगर केलेला होता पण कधीही टनेलमध्ये राउट केलेला नव्हता। टनेलचे पत्ते त्या वेळी पिंगला उत्तर देत होते, आणि म्हणूनच कोणीही प्रीफिक्सकडे पाहिले नाही। डेलिगेट केलेला IPv6 प्रीफिक्स साइट VPN मधून जायचा असेल तेव्हा मी तपासतो तो क्रम असा आहे: प्रीफिक्स नकाशा, ट्रॅफिक सिलेक्टर, फॉरवर्डिंग आणि फायरवॉल, आणि नंतर परतीचा मार्ग।

टनेलला हात लावण्यापूर्वी प्रीफिक्स नकाशा लिहा

प्रीफिक्स डेलिगेशन मागणी करणाऱ्या राउटरला ब्लॉक देतो। तो पीअरवर मार्ग बसवत नाही, तो ब्लॉक on-link वाढवत नाही, आणि मागणी करणाऱ्या राउटरमागे काय आहे हे दूरच्या गेटवेला सांगत नाही। हे तीन तुम्हालाच कॉन्फिगर करायचे आहेत, आणि कोणतीही कॉन्फिग फाइल बदलण्यापूर्वी ते पत्ता आराखड्यात असले पाहिजेत।

प्रत्येक साइटसाठी डेलिगेट केलेला प्रीफिक्स, 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 नमूद करावा।

जवळपास प्रत्येक वेळी दोन चुका दिसतात। एक म्हणजे दूरच्या प्रीफिक्सला on-link मानणे, तो ब्रिज करणे किंवा टनेल इंटरफेसवर ठेवणे, त्यामुळे गेटवे ज्यांना पोहोचू शकत नाही अशा होस्टसाठी शेजारी विनंतीला उत्तर देतो। दुसरी म्हणजे फक्त एक /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 उभा राहिला तरी child SA कधीच उभा राहत नाही। दोन्ही बाजूंना कॉन्फिगर केलेले सबनेट स्थानिक कर्नल टनेलकडे राउट करत असलेल्याच्या बरोबर असले पाहिजे।

WireGuard तीच माहिती AllowedIPs मध्ये वाहतो, एका वळणासह: AllowedIPs प्राप्त करताना स्रोत फिल्टर आणि पाठवताना मार्ग आहे। साइट B च्या साइट A साठीच्या peer नोंदीत 2001:db8:a1:10::/64 राहिला तर साइट A वरून येणारे पॅकेट वैध handshake वर येतात आणि अनुमती नसल्याने टाकून दिले जातात। त्यामुळे handshake सतत नूतनीकरण होत राहतो पण उत्तर कधीच बाहेर पडत नाही, हा परिचित नमुना तयार होतो। दोन्ही टोके wg show wg0 allowed-ips ने तुलना करा। डेलिगेशन बदलल्यावर प्रत्येक वेळी ती यादी पुन्हा तपासा; जुना /64 सत्र जिवंत ठेवतो आणि नवीन प्रीफिक्स पोहोचण्याअयोग्य करतो।

आधी फॉरवर्डिंग, फायरवॉल आणि MTU वगळा

पुढील लॉग ओळ वाचण्यापूर्वी गेटवे अजिबात फॉरवर्ड करतात का याची खात्री करा। sysctl net.ipv6.conf.all.forwarding दोन्हीकडे 1 परत करायला हवे, टनेल आणि LAN इंटरफेसवरही लागू। एक सापळाही येतो: फॉरवर्डिंग सुरू केल्यावर accept_ra=1 असलेला इंटरफेस प्रदात्याकडून राउटर जाहिराती घेणे थांबवतो, त्यामुळे यंत्र टनेलमध्ये अचूक राउट करत असूनही वरचा डीफॉल्ट मार्ग गमावू शकते। प्रदात्याचा RA अजूनही आवश्यक असेल तिथे accept_ra=2 सेट करा।

नंतर फायरवॉल नियमांनी प्रीफिक्स दोन्ही दिशांना परवानगी द्यायला हवी, आणि ICMPv6 टिकायला हवे: शेजारी शोध, packet-too-big आणि destination-unreachable ऐच्छिक नाहीत। ते सोडले तर मार्गाचा 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 कधीही परत न येणारे packet-too-big संदेश दाखवते। टनेलचा MTU स्पष्ट सेट करा, किंवा mangle तक्त्यात TCP MSS मर्यादित करा, आणि लहान MTU कळवणारा ICMPv6 परत येऊ द्या।

टनेलचा पत्ता नाही, परतीचा मार्ग तपासा

सर्वाधिक वेळ खाणारी बिघाडी एकदिश मार्गनिर्देशन आहे। प्रत्येक गेटवे दूरचा प्रीफिक्स टनेलमध्ये राउट करतो, पण होस्ट स्वतःच्या डीफॉल्ट गेटवेमधून उत्तर देतात, कारण त्यांचा /64 तिथेच असतो। पॅकेट गंतव्यस्थानापर्यंत पोहोचवणे हा अर्धाच मार्ग।

दोन आदेश बहुतेक सोडवतात। साइट A वर ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 त्या स्रोताकडून येणारा प्रतिसाद कोणता इंटरफेस वापरेल ते दाखवते; साइट B वर आरशासारखी तपासणी करा। नंतर गेटवेऐवजी होस्टवरून ट्रॅफिक तयार करा आणि दोन्ही टोकांची मोजणी तुलना करा।

दूरच्या प्रीफिक्ससाठी शेजारी विनंती टनेलवर दिसली, तर तो प्रीफिक्स नसावा तिथे on-link आहे; मार्ग सुधारण्यापूर्वी ते दुरुस्त करा। Proxy NDP ब्रिजिंग खरोखरच आवश्यक असेल त्या प्रसंगांना समाविष्ट करतो, मार्गाला पर्याय नाही।

प्रीफिक्स तुमच्याखाली बदलेल अशी योजना करा

प्रीफिक्स डेलिगेशन हे डेलिगेट करणारे आणि मागणी करणारे राउटर यांच्यातील भाडेपट्टा आहे, आणि नूतनीकरण वेगळा ब्लॉक परत देऊ शकते: प्रदाता स्थलांतरानंतर वेगळा /56, किंवा टनेल चालू असलेल्या कालावधीपेक्षा लहान भाडेपट्टा। जुना प्रीफिक्स नमूद करणारे प्रत्येक ठिकाण एकाच वेळी जुने होते: मार्ग, सिलेक्टर, AllowedIPs, फायरवॉल नियम, DNS नोंदी आणि शब्दशः पत्ते हार्डकोड करणारे कोणतेही निरीक्षण। संदेश प्रवाह RFC 8415 मध्ये आहे।

प्रीफिक्स हलण्याची अपेक्षा असेल तिथे त्यावर अवलंबून नसलेला अंतर्गत पत्ता आराखडा ठेवा आणि सीमेवर भाषांतर करा। NPTv6 हा स्थितीहीन पर्याय आहे आणि अंतर्गत धोरण वाचनीय ठेवतो, पण हे प्रीफिक्स भाषांतर आहे, जादुई स्तर नाही: /64 सीमा जुळल्या पाहिजेत, चेकसम समायोजित होतात, आणि शब्दशः पत्ते एम्बेड करणारी अनुप्रयोग अजूनही तुटतात। प्रदात्याचे पत्ते टोकापासून टोकापर्यंत ठेवत असाल, तर भाडेपट्ट्याचे वर्तन आणि बदल प्रक्रिया पत्ता आराखड्यात नोंदवा।

काळाचा सामना करणाऱ्या चाचणीने संपवा: प्रत्येक LAN वरील अनुमत होस्ट दुसऱ्या LAN वरील सेवेपर्यंत पोहोचतो, प्रतिसाद टनेलमधून परत येतो, आणि तीच जोडी टनेल पुन्हा सुरू केल्यावर व डेलिगेशन नूतनीकरणानंतरही चालते। शेवटचा भाग अयशस्वी झाला तर रचना आठवडा टिकणार नाही अशा स्थितीवर अवलंबून आहे।