ह्यान्डशेक पूरा हुन्छ, wg show हालैको स्थानान्तरणको जानकारी दिन्छ, र सर्भरको टनेल ठेगानाले पिंगको जवाफ दिन्छ। तर सर्भरको LAN मा रहेको होस्टले दिँदैन। तीनवटा सर्तहरू एकैसाथ पूरा हुनुपर्छ: क्लाइन्टले LAN प्रिफिक्स टनेलमा रुट गर्नुपर्छ, सर्भरले प्याकेट फर्वार्ड गर्नुपर्छ, र जवाफलाई फर्कने बाटो चाहिन्छ। तीनमध्ये एउटा छुट्दा लक्षण उही हुन्छ।

AllowedIPs एउटै समयमा पहुँच सूची र रुटिङ तालिका हो

क्लाइन्टमा, AllowedIPs सूचीले त्यो पियरलाई के पठाउन सकिन्छ र WireGuard ले कुन रुट स्थापना गर्छ दुवै निर्धारण गर्छ। सर्भरको टनेल ठेगाना मात्र सूचीबद्ध गर्ने पियर प्रविष्टिले एउटा होस्ट रुट स्थापना गर्छ, त्यसैले LAN का गन्तव्यहरू कहिल्यै टनेलमा पस्दैनन्। LAN प्रिफिक्स थप्नु पहिलो जाँच्नुपर्ने कुरा हो, र प्रतिलिपि गरिएको कन्फिगरेसनपछि सबैभन्दा धेरै छुट्ने परिवर्तन पनि त्यही हो। पूर्वनिर्धारित रुटसम्म फैलाइएको पियर अर्को डिजाइन हो, र त्यसले क्लाइन्टको इन्टरनेट ट्राफिक पनि सार्छ।

होस्ट रुट र LAN प्रिफिक्सलाई छुट्टाछुट्टै प्रविष्टिका रूपमा राख्नुहोस्। कार्यालयमा दुई सबनेट छन् भने दुवै सूचीमा पर्छन्, र छुटेको दोस्रो प्रिफिक्सले पूर्ण नभई छनोटजस्तो देखिने असफलता उत्पन्न गर्छ।

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

फर्वार्डिङ र अनुवाद सर्भरमै हुनुपर्छ

सर्भरलाई IP फर्वार्डिङ सक्षम, टनेलबाट आउने ट्राफिक स्वीकार गर्ने फर्वार्ड नियम, र आफ्नो LAN इन्टरफेसतर्फ अनुवाद नियम चाहिन्छ। यही अनुवादले कार्यालय नेटवर्कको हरेक होस्टलाई छुनुबिना डिजाइनलाई काम गराउँछ। त्यसपछि जवाफहरू LAN ले कहिल्यै नसुनेको ठेगानामा होइन, सर्भरमा फर्कन्छन्। त्यो बिना हरेक होस्टलाई टनेल सबनेटको रुट र त्यसलाई अनुमति दिने फायरवाल नियम चाहिन्छ, जुन अरू कसैले व्यवस्थापन गर्ने नेटवर्कमा विरलै स्वीकार्य हुन्छ।

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

हातले थपिएका नियम रिबुटमा हराउँछन्, त्यसैले सर्भर कन्फिगरेसनका hook कमाण्डद्वारा तिनलाई इन्टरफेसमा बाँध्नुहोस्। आफ्नो इन्टरफेसभन्दा लामो बाँच्ने नियम समूहले नै मेसिनले अब नरहेको टनेलका लागि ट्राफिक अनुवाद गर्न थाल्छ।

LAN सर्यो तर नियम सरेन

कार्यालय सबनेट पुनःनम्बर गर्ने राउटर प्रतिस्थापन यो असफलताको उत्कृष्ट उदाहरण हो। टनेल चालु रहन्छ, ह्यान्डशेक ताजा रहन्छ, र सर्भरपछाडि केही पनि जवाफ दिँदैन, किनभने अनुवाद नियमले अझै पुरानो ठेगाना भन्छ। इन्स्टलर स्क्रिप्टले प्रायः सर्भरको LAN ठेगाना POSTROUTING नियममा राख्छन्, र पुनःनम्बरपछि त्यो ठेगाना कुनै इन्टरफेसमा हुँदैन। त्यसपछि प्याकेटहरू जवाफ दिन नसक्ने गन्तव्यतर्फ पुनःलेखिन्छन्।

iptables -t nat -n -L POSTROUTING
ip -br addr show

दुवै आउटपुट तुलना गर्नुहोस्। इन्टरफेस सूचीमा नदेखिने अनुवाद लक्ष्य नै बग हो, र एकचोटि देखिसकेपछि त्यसलाई सुधार्नु एक लाइनको परिवर्तन हो। नियम WireGuard कन्फिगरेसनमा नभई उत्पन्न unit मा हुन सक्छ, त्यसैले सम्पादनपछि त्यो unit पुनःलोड गर्नुहोस् र अर्को बुटले तपाईंको परिवर्तन पुनःलेख्दैन भन्ने पुष्टि गर्नुहोस्।

NAT पछाडिका दुई साइटलाई भेट्ने ठाउँ चाहिन्छ

कुनै पक्षले पनि भित्र आउने जडान स्वीकार नगर्दा व्यावहारिक जवाफ सार्वजनिक ठेगाना र दुई WireGuard इन्टरफेस भएको सानो होस्ट हो। हरेक साइट बाहिरतर्फ जोडिन्छ, बीचको होस्टले हरेक पियरको LAN आफ्नो AllowedIPs, अर्थात् आफ्नो सूचीमा, सूचीबद्ध गर्छ, र फर्वार्डिङले दुई टनेलबीच प्याकेट बोक्छ। कुनै पनि साइटको फायरवालमा केही बदल्नु पर्दैन, त्यसैले यो डिजाइन सजिलै फैलिन्छ।

साइटहरूबीचको रुटिङले मूल स्रोत ठेगाना राख्छ र त्यसैले प्रति-होस्ट लगिङलाई अर्थपूर्ण राख्छ। दुई LAN ओभरल्याप हुँदा बीचको होस्टमा अनुवाद गर्न सजिलो हुन्छ, तर लगमा स्रोतको पहिचान गुमाउने मूल्यमा। छनोट गर्नुअघि कुन गुण महत्त्वपूर्ण छ निर्धारण गर्नुहोस्।

चार जाँचले तहहरू अलग गर्नुहोस्

तीन कुरा बदलेर आशा गर्नुको सट्टा हरेक तहका लागि एक जाँच गर्नुहोस्। पहिलोले हरेक पियरको ह्यान्डशेक उमेर र काउन्टर देखाउँछ। दोस्रोले क्लाइन्टले त्यो गन्तव्य साँच्चै टनेलमा रुट गर्छ कि गर्दैन देखाउँछ। तेस्रो र चौथोले अनुरोध पुग्यो कि पुगेन र पुगेपछि कुनै नीतिले त्यसलाई खसाल्यो कि खसालेन भन्छ।

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

पुगेर पनि जवाफ नल्याउने अनुरोधले जवाफको बाटो वा LAN होस्टतर्फ संकेत गर्छ। कहिल्यै नपुग्ने अनुरोधले AllowedIPs वा क्लाइन्टको रुटतर्फ संकेत गर्छ। यी दुई नतिजाका लागि फरक सुधार चाहिन्छ, र क्याप्चरले नै तिनलाई छुट्याउँछ।

सम्बन्धित लेखहरू