साइट-टु-साइट VPN मार्फत IPv6 प्रिफिक्स डेलिगेसन: जाँचसूची
डेलिगेट गरिएको IPv6 प्रिफिक्स साइट-टु-साइट VPN मार्फत रुट गर्ने जाँचहरू: प्रिफिक्स नक्सा, ट्राफिक सिलेक्टर, फर्वार्डिङ, MTU, फिर्ती मार्ग र पुनःनम्बरिङ।
टनेल उठाउनु सजिलो आधा हो। साइट-टु-साइट लिंक दिनौसम्म स्थापित रहँदा टाढाको 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 } acceptMTU यसको पछाडि छ। टनेलले प्रयोगयोग्य MTU लाई 1500 भन्दा तल घटाउँछ, र IPv6 ले हरेक लिंकले कम्तीमा 1280 बोक्नुपर्ने माग गर्छ। साना पिङ जान्छन्, SSH सत्र ठूलो उछालमा जम्छ, र /proc/net/snmp6 मा कहिल्यै फर्किने packet-too-big सन्देश देखिन्छन्। टनेलको MTU स्पष्ट सेट गर्नुहोस्, वा mangle तालिकामा TCP MSS सीमित गर्नुहोस्, र सानो MTU जनाउने ICMPv6 फर्किन दिनुहोस्।
टनेलको ठेगाना होइन, फिर्ती मार्ग परीक्षण गर्नुहोस्
सबैभन्दा बढी समय खाने खराबी एकदिश रुटिङ हो। हरेक गेटवेले टाढाको प्रिफिक्स टनेलमा रुट गर्छ, तर होस्टहरू आफ्नै पूर्वनिर्धारित गेटवेबाट जवाफ दिन्छन् किनकि तिनको /64 त्यहीँ बस्छ। प्याकेटलाई गन्तव्यसम्म पुर्याउनु आधा बाटो मात्र हो।
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
दुई आदेशले धेरैजसो समाधान गर्छन्। साइट 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 को सेवा पुग्छ, जवाफ टनेलबाट फर्किन्छ, र त्यही जोडी टनेल पुनःसुरु र डेलिगेसन नवीकरणपछि पनि चल्छ। अन्तिम भाग असफल भयो भने डिजाइन हप्ता नटिक्ने अवस्थामा निर्भर छ।