VPN र वेबका लागि एउटै सार्वजनिक होस्ट: भूमिका कसरी बाँड्ने

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

अब आउने कुरा निर्णय प्रक्रिया हो, निर्माण पाना होइन। हरेक पाइलाले भर्खरै थपिएको भूमिका साँच्चै अलग छ भनी प्रमाणित गर्ने जाँचमा टुंगिन्छ।

पोर्टभन्दा पहिले ठेगानाको मालिक छान्नुहोस्

टनेलको अन्त्य बिन्दु र वेब सर्भरले एउटै कर्नेल साझा गर्न सक्छन्; एउटै समयमा एउटै ठेगाना, पोर्ट र प्रोटोकल साझा गर्नु नै असफल हुने कुरा हो. WireGuard सामान्यतया UDP 51820 लिन्छ, OpenVPN UDP 1194 वा TCP 443 लिन्छ, र वेब सर्भरले TCP 443 लिन्छ। दुखाउने जोडी HTTPS को छेउमा TCP 443 मा OpenVPN हो, किनकि दुवैले एउटै सकेट चाहन्छन् र कर्नेलले त्यो पहिले बाइन्ड गर्नेलाई दिन्छ। अगाडिको डिमल्टिप्लेक्सरले मात्र, जस्तै sslh वा TLS बुझ्ने प्रोक्सीले, तिनीहरूलाई त्यो पोर्ट साझा गर्न दिन्छ, र त्यसले विफलता फायरवल समस्याजस्तै देखिने घटक थप्छ।

केही बदल्नुअघि मालिकहरूलाई हेर्नुहोस्: ss -lntup सुनिरहेको हरेक सकेटको स्थानीय ठेगाना, पोर्ट र प्रक्रिया छाप्छ। देखाउने दुई लाइन 0.0.0.0:443 भन्नुको अर्थ दोस्रो सेवा कहिल्यै बाइन्ड भएन, त्यसको init स्क्रिप्ट जतिसुकै खुसी भए पनि। ब्रिजिङले पनि मालिक सार्छ। जब eth0 जोडिन्छ br0, IP br0 मा जान्छ र eth0 भनी नाम लिने हरेक फायरवल नियम मिल्न छोड्छ, त्यसैले सेवाहरू ब्रिजमा बाइन्ड गर्नुहोस् र ip -br addr बाट पुष्टि गर्नुहोस्।

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

दुई LAN बीच रुट गर्नुहोस् वा एउटा पक्ष NAT गर्नुहोस्

एकअर्कालाई नदेख्ने दुई LAN मध्ये हरेकले सार्वजनिक होस्टलाई कल गर्न सक्छ, जसले त्यसपछि टनेलहरूबीच फर्वार्ड गर्छ। त्यो रुटेड डिजाइनलाई तीन कुरा चाहिन्छ: फर्वार्डिङ खुला, हरेक टाढाको प्रिफिक्सतिर रुट, र ट्रान्जिट जान दिने फर्वार्डिङ नीति। sysctl -w net.ipv4.ip_forward=1 पहिलो समेट्छ, ip route add 10.20.0.0/24 dev wg1 दोस्रो, र nftables को लाइन जस्तै nft add rule inet filter forward iifname "wg0" oifname "wg1" accept तेस्रो।

स्रोत NAT थप्न सजिलो र डिबग गर्न गाह्रो छ। मास्करेडिङले क्लाइन्टको ठेगाना पुनः लेख्छ, त्यसैले टाढाको पक्षले वास्तविक होस्ट नभई हब देख्छ, र त्यसका पहुँच नियम र लगहरू श्रेयका लागि उपयोगी रहँदैनन्। दुवै नेटवर्क तपाईंका भए रुट गर्नुहोस्। एउटा पक्ष तेस्रो पक्षको भए र त्यसले फिर्ती रुट थप्ने छैन भने NAT यही हप्ता जाने विकल्प हो। जे भए पनि ठेगाना योजना लेख्नुहोस्, किनकि दुई ओभरल्यापिङ /24 लाई कुनै पनि कन्फिगरेसनले रुट गर्न सक्दैन।

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

दुई भूमिका रोकिएको बेला विभाजन जाँच्नुहोस्

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

तीन कमाण्डले त्यो जाँच ठोस बनाउँछन्। curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ बाह्य DNS बिना स्थानीय श्रोताले जवाफ दिन्छ भनी प्रमाणित गर्छ, wg show क्लाइन्टमा ह्यान्डसेक पूरा भयो भनी प्रमाणित गर्छ, र tcpdump -ni any port 51820 हबमा रुटिङ समस्यालाई कुञ्जी समस्याबाट अलग गर्छ। क्याप्चरमा कहिल्यै नदेखिने ह्यान्डसेक होस्टअघि नै मर्यो: प्रदायकको फायरवल, गलत सार्वजनिक ठेगाना वा बाटोमा NAT नियम।

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

भूमिका घटाउँदा नियम समूह पढ्नयोग्य राख्नुहोस्। nft list ruleset साँच्चै चाहिने हरेक दिशाका लागि एउटा स्वीकृति नियम देखाउनुपर्छ, र सबै स्वीकार गर्ने फर्वार्ड श्रृंखला विभाजन होइन, त्यो चलिरहेको डेमो हो।

IPv6 मात्र पहुँच लाइन र IPv4 सेवाहरू

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

हरेक परिवारलाई अलग-अलग जाँच्नुहोस् curl -4 र curl -6 ले, किनकि एउटा सफल अनुरोधले तपाईंले नजाँचेको बाटोबारे केही भन्दैन। पोर्टको स्वामित्व परिवारहरूबीच बदलिँदैन, तर श्रोता बदलिन्छ: ss -lntup ले IPv4 र IPv6 सकेटहरू अलग लाइनमा सूचीबद्ध गर्छ, र 0.0.0.0:443 ले समेट्दैन [::]:443 लाई, प्रक्रियाले dual-stack सकेट नमागेसम्म।

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