दो साइटें, एक सबनेट, एक WireGuard हब: इसे काम कराएँ

दोनों साइटें एक ही LAN रेंज का उपयोग करती हैं, और ओवरलैप वह नहीं है जो असल में डिज़ाइन को तोड़ता है। हब को केवल गंतव्य पते से साइट चुननी होती है, और दो समान गंतव्य उसे चुनने के लिए कुछ नहीं देते। किसी टनल को संतुष्ट करने के लिए चल रहे दफ़्तर को फिर से क्रमांकित करना आम तौर पर हर प्रकाशित सेवा को टनल द्वारा ले जाने योग्य अलग पता देने से बुरा सौदा है। नीचे का डिज़ाइन प्रत्येक साइट से एक HTTPS सेवा प्रकाशित करता है और कुछ नहीं।

ओवरलैप असली समस्या क्यों नहीं है

WireGuard गंतव्य के अनुसार आगे भेजता है: किसी peer के AllowedIPs तय करते हैं कि कौन सा peer पैकेट पाएगा। दो peer एक साथ 10.10.7.0/24 की घोषणा नहीं कर सकते, जब तक उनमें से एक हर खोज न जीते। यह peer तालिका का गुण है, टनल का नहीं, इसलिए यहाँ समाधान पता योजना है, रूटिंग की तरकीब नहीं।

योजना यह है कि LAN की घोषणा बिल्कुल बंद कर दी जाए। इसके बजाय प्रत्येक सेवा के लिए एक alias घोषित करें, प्रत्येक साइट के लिए एक पता, और प्रत्येक साइट का गेटवे उस alias को अपने वास्तविक एप्लिकेशन में अनुवाद करे।

उपयोगकर्ता दो अनोखे पते रूट करता है, अस्पष्ट प्रीफ़िक्स कभी नहीं देखता, और दोनों दफ़्तरों में कुछ नहीं बदलता। यह सीमा भी ईमानदारी से बताता है: आप प्रत्येक साइट से एक HTTPS सेवा प्रकाशित कर रहे हैं, दो नेटवर्क मिला नहीं रहे। आगे जो नियम आते हैं वे छोटे रहते हैं क्योंकि कथन सँकरा है। व्यापक कथन को व्यापक नियम चाहिए, और इसी तरह ये डिज़ाइन जटिल होते हैं।

प्रत्येक साइट को ऐसा alias दें जिसे उपयोगकर्ता रूट कर सके

ऐसी रेंज से पते चुनें जो उपयोगकर्ता की मशीन, हब या दोनों में से किसी भी LAN पर किसी चीज़ से टकराते न हों। यहाँ हब 10.66.0.1 है, उपयोगकर्ता 10.66.0.10, गेटवे 10.66.0.21 और 10.66.0.22, और दो alias 10.77.1.20 और 10.77.2.20 हैं। हब प्रत्येक alias को उस peer के माध्यम से प्रकाशित करता है जो उसका मालिक है, इसलिए एक alias के लिए भेजा गया बाहर जाने वाला पैकेट केवल मेल खाती साइट से ही निकल सकता है:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

उपयोगकर्ता पक्ष को केवल दो alias चाहिए, जो क्लाइंट कॉन्फ़िगरेशन को दोनों LAN प्रीफ़िक्स से मुक्त रखता है। उस कॉन्फ़िगरेशन में कुछ भी किसी भी वास्तविक LAN का ज़िक्र नहीं करता:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

प्रत्येक गेटवे हब और उपयोगकर्ता के स्रोत की घोषणा करता है, और कुछ नहीं, इसलिए एक साइट कभी दूसरी साइट का LAN नहीं जानती। Keepalive साइट के अपलिंक पर NAT मैपिंग बनाए रखता है; यह ट्रैफ़िक को अधिकृत नहीं करता, और फ़ायरवॉल अब भी तय करता है कि क्या स्वीकार होगा। एक गेटवे का कॉन्फ़िगरेशन दूसरे में कॉपी करना ठीक है जब तक निजी कुंजी, इंटरफ़ेस पता और alias सभी बदलें।

हब को अपने दो peer के बीच क्या अनुमति देनी चाहिए

हब अपने ही दो peer के बीच पैकेट आगे भेजता है, जो forward श्रृंखला का निर्णय है, इनपुट निर्णय नहीं। प्लेटफ़ॉर्म की सामान्य विधि से IPv4 फ़ॉरवर्डिंग सक्षम करें, फिर ठीक उन्हीं जोड़ों को अनुमति दें जिनकी डिज़ाइन को ज़रूरत है।

नीचे का नियम उपयोगकर्ता को एक alias और एक पोर्ट की अनुमति देता है, और कनेक्शन ट्रैकिंग के माध्यम से वापसी ट्रैफ़िक की अनुमति देता है। यह forward पथ में बाकी सब गिरा देता है, और यही बात है:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

दो बातें बताने योग्य हैं क्योंकि वे चुपचाप विफलताएँ पैदा करती हैं। एक बेस चेन में accept दूसरी में drop को ओवरराइड नहीं करता, इसलिए इसे मौजूदा नीति के साथ मिलाएँ, उसके बगल में लोड न करें। और स्रोत पता व्यक्ति नहीं, डिवाइस की पहचान करता है; एप्लिकेशन प्रमाणीकरण को नेटवर्क स्वीकृति से अलग रखें।

जहाँ alias असली पता बनता है

साइट A को 10.77.1.20 के लिए अनुरोध मिलता है, गंतव्य को वास्तविक एप्लिकेशन में फिर से लिखता है, और स्रोत को अपने LAN पते में फिर से लिखता है ताकि उत्तर टनल तक मार्ग के बिना लौट सके। दोनों अनुवाद एक ही जगह करने से बाकी नेटवर्क alias से अनजान रहता है। नीचे के नियम पूरी क्रियाविधि हैं:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

फिर साइट A की forward नीति को टनल इंटरफ़ेस से LAN इंटरफ़ेस तक अनुवादित प्रवाह स्वीकार करना होगा, साथ ही वापसी दिशा भी। forward हुक गंतव्य को गंतव्य अनुवाद के बाद और स्रोत पुनर्लेखन से पहले देखता है, इसलिए नियम वास्तविक एप्लिकेशन का पता बताता है। जब भी कोई नियम किसी चीज़ से मेल न खाता लगे, वे दोनों हुक इसी क्रम में पढ़ें। alias के विरुद्ध लिखा forward नियम कभी मेल नहीं खा सकता, क्योंकि उस हुक पर alias अब मौजूद नहीं है।

साइट B इसे अपने alias और अपनी कुंजी के साथ दोहराती है। इसे साइट A की निजी कुंजी दोबारा नहीं उपयोग करनी चाहिए, क्योंकि दो peer का एक पहचान साझा करना कॉन्फ़िगरेशन त्रुटि है जिसे देखना कठिन और फ़ाइल कॉपी करके बनाना आसान है। दोनों गेटवे दस्तावेज़ों को उन मानों के अलावा समान रखें जिन्हें भिन्न होना चाहिए, ताकि समीक्षा में अंतर उभरे। कॉपी की गई फ़ाइल उस दोष का सामान्य स्रोत है।

स्रोत पुनर्लेखन की एक कीमत है। एप्लिकेशन गेटवे को अपना क्लाइंट मानता है, इसलिए उसके लॉग अब नहीं दिखाते कि कौन उपयोगकर्ता जुड़ा। गेटवे का ऑडिट ट्रेल रखें, और अनुवाद द्वारा हटाई गई नेटवर्क पहचान की भरपाई के लिए एप्लिकेशन लॉगिन कमज़ोर न करें।

कैसे साबित करें कि दोनों प्रकाशित नाम उत्तर देते हैं

प्रत्येक alias को DNS नाम दें और उस नाम के लिए एप्लिकेशन और प्रमाणपत्र कॉन्फ़िगर करें, क्योंकि अनुवाद रीडायरेक्ट या एम्बेडेड निरपेक्ष URL फिर से नहीं लिखता। प्रत्येक साइट के लिए एक नाम रखें ताकि प्रमाणपत्र की असंगति को कभी रूटिंग खराबी न समझा जाए।

असली क्लाइंट से परीक्षण करें, पुष्टि करें कि किस साइट ने उत्तर दिया, और अनधिकृत पोर्ट भी जाँचें। किसी भी NAT परिवर्तन के बाद नए कनेक्शन उपयोग करें, क्योंकि स्थापित स्थिति पुरानी मैपिंग रखती है:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

पहले कमांड में खाली या अप्रत्याशित alias का अर्थ है कि किसी भी फ़ायरवॉल नियम के मायने रखने से पहले peer चयन गलत है। यदि alias सही है और नाम फिर भी विफल होता है, तो समस्या DNS और प्रमाणपत्रों में चली गई है। जब दोनों नाम उत्तर देते हैं और तीसरा पोर्ट बंद रहता है, तो डिज़ाइन वही करता है जो वह दावा करता है: दो संकीर्ण रूप से प्रकाशित सेवाएँ, दो मिली हुई LAN नहीं।