एउटा परीक्षण LAN लाई यसको आफ्नै WireGuard निकास कसरी दिने

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

निकास कहाँ बस्छ भनेर निर्णय गर्नुहोस्

पहिलो प्रश्न: के यो होस्ट अरू कुनै कुराका लागि पनि अगाडि पठाउँछ? समर्पित प्रयोगशाला गेटवेले डिफल्ट रूपमा सबै खारेज गर्ने फर्वार्डिङ नीतिसँग बाँच्न सक्छ। उत्पादनको जिम्मेवारी भएको राउटरले त्यसो गर्न सक्दैन, र व्यवस्थापित फायरवालमाथि प्रतिस्पर्धी नियमसमूह राख्नु भनेको अवरोध तालिका बनाउने ठ्याक्कै त्यही तरिका हो। दोस्रो: रिबुटहरूभरि तपाईं दुई नीति वस्तु र तिनको क्रम राख्न सक्नुहुन्छ? तेस्रो: तपाईंको साथीले तपाईंको सुरुङ स्रोत ठेगाना अधिकृत गर्छ र इन्टरनेट निकास दिन्छ? केवल निजी सञ्जाल मात्र देखाउने साथी अर्कै उत्पादन हो, र कुनै स्थानीय राउटिङ परिवर्तनले त्यो सुधार्दैन। कुनै जवाफ होइन भए, निकासलाई बरु नामस्थानमा वा एकैचोटि प्रयोग हुने भर्चुअल मेसिनमा राख्नुहोस्।

नामस्थान वा VM ले स्मृति खर्च गर्छ र तपाईंलाई सफा विस्फोट त्रिज्या दिन्छ। नीति-आधारित राउटिङले दुई नियम खर्च गर्छ र डिबग गर्न एउटै बाकस छोड्छ।

तपाईंको स्रोत अधिकृत गर्ने निकास छान्नुहोस्

यो प्रयोगशालामा अधिकांश असफलता एउटा पनि फायरवाल नियम नबनेकै अवस्थामा हुन्छ। निकास अपरेटरले अनुवादपछि तपाईंका प्याकेटले बोकेको स्रोत ठेगाना स्वीकार गर्नुपर्छ, र यो डिजाइनमा त्यो सुरुङ ठेगाना हो, LAN प्रिफिक्स होइन। त्यसैले मास्करेडिङ सुरुदेखि नै डिजाइनको अङ्ग हो, पछिको थप होइन।

अपरेटरसँग तीन कुरा पक्का गर्नुहोस्: साथीले तपाईंको सुरुङ ठेगाना अधिकृत गर्छ, यसले आफैँमा अन्त्य नगरी IPv4 अगाडि पठाउँछ, र यसले निकास NAT लागू गर्छ। पहिलो बिना तपाईंका प्याकेट पुग्छन् र हराउँछन्। तेस्रो बिना तिनीहरू निजी स्रोतसहित बाहिर जान्छन् र अर्को हपमा मर्छन्। त्यसपछि wg-quick ले आफ्नै डिफल्ट मार्ग स्थापना गर्दैन भनी जाँच्नुहोस्, जसलाई Table = off रोक्छ; त्यो सेटिङले मार्ग सिर्जना दबाउँछ, साथीको AllowedIPs जाँच वा त्यसको DNS व्यवस्थापन होइन।

दुई नीति वस्तुले मार्गनिर्देशन गर्छन्

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

गार्ड खोजभन्दा अघि आउँछ, पछि होइन। त्यही क्रम नै डिजाइनको सम्पूर्ण सुरक्षा विशेषता हो।

गार्ड उही चयनकर्तामाथिको दोस्रो नियम हो जसको फैसला unreachable छ। सुरुङ माथि हुँदा पनि खोज जितिरहन त्यसलाई उच्च सङ्ख्यात्मक प्राथमिकता दिनुहोस्। सुरुङ मार्ग हराएपछि खोजले केही फर्काउँदैन र गार्डले खोज रोक्छ, यसलाई मुख्य तालिकाको WAN डिफल्टसम्म खस्न दिँदैन।

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

पछाडि हट्ने खाल्डो खोल्नुअघि बन्द गर्नुहोस्

पहिले गार्ड र त्यसपछि खोज स्थापना गर्नुहोस्। उल्टो गर्दा केही सेकेन्डको झ्याल रहन्छ, जसमा परीक्षण क्लाइन्टको ट्राफिक माथिल्लो जडानसम्म पुग्न सक्छ।

फिल्टरले चित्र पूरा गर्छ। forward हुकमा परीक्षण प्रिफिक्सका लागि LAN बाट सुरुङतर्फको दिशा र स्थापित फर्किने दिशा स्वीकार गर्नुहोस्, त्यसपछि बाँकी सबै खारेज गर्नुहोस्; त्यो प्रिफिक्सको सुरुङ इन्टरफेसमा NAT postrouting मा जान्छ। फर्वार्ड चेनमा policy drop राख्नु नै हराएको मार्गलाई चुहावटको सट्टा मौनतामा बदल्छ। उल्टो मार्ग फिल्टरिङका लागि सुरुङ इन्टरफेसमा ढिलो मोड चाहिन्छ, किनकि डिक्याप्सुलेसनपछि आउने सार्वजनिक स्रोतको उत्तम उल्टो मार्ग WAN पट्टि हुन्छ। Linux ले all र प्रति-इन्टरफेस मानमध्ये उच्च लिन्छ, त्यसैले सुरुङ इन्टरफेस सेट गर्नु जताततै प्रमाणीकरण कमजोर बनाउनुसँग बराबर होइन।

असफलताको अवस्थाबाट यो प्रमाणित गर्नुहोस्

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

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