WireGuard मार्फत एउटा एप: बाइन्डिङ राउटिङ होइन

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

यो कार्यविधिका दुई आधा भाग छन्: टनेलको ट्राफिकले मात्र प्रयोग गर्नुपर्ने राउटिङ तालिका, र मिल्ने स्रोत त्यहाँ पठाउने नियम।

बाइन्डिङले स्रोत ठेगाना तोक्छ, त्यसभन्दा बढी होइन

नीति नियमहरूलाई त्यो खोजी अन्यत्र मोड्ने अवसर मिलेपछि लिनक्सले राउटिङ तालिकामा गन्तव्य खोजेर बाहिर जाने इन्टरफेस छान्छ। नियमहरूले स्रोत ठेगाना, फायरवाल मार्क, आउने इन्टरफेस, UID वा पोर्टसम्मका आधारमा छान्न सक्छन्; हरेक सबै ट्राफिक नभई यो ट्राफिक भन्ने अर्को तरिका हो। VPN क्लाइन्टको कन्फिगरेसनले टनेलका रुट भएको तालिका छान्छ; नियमले कुन ट्राफिकलाई त्यसको सल्लाह लिन अनुमति छ भनी छान्छ। बाइन्डिङ मात्रले दुवैमध्ये केही दिँदैन।

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

टनेललाई उसको आफ्नै तालिका दिनुहोस्

wg-quick ले प्रोफाइलले भनेको ठाउँमा रुट स्थापना गर्छ। [Interface] मुनि Table = 40 थप्दा तिनीहरू मुख्य तालिकाको सट्टा तालिका 40 मा जान्छन्। इन्टरफेस माथि उठाउनुहोस् र तिनीहरू पुगेको पुष्टि गर्नुहोस्: ip -4 route ls table 40 ले टनेलका रुट देखाउनुपर्छ, र ip -4 route get 10.66.127.142 ले कर्नेलले अहिले तीमध्ये एउटा कसरी समाधान गर्छ देखाउँछ। रुट तिनीहरूकै तालिकामा हुँदा मुख्य तालिका बाँकी सबैका लागि काम गरिरहन्छ।

फराकिलो प्रिफिक्स मिलाउनुको सट्टा IPv6 का लागि पनि त्यही गर्नुहोस्। ip -6 rule add from fd00::2/128 lookup 40 एउटा ठेगाना पिन गर्छ; fc00::/8 होस्टका अन्य इन्टरफेससँग ठोक्किन सक्छ र उद्देश्यभन्दा बढी मिल्ने नियम बनाउन सक्छ।

स्रोत नियम थप्नुहोस् र काउन्टर हेर्नुहोस्

त्यसपछि दुई आधा जोड्नुहोस्: ip -4 rule add from 10.66.127.142/32 lookup 40, त्यही ठेगाना WireGuard इन्टरफेसमा जोडिएको राखेर। दुवै नियम PostUp मा राख्नुहोस्, पुनः जडान हुँदा ती पुनर्स्थापित होऊन्। सेटिङले नभई वास्तविक अनुरोधले जाँच्नुहोस्: ip route get 1.1.1.1 from 10.66.127.142 ले टनेल उपकरणको नाम बताउनुपर्छ, र curl --interface wg0 ifconfig.me ले घरको ठेगानाको सट्टा टनेलको ठेगाना रिपोर्ट गर्नुपर्छ।

तैपनि असफल भए ip -s rule पढ्नुहोस्। अस्तित्वमा भए पनि कहिल्यै नमिलेको नियमले शून्य काउन्टर देखाउँछ, र यसले गलत नियमलाई नियम नै नभएकोबाट अलग गर्छ। त्यो एउटा आदेशले एपले आफ्नो इन्टरफेस सेटिङ बेवास्ता गर्यो कि भन्ने धेरै अनुमान बचाउँछ।

उल्टो अवस्था: SSH लाई टनेलबाहिर राख्नुहोस्

उल्टो समस्या पनि उत्तिकै सामान्य छ: wg-quick सँग पूर्वनिर्धारित रुट छ र सर्भरको SSH सत्र बीचैमा मर्छ। यसका नियम कम प्राथमिकता नम्बरमा बस्छन्, त्यसैले अपवाद तिनीभन्दा अघि मूल्याङ्कन गर्नुपर्छ। ip rule add dport 22 ipproto tcp table main priority 123 ले हालैको iproute2 मा त्यो गर्छ; जहाँ चयनकर्ता उपलब्ध छैन त्यहाँ nftables मा प्रवाह चिन्ह लगाउनुहोस् र सट्टा चिन्ह मिलाउनुहोस्।

फर्किने बाटो पनि जाँच्नुहोस्। स्थापित भएर पछि चुप लाग्ने SSH सत्रमा सामान्यतया असममित राउटिङ हुन्छ: एउटा दिशा टनेलबाट र अर्को भौतिक इन्टरफेसबाट बाहिर जान्छ। सर्भर ठेगानाका लागि ip route get ले जवाफ कुन दिशातिर जान्छ भन्ने बताउँछ।

तालिका नम्बर, स्रोत नियम र अपवाद प्रोफाइलमै लेख्नुहोस्। तीनवटै एउटै ढाँचाका हुन् र सँगै सम्पादन गरिनेछन्।