Pi मा hotspot ग्राहकहरू TUN VPN मार्फत घरको LAN मा पुग्दैनन्

ठेगाना पाउने तर घरको साझेदारी खोल्न नसक्ने hotspot ग्राहकहरूलाई पुल होइन, फर्कने मार्ग चाहिन्छ। TUN मार्ग, प्रिफिक्स मालिक र NAT पछ्याउनुहोस्।

स्थानीय Wi-Fi र Ethernet ग्राहकहरू Pi को hotspot मा जोडिन्छन्, यसको DHCP दायराबाट ठेगाना लिन्छन् र उजुरी बिना इन्टरनेट पृष्ठहरू लोड गर्छन्। त्यसपछि तीही ग्राहकहरू घरको LAN मा फाइल साझेदारी वा वेब इन्टरफेस खोल्दा समय सकिन्छ, जबकि Pi आफैं सुरुङमार्फत त्यो LAN मा पुग्छ। वायरलेस तहमा केही पनि बिग्रेको छैन। कम भएको कुरा राउट गरिएको सम्झौता हो: hotspot प्रिफिक्स TUN इन्टरफेसमा लग्नुपर्छ, र घरको तर्फ केही कुरालाई जवाफ त्यहाँ फर्काएर कसरी पठाउने थाहा हुनुपर्छ। एउटा प्याकेटले यात्रा पूरा गर्नुअघि दुवै आधा हुनुपर्छ।

तीन फरक काम भएका तीन जडानहरू

Linux Ethernet पुलले गन्तव्य MAC ठेगाना अनुसार फ्रेमहरू अगाडि पठाउँछ। OpenVPN TUN मोडमा IP प्याकेटहरू बोक्छ र MAC तह बिल्कुलै हुँदैन, त्यसैले स्थानीय पुल थप्दा सुरुङ कहिल्यै पोर्टको रूपमा दर्ता हुँदैन। कर्नेल TUN/TAP कागजात ले त्यो विभाजन बुझाउँछ: TAP यन्त्र Ethernet इन्टरफेसजस्तो देखिन्छ, TUN यन्त्र होइन। दुई स्थानीय पोर्टहरू पुल गरेर त्यसपछि राउट गर्ने डिजाइन इन्टरफेसका नाम जे भने पनि राउटर हो।

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

मोडेम पनि ग्राहक पुलबाहिर राख्नुहोस्। PPP जडान फरक लेबल भएको Ethernet यन्त्र होइन, र pppd को कागजात गरिएको पूर्वनिर्धारित मार्ग तर्क IPCP वार्तापछि चल्छ र त्यो लिङ्क खस्दा आफ्नो मार्ग फिर्ता लिन्छ। DHCP टेम्प्लेट प्रतिलिपि गरेर हरेक usb0 लाई ppp0 नाम दिनुले गेटवे, मेट्रिक वा जीवनचक्रबारे केही प्रमाणित गर्दैन।

कुनै पनि कन्फिग सम्पादन गर्नुअघि प्रिफिक्सहरू छान्नुहोस्

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

पहिलो पोखरी क्यारियरले मोडेमलाई दिएको underlay ठेगाना हो; त्यो ग्राहकतर्फ देखिने हरेक योजनाबाहिर रहनुपर्छ। दोस्रो सर्भरले छानेको सुरुङ सबनेट हो, प्रायः आफ्नै निजी /24। तेस्रो hotspot पुल हो, र चौथो तपाईं पुग्न चाहनुभएको घरको प्रिफिक्स हो। यो यात्रामा hotspot ले 172.28.90.0/24 पाउँछ, पुल 172.28.90.1 मा छ, र घरको सेवा LAN ले 192.168.77.0/24 राख्छ, जसले उपभोक्ता राउटरसँग आउने 192.168.1.0/24 र 10.0.0.0/24 पूर्वनिर्धारित र 100.64.0.0/10 क्यारियर दायरा छल्छ।

hotspot को DHCP दायरामा पुलको ठेगाना मात्र गेटवेका रूपमा घोषणा गर्नुहोस्, अरू केही होइन। hotspot ग्राहकहरूलाई कहिल्यै गेटवेका रूपमा घरको ठेगाना नदिनुहोस्; त्यो खण्डसम्म तिनीहरूको लिङ्क-तह मार्ग छैन।

हरेक दिशालाई त्यसको स्वामित्व भएको पक्षमा राउट गर्नुहोस्

Pi लाई सुरुङमार्फत घरको प्रिफिक्सको मार्ग चाहिन्छ। सर्भर मोडका सर्भरहरूले सामान्यतया त्यो मार्ग धकेल्छन्, त्यसैले पहिले फर्वार्डिङ खुला छ र कर्नेलले tun0 बाट घरको ठेगाना समाधान गर्छ भनी पुष्टि गर्नुहोस्।

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

यदि ip route get अझै underlay इन्टरफेस रिपोर्ट गर्छ भने त्यहीँ रोक्नुहोस्; मार्गमा अगाडि केहीले पनि गलत खोजी सुधार्न सक्दैन।

