दुई साइट, एउटा सबनेट, एउटा 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 होइन।