दो साइटों के बीच मौजूदा 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 है, जो वह हेडर परिभाषित करता है जो टनल ले जाता है।

संबंधित लेख