घरका यन्त्रहरूसँग 172.28.90.0/24 सम्म मार्ग छैन, त्यसैले तिनका जवाफहरू पूर्वनिर्धारित गेटवे पछ्याउँछन् र राउटरमा मर्छन्। दुई समर्थित सुधारहरू छन्। या त घरको राउटरमा hotspot प्रिफिक्सलाई VPN सर्भरको LAN ठेगानातिर निर्देश गर्ने स्थिर मार्ग थप्नुहोस्, वा सर्भर आफैं गेटवे हुँदा ग्राहक प्रिफिक्स सर्भरको आफ्नै राउटिङ तालिकामा दर्ता गर्नुहोस्। OpenVPN को बहु-ग्राहक मोडमा ग्राहक-विशिष्ट डाइरेक्टरीले त्यो सम्बन्ध बोक्छ: ग्राहक प्रमाणपत्रको सामान्य नाममा नाम राखिएको फाइल, जसमा iroute 172.28.90.0 255.255.255.0 र त्यसलाई सर्भर कर्नेलमा स्थापना गर्ने मिल्दो route लाइन हुन्छ। सर्भरमा अनुमान गरिएको कर्नेल मार्ग कुन ग्राहक प्रिफिक्सको मालिक हो भनी सर्भरलाई भन्नुसरहको कथन होइन।

यो काम गराउन घरको नेटवर्कको DHCP सेवा VPN सर्भरमा सार्नु हुँदैन। पूरै घरको पूर्वनिर्धारित गेटवे बदल्नु एउटा निजी फर्कने मार्ग थप्नुभन्दा धेरै ठूलो परिवर्तन हो, र यसले DNS, ठेगाना आरक्षण र नयाँ लिज बेवास्ता गर्ने हरेक यन्त्रलाई असफलतामा तान्छ।

फायरवाल अनुमान नगरी फर्वार्डिङ खोल्नुहोस्

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 बाट tun0 सम्म स्वीकृति नियम र मिल्दो जवाफ दिशा, साथै स्रोत पुनःलेखन गर्न सक्ने postrouting नियम खोज्नुहोस्। यदि चेन नीति drop छ र कुनै नियम मिल्दैन भने, नीति accept मा उल्ट्याउनुको सट्टा साँघुरो स्वीकृतिहरू थपेर फेरि परीक्षण गर्नुहोस्।

अनुवाद आवश्यकता होइन, नीतिको छनोट हो। घरको LAN तर्फ स्रोत NAT ले हरेक hotspot ग्राहकलाई Pi को सुरुङ ठेगानाजस्तो देखाउँछ, जसले घरको लगमा प्रति-ग्राहक श्रेय गुमाउँछ र मूल स्रोत अपेक्षा गर्ने सेवाहरू तोड्छ। NAT बिना राउटिङले ग्राहक ठेगानाहरू देखिने राख्छ तर माथिको फर्कने मार्गमा निर्भर हुन्छ। एउटा छान्नुहोस् र DNS तथा IPv6 लाई पनि उही तरिकाले व्यवहार गर्नुहोस्, किनकि बिग्रेको IPv6 मार्गको छेउमा चल्ने IPv4 मार्ग ब्राउजरमा अझै आधा बिग्रेको पढिन्छ।

आउने-जाने यात्रा जाँच्नुहोस्, त्यसपछि जानाजान तोड्नुहोस्

hotspot ग्राहकबाट परीक्षण गर्नुहोस्, कहिल्यै Pi बाट होइन, किनकि Pi को आफ्नै ट्राफिकले अगाडिको र फर्कने दुवै मार्ग छल्छ। एउटा ग्राहक घरको सेवासम्म पुग्न प्रयास गर्दा दुवै इन्टरफेस हेर्नुहोस्।

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

दुवै क्याप्चर सँगै पढ्नुहोस्। br0 मा देखिएर tun0 मा कहिल्यै नदेखिने अनुरोधहरूको अर्थ Pi फर्वार्ड गर्दैन वा मार्ग अन्तै देखाउँछ। tun0 मा जवाफ नभएका अनुरोधहरूको अर्थ घरको पक्षमा फर्कने मार्ग छैन वा सर्भरले प्याकेट फिल्टर गर्यो। tun0 मा देखिएर br0 मा फेरि नदेखिने जवाफहरूको अर्थ उल्टो फिल्टर नियम हराएको छ, जहाँ सुरुङ उत्तम देखिन्छ र ग्राहकले अझै केही देख्दैन।

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

hotspot ग्राहकले घरको नाम समाधान गर्न, TCP सेवा खोल्न र एउटा मोडेम पुनःजडानभरि सत्र जीवित राख्न सक्दा मात्र डिजाइन स्वीकार गर्नुहोस्। यदि अनुप्रयोगलाई घरको खण्डमा साँच्चै Ethernet-तहको पत्ता लगाउने कुरा चाहिन्छ भने, स्थानीय पुललाई पुल गरिएको भनी वर्णन गरेर प्रसारण आउने प्रतीक्षा गर्नुको सट्टा समर्थित Layer 2 डिजाइन छान्नुहोस्।

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