दोन साइट्समध्ये विद्यमान 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 आहे, जो बोगदा वाहून नेणारे हेडर परिभाषित करतो।

संबंधित लेख