नेस्टेड WireGuard: बीचको हपले आफ्नै पोर्टमा जवाफ दिन सक्दैन
बीचको हपले सबै कुरा एउटै टनेलमा पठाउँदा उसको आगमन सेवाका जवाफहरू गलत बाटोबाट बाहिरिन्छन्। इन्टरफेसमा स्रोत-पोर्ट नियमले यसलाई सुधार्छ।
तीन WireGuard हपहरू सार्वजनिक ठेगाना नभएको नेटवर्कसम्म पुग्छन्, अनि बीचको मेसिनले सुन्नुपर्ने पोर्टमा जवाफ दिन छाड्छ। अगाडिको टनेल अझै काम गर्छ, टाढाको होस्ट अझै प्रतिक्रिया दिन्छ, र बाहिरबाट चुप लागेको बीचको सर्भर आफैं मात्र हो। यो संयोजन भ्रमित पार्ने कुरा यो आफैंले गरेको हुनाले नै हो: बीचको हप आफ्नै राउटिङ तालिका मानिरहेको छ, र तालिकाले उसका जवाफहरू गलत दिशामा पठाउँछ।
बीचको बाकससँग कुरा नगरेसम्म काम गर्ने शृंखला
एउटा उदाहरणीय शृंखला लिनुहोस्: क्लाइन्ट A UDP 500 मा सर्भर B सम्म पुग्छ, र B UDP 500 मा सर्भर C तिर अगाडि बढ्छ। C ले आफ्नो एकमात्र साथीको ठेगानाबाट मात्र ट्राफिक स्वीकार गर्छ, जसले यसलाई पात बनाउँछ र यसको व्यवहार सरल राख्छ। B पात होइन, र यो खराबीमा रोचक सबै कुरा त्यहीँ हुन्छ।
यो भिन्नता महत्त्वपूर्ण छ किनकि पात र बीचको भूमिकाहरू विपरीत दिशामा तान्छन्। पातले कुनै परिणाम बिना सबै कुरा एउटै टनेलमा पठाउन सक्छ, किनकि त्यसमा अरू केही निर्भर छैन। बीचको हप एकै समयमा क्लाइन्टहरूका लागि अन्तिम बिन्दु र टाढाको पक्षतिर क्लाइन्ट हो, र ती दुई कामले फरक राउटिङ चाहन्छन्।
जवाफ किन टनेलबाट बाहिरिन्छ
B मा, C तिर फर्केको इन्टरफेसले मिल्ने पूर्वनिर्धारित मार्गसँगै AllowedIPs = 0.0.0.0/0 बोक्छ। त्यसैले B ले सिर्जना गर्ने प्रत्येक प्याकेट त्यो टनेलमा जान्छ, जबसम्म अझ विशिष्ट कुराले प्राथमिकता पाउँदैन।
A बाट B लाई सम्बोधन गरिएको प्याकेट आउँछ र स्वीकारिन्छ, किनकि B गन्तव्य हो र स्थानीय डेलिभरी पहिले हुन्छ। जवाफ A को सार्वजनिक ठेगानातिर लक्षित पूरै नयाँ स्थानीय रूपमा सिर्जना गरिएको प्याकेट हो, र त्यो गन्तव्य टनेलभित्रको पूर्वनिर्धारित मार्गसँग मिल्छ। C ले यो प्राप्त गर्छ, त्यो ठेगानाको मालिक होइन, र यसलाई फ्याँक्छ।
लक्षण फायरवाल समस्या वा कुञ्जी नमिलेको जस्तो पढिन्छ, र यहाँ दुवै सत्य होइनन्। C तिरको टनेलमा गरिएको क्याप्चरले जवाफहरू गलत दिशामा गइरहेको देखाउँछ। त्यो एउटा अवलोकनले जति कन्फिगरेसन पढे पनि भन्दा बढी समय बचाउँछ, त्यसैले कुञ्जी बदल्न थाल्नुअघि त्यो लेख्नुहोस्। क्याप्चर नदेखेको जो कोहीले टनेल नै बिग्रेको छ भन्ने ठान्नेछ।
साँघुरो मर्मत: स्रोत पोर्टसँग मिल्ने नीति नियमहरू
B को सुन्ने सकेटबाट जवाफहरू स्रोत पोर्ट 500 सहित बाहिरिन्छन्। नीति नियमले त्यससँग मिल्न सक्छ र ती प्याकेटहरूलाई सामान्य तालिकामा फर्काउन सक्छ:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101नीति नियमहरू प्राथमिकताको क्रममा हेरिन्छन्, र मुख्य तालिका 32766 मा छ, त्यसैले 100 मा रहेको नियम टनेलको पूर्वनिर्धारित मार्गले बोल्नुअघि सोधिन्छ। बाहिरबाट पुग्न सकिने रहनुपर्ने प्रत्येक पोर्टका लागि एउटा प्रविष्टि थप्नुहोस् र त्यसभन्दा बढी केही होइन, ताकि अगाडि पठाइने ट्राफिकले जुन टनेलका लागि बनाइएको थियो त्यही प्रयोग गरिरहोस्।
यो उपायको सीमा जान्नुहोस्। sport चयनकर्ता स्थानीय रूपमा सिर्जना गरिएका प्याकेटसँग मिल्छ, जसले जवाफको अवस्था ठ्याक्कै समेट्छ र B ले अरूका लागि मात्र अगाडि पठाउने ट्राफिक जानाजान समेट्दैन। B पछाडि होस्ट गरिएको सेवालाई अझै आफ्नै जवाफ चाहिन्छ, र विपरीत हुनुको नाटक गर्दा पहिलो सेवाका लागि काम गर्ने र दोस्रोका लागि असफल हुने सुधार आउँछ।
नियमलाई मालिक दिनुहोस्
प्रम्प्टमा टाइप गरिएको नियम अर्को पटक इन्टरफेस पुनः निर्माण हुँदा हराउँछ। WireGuard सेटअपमा यसलाई इन्टरफेस सिर्जना र हटाइने ठाउँमा राख्नुहोस्:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100यदि इन्टरफेसको मालिक NetworkManager, वितरण हुक वा कन्टेनर प्रवेश बिन्दु हो भने, त्यो जोडी हातले सम्पादन गरिएको फाइलको नभई त्यही मालिकको हो। पुनः जडानपछि प्रभावकारी नियमहरू जाँच्नुहोस्, पहिलो सुरुवातपछि मात्र होइन, किनकि पहिलो सुरुवात सधैं काम गर्ने अवस्था हो।
विकल्पहरूको इमानदार तुलना गर्नुहोस्
स्रोत-पोर्ट नियम चार बाटोमध्ये एक हो, र तीमध्ये सबैभन्दा साँघुरो। टनेल नीतिलाई पटक्कै नछुने यसको फाइदा हो, र त्यसैले यो पछिका परिवर्तनहरूमा टिक्ने गर्छ। साँघुरा सुधारहरू लागू हुन छाड्दा ठूलो स्वरमा असफल हुन्छन्, जबकि फराकिलो अपवाद त्यसको कारण हराएको धेरै पछिसम्म पनि चुपचाप काम गरिरहन्छ। दुई वर्षपछि जब बाकसको मालिक अरू कोही हुन्छ, त्यो भिन्नता सजावटभन्दा बढी महत्त्वपूर्ण हुन्छ।
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
छनोट गरेपछि दुवै छेउबाट प्रमाणित गर्नुहोस्। A बाट B को पोर्टमा जडान सुरु गर्नुहोस् र केही समय व्यस्त राख्नुहोस्। B मा, कर्नेललाई ip route get <address-of-A> sport 500 जस्तो कुराले जवाफ-मार्ग न्यायोचित ठहराउन लगाउनुहोस्, र यसले टनेल नभई WAN इन्टरफेस भनेको पुष्टि गर्नुहोस्। त्यसपछि, C पछाडिको कुनै कुरा अझै शृंखलाबाट जवाफ दिइरहेको जाँच्नुहोस्, जसले अपवाद बाइपास बन्नुको सट्टा साँघुरै रहेको प्रमाणित गर्छ। अन्तमा, पोर्टहरू डिजाइन नोटमा लेख्नुहोस्, नत्र अर्को अपरेटरले यो अर्को सेवामा फेरि भेट्टाउनेछ।