दुई साइटबीच अवस्थित VPN मार्फत IPv6 रुटिङ

केवल IPv4 भएको WAN ले पनि आन्तरिक IPv6 बोक्न सक्छ। सेलक्टर, कर्नेल रुट, फर्वार्डिङ र जवाफहरू चुपचाप फ्याँक्ने फिर्ती प्रिफिक्स हेर्नुहोस्।

जब तपाईं दुई साइटबीचको टनेलमा IPv6 प्रिफिक्स थप्नुहुन्छ, प्याकेट रेखाचित्रले सुझाएजस्तो यात्रा गर्दैन। स्थानीय गेटवेले पूरा IPv6 प्याकेट लिन्छ, इन्क्रिप्ट गर्छ र त्यसको अगाडि बाहिरी IP हेडर राख्छ जसको ठेगाना परिवार भित्री सामग्रीले होइन, टुप्पाका ठेगानाले निर्धारण गर्छ। टाढाको गेटवेले त्यो बाहिरी हेडर हटाएर मूल प्याकेट आफ्नो LAN मा पठाउँछ, जहाँ त्यो फेरि साधारण IPv6 प्याकेट हुन्छ। बाहिरी टनेल र भित्री ट्राफिक दुई अलग कुराकानी हुन् जसले एउटा कुञ्जी, एउटा टुप्पा जोडी र यसबाहेक केही साझा गर्दैनन्।

दुई हेडर, दुई ठेगाना परिवार

IPsec टनेल मोडमा भित्री IPv6 प्याकेट ESP हेडरपछाडिको पेलोड बन्छ। त्यो ESP प्याकेट बोक्ने बाहिरी हेडर IPv4 वा IPv6 हुन सक्छ र local_addrs तथा remote_addrs पछ्याउँछ। WireGuard त्यही काम कम औपचारिकतामा गर्छ: भित्री प्याकेट साथीको टुप्पातर्फ जाने UDP डेटाग्रामको पेलोड हो। दुवैले भित्री हेडर अछुत राख्छन्, त्यसैले टाढाको पक्षले डिक्याप्सुलेसनपछि यसलाई रुट गर्न सक्छ।

साइटबीचको बाटोले UDP 4500 मात्र देख्छ जब IPsec ले NAT ट्राभर्सल प्रयोग गर्छ, वा पूर्वनिर्धारित WireGuard स्रोताका लागि UDP 51820। बाटोमा कुनै पनि राउटर केवल IPv4 हुन सक्छ र IPv6 ट्राफिक तैपनि तर्छ, किनकि त्यो त्यो बाटोमा कहिल्यै IPv6 प्याकेटका रूपमा देखिँदैन। यसले सफा पहिलो विभाजन दिन्छ: tcpdump -ni eth0 udp port 51820 इन्क्रिप्टेड बाटो देखाउँछ, tcpdump -ni wg0 ip6 भित्री ट्राफिक देखाउँछ। बाहिरी क्याप्चर व्यस्त र भित्री शान्त भएको मतलब कर्नेलले IPv6 टनेलमा राखिरहेको छैन; यो रुटिङ वा नीति हो, लिङ्कको अवस्था होइन।

गेटवेले फर्वार्ड गर्दा भित्री Hop Limit पनि घटाउँछ, त्यसैले टुप्पाहरू IPv6 बाटोमा राउटर गनिन्छन्। बाहिरी हप सङ्ख्या र भित्री Hop Limit अलग-अलग चल्छन्, र टाढाको गेटवेमा मर्ने प्याकेट फर्वार्डिङमा मर्‍यो, इन्क्रिप्शनमा होइन।

सेलक्टर र AllowedIPs अनुमति सूची हुन्

IKEv2 ले child SA कुन भित्री प्रिफिक्स बोक्न सक्छ भन्ने वार्ता गर्छ। strongSwan 5.9 र पछि तिनलाई swanctl.conf मा लेख्दा यस्तो देखिन्छ:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

यदि local_ts र remote_ts छोड्नुभयो भने strongSwan ले तिनलाई आफ्नो छानिएको इन्टरफेसको सबनेटबाट निकाल्छ। दोहोरो स्ट्याक भएको होस्टमा त्यो सर्टकटले प्रायः केवल IPv4 को जोडी दिन्छ: SA माथि उठ्छ र IPv6 ESP कोडमा पुग्नुअघि अस्वीकार हुन्छ। दुवै प्रिफिक्स लेख्दा SA तिनलाई बोक्न योग्य बन्छ, र start_action = trap ले पहिलो मिल्ने प्याकेटमा यसलाई माथि उठाउँछ।

WireGuard सँग एउटै सूची छ जसले दुई काम गर्छ। साथी ब्लकमा AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 पठाउँदा जडान गरिएको बाटो पनि हो र प्राप्त गर्दा लगाइने फिल्टर पनि: जसको भित्री स्रोत त्यो साथीको सूचीबाहिर पर्छ त्यस्तो डिक्रिप्ट भएको प्याकेट चुपचाप फ्याँकिन्छ। wg-quick ले प्रत्येक प्रविष्टिका लागि बाटो थप्छ, त्यसैले तलको साथी ब्लकलाई अलग ip -6 route आदेश चाहिँदैन।

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

दुवै सूची ऐनाजस्तै हुनुपर्छ: साइट B ले साइट A को प्रिफिक्सलाई टाढाको सेलक्टर मानी स्वीकार्छ र यसलाई फर्काएर रुट गर्छ, र टनेल तब मात्र चल्छ जब दुवै दिशा सहमत हुन्छन्। असममित सूचीले सबैभन्दा बढी समय खाने लक्षण दिन्छ — स्वस्थ ह्यान्डसेक, एकापट्टि चल्ने काउन्टर, र A बाट B सम्म सफल ping जबकि B बाट केही पनि A सम्म पुग्दैन।

फर्वार्डिङ, रुट र फिर्ती प्रिफिक्स

Linux ले तपाईंले नभनेसम्म IPv6 फर्वार्ड गर्दैन, र सेटिङ इन्टरफेसको होइन namespace को हिसाबले हुन्छ:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

दोस्रो पङ्क्ति त्यही हो जुन रुट आधारित डिजाइनमा मानिसहरू बिर्सन्छन्। नीति आधारित IPsec ले प्रिफिक्ससँग मिल्ने XFRM नीति स्थापना गर्छ, तर vti6 वा WireGuard भएको रुट आधारित सेटअपलाई त्यो यन्त्रतर्फ देखाउने वास्तविक IPv6 बाटो चाहिन्छ। sysctl लाई /etc/sysctl.d/ मुनि दिगो राख्नुहोस्; नत्र पुनः बुटले फर्वार्डिङलाई चुपचाप बन्द गर्छ।

फर्वार्डिङको एउटा साइड इफेक्ट छ जुन जान्न योग्य छ: कर्नेलले तब राउटर घोषणाहरूलाई बेवास्ता गर्छ जबसम्म net.ipv6.conf.<wan>.accept_ra 2 हुँदैन, त्यसैले जसको WAN ठेगाना SLAAC बाट आउँछ त्यस्तो गेटवेले फर्वार्डिङ सक्रिय गर्ने क्षणमै आफ्नो पूर्वनिर्धारित बाटो गुमाउन सक्छ। उही फाइलमा त्यो इन्टरफेसमा accept_ra = 2 सेट गर्नुहोस् र बाटो बाँच्छ। साइट B को कोरले पनि टनेल गेटवेबाट 2001:db8:aa::/48 सिक्नुपर्छ, स्थिर बाटो वा टनेलमाथिको रुटिङ प्रोटोकलद्वारा, नत्र जवाफ B को आफ्नै सञ्जालभित्र मर्छ।

टुटाइको स्थान पहिचान गर्ने चार चरणको जाँच

यही क्रममा काम गर्नुहोस् र पहिलो असफल चरणमा रोक्नुहोस्, किनकि हरेक अर्को चरण अघिल्लाहरूमा निर्भर छ।

  1. सेलक्टर: swanctl --list-sas ले child SA मा IPv6 प्रिफिक्सको जोडी देखाउनुपर्छ, वा wg show wg0 allowed-ips ले टाढाको प्रिफिक्स ताजा latest-handshakes सहित।
  2. कर्नेल रुट: ip -6 route get 2001:db8:bb::10 ले टनेल यन्त्रसँग जवाफ दिनुपर्छ, WAN इन्टरफेससँग होइन।
  3. भित्री क्याप्चर: tcpdump -ni wg0 ip6 वास्तविक LAN होस्टबीच ping गर्दा। बाहिर जाने तर कुनै फर्केर नआउने प्याकेटले B को बाटो वा फायरवालतर्फ सङ्केत गर्छ; पटक्कै प्याकेट नहुनुले चरण 1 वा 2 तर्फ फर्काउँछ।
  4. गन्तव्य: B होस्टमा ss -6 -ltn ले सेवा IPv6 मा सुनिरहेको पुष्टि गर्छ, र स्थानीय फायरवाल काउन्टरले प्याकेट स्वीकार भयो वा फ्याँकियो देखाउँछ।

MTU त्यही चरणमा पर्छ। IPv6 राउटरहरू खण्डीकरण गर्दैनन्, त्यसैले अत्यधिक ठूलो प्याकेट फ्याँकिन्छ र Packet Too Big पठाउनेकहाँ फर्कन्छ। यदि ह्यान्डसेक र साना ping चल्छन् तर फाइल स्थानान्तरण अड्किन्छ भने पेलोड घटाउनुहोस् जबसम्म त्यो पार हुँदैन: ping -6 -s 1400 -c 3 2001:db8:bb::10। WireGuard इन्टरफेसको पूर्वनिर्धारित MTU 1420 बाइट छ र IPv4 माथिको IPsec ले अझ बढी काट्छ, त्यसैले भित्री MTU सेट गर्नु ICMPv6 फ्याँक्ने फायरवालबाट बाटोको MTU पत्ता लाग्ने आशा भन्दा राम्रो हो।

फायरवाल समस्याजस्तो देखिने असफलताका ढाँचाहरू

सबैभन्दा सामान्य त फायरवाल नै होइन: सेवा :: को सट्टा 0.0.0.0 मा बाँधिन्छ, AAAA रेकर्ड अवस्थित छ, र ग्राहकले IPv6 मा छिटो अस्वीकार पाउँछ जसलाई दोहोरो स्ट्याक ब्राउजरले IPv4 मा फर्किएर लुकाउँछ। यदि केवल केही अनुप्रयोग असफल हुन्छन् भने नियमसमूह छुनुअघि सुन्ने परिवार जाँच्नुहोस्।

दोस्रो ICMPv6 फिल्टरिङ हो। Neighbor Discovery र Packet Too Big सामान्य सञ्चालनको भाग हुन्, निदानको होइन, र सबै ICMPv6 फ्याँक्ने नीतिले जोडिने, प्रमाणित हुने र त्यसपछि सानो प्याकेटभन्दा ठूलो जे पनि भएमा अड्किने टनेल बनाउँछ। बाटो निर्भर हुने प्रकारहरूलाई अनुमति दिनुहोस् र काउन्टरहरू खुला राख्नुहोस् ताकि फ्याँकिएको देखियोस्।

तेस्रो त्यो प्रिफिक्स हो जो टनेलमा थपिन्छ तर जुन साइटको स्वामित्वमा छ त्यसको ठेगाना योजनामा कहिल्यै थपिँदैन, त्यसैले कुनै राउटरले यसको घोषणा गर्दैन र कुनै होस्टले यसबाट जवाफ दिन सक्दैन। एउटा प्रिफिक्स र एउटा होस्ट जोडीबाट सुरु गर्नुहोस्, दुवै दिशा चार चरणले प्रमाणित गर्नुहोस्, त्यसपछि बाँकी थप्नुहोस्; बिग्रिएको प्रिफिक्स पुनःडिजाइनको सट्टा कन्फिगरेसनमा एक पङ्क्ति रहन्छ। खुला राख्न लायक एकमात्र आधिकारिक सन्दर्भ RFC 8200 हो, जसले टनेलले बोक्ने हेडर परिभाषित गर्छ।

सम्बन्धित लेखहरू