दोन साइट, एक सबनेट, एक 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 hook गंतव्य भाषांतरानंतर आणि स्रोत पुनर्लेखनापूर्वी गंतव्य पाहते, म्हणून नियम खऱ्या अनुप्रयोगाचा पत्ता नमूद करतो। जेव्हा नियम कशाशीही जुळत नाही असे वाटेल तेव्हा ते दोन hook याच क्रमाने वाचा। alias विरुद्ध लिहिलेला forward नियम कधीही जुळू शकत नाही, कारण त्या hook वर 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 नाहीत।