एउटै Pi मा hostapd र OpenVPN: पूर्वनिर्धारित रुट कसको?

फोनहरू एक्सेस पोइन्टमा जोडिन्छन्, ठेगाना लिन्छन्, र त्यसपछि टनेल उठ्ने बित्तिकै कतै पुग्दैनन्। त्यो अवस्थामा hostapd सामान्यतया स्वस्थ हुन्छ, र OpenVPN पनि; बिग्रने कुरा पूर्वनिर्धारित रुट हो, जो या त ब्रिजमा कहिल्यै थिएन वा टनेलले VPN सर्भरसम्मको बाटो नछोडी त्यसलाई बदल्यो। यो निर्देशिकाले त्यो रुटलाई यसको ठाउँमा फर्काउँछ र नतिजा Pi बाट नभई क्लाइन्टबाट प्रमाणित गर्छ। हरेक चरण उल्टाउन सकिने छ, र यहाँ केहीले पनि टनेलको कन्फिगरेसन बदल्दैन, तपाईंले यसभित्र कुन ट्राफिक चाहनुहुन्छ थाहा नपाएसम्म।

केही सम्पादन गर्नुअघि इन्टरफेसहरूको सूची बनाउनुहोस्

परिचित लेआउटले वायरलेस रेडियो र वायर्ड पोर्टलाई br0 भित्र राख्छ, ब्रिजविरुद्ध hostapd सुरु गर्छ र dnsmasq बाट भाडा बाँड्छ, जबकि OpenVPN क्लाइन्टले tun0 सिर्जना गर्छ। त्यसपछि तीन अलग आवश्यकताहरू एउटै जस्तो देखिन्छन्: एक्सेस पोइन्ट क्लाइन्टहरूलाई गेटवेको रूपमा Pi चाहिन्छ, Pi लाई आफ्नो सर्भरसम्म पुग्न इन्टरनेटमा रुट चाहिन्छ, र ब्रिजलाई ती क्लाइन्टहरूले प्रयोग गर्न सक्ने गेटवे ठेगाना चाहिन्छ।

परिवर्तन गर्नुअघि हालको अवस्था पढ्नुहोस्, किनभने यी चार आदेशले इन्टरफेस समस्यालाई राउटिङ समस्याबाट अलग गर्छन्।

ip -br addr
ip route show
ip link show master br0
bridge link show

यदि br0 मा ठेगाना छ तर पूर्वनिर्धारित रुट छैन भने, क्लाइन्टहरू Pi सम्म पुग्छन् र त्यसभन्दा पर केही पुग्दैनन्। यदि टनेल तल हुँदा पूर्वनिर्धारित रुटले tun0 लाई देखाउँछ भने, Pi सँग कुनै काम गर्ने बाटो नै हुँदैन, र क्लाइन्टको लक्षण ठ्याक्कै उस्तै देखिन्छ। दुवै अवस्था फोनबाट एउटै देखिन्छन्, त्यसैले रुट तालिका सिधै पढ्नुपर्छ।

ब्रिजलाई यसको आफ्नै पूर्वनिर्धारित रुट दिनुहोस्

Raspberry Pi OS ले इन्टरफेस फाइल लेखेपछि ब्रिज बनेको अवस्थामा ब्रिजलाई पूर्वनिर्धारित रुट बिना छोड्ने गर्छ। ब्लक /etc/dhcpcd.conf मा हुनुपर्छ, र यसले Pi लाई होइन, माथिल्लो राउटरलाई नाम दिनुपर्छ।

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

त्यो उदाहरणमा 192.168.50.1 विद्यमान राउटर हो र 192.168.50.2 उही सबनेटमा Pi को ब्रिज ठेगाना हो, त्यसैले संख्याहरू प्रतिलिपि गर्नुको सट्टा आफ्नै योजना राख्नुहोस्। ब्रिजका सदस्यहरूले पनि राउटर माग्नु हुँदैन, नत्र Pi मा प्रतिस्पर्धी पूर्वनिर्धारितहरू रहन्छन्, जसको विजेता मेट्रिक र समयमा भर पर्छ, मनसायमा होइन।

systemctl restart dhcpcd पछि ip route show default ले br0 एक पटक मात्र देखाउनुपर्छ र वायर्ड पोर्टबाट कुनै नक्कल हुनु हुँदैन। तालिका होइन, खोजी प्रमाणित गर्नुहोस्, किनभने पुरानो प्रविष्टि विजयी प्रविष्टिको छेउमा बस्न सक्छ: ip -4 route get 203.0.113.10 ले br0 लाई नाम दिनुपर्छ। त्यो ठेगाना TEST-NET-3 दस्तावेजीकरण दायराबाट आउँछ, त्यसैले यो पढ्दा यो वास्तविक सर्भरसँग ठोक्किन सक्दैन।

टनेललाई आफ्नै सर्भरको बाटो चोर्नबाट रोक्नुहोस्

redirect-gateway स्वीकार गर्ने OpenVPN क्लाइन्टले पूर्वनिर्धारित रुट लिन्छ र त्यसलाई टनेलभित्र पठाउँछ। हरेक एक्सेस पोइन्ट क्लाइन्टले VPN प्रयोग गर्नुपर्ने बेला यो सही हो, र केही गन्तव्यहरूले मात्र प्रयोग गर्नुपर्ने बेला गलत हो। जसरी पनि, Pi को सर्भरसँगको आफ्नै जडान अझै बनिरहेको टनेलभित्र जानु हुँदैन। OpenVPN ले पूर्वनिर्धारित पुनर्निर्देशन गर्दा मूल गेटवे हुँदै टाढाकोतर्फ होस्ट रुट थप्छ, र यही त्यो व्यवहार हो जसले ढुवानीलाई जीवित राख्छ; त्यो रुट नभएमा, टनेल स्थापित हुने बित्तिकै भत्किन्छ।

जोडिनुअघि र पछि त्यो ढुवानी बाटोको छिटो तुलना ती दस सेकेन्डको लायक छ। ip -4 route get 203.0.113.10 ले दुवै अवस्थामा अन्तर्निहित यन्त्रको नाम दिनुपर्छ, मेट्रिक मात्र बदलिन्छ। टनेल उठेपछि यसले tun0 लाई नाम दिन्छ भने, होस्ट रुट कहिल्यै स्थापना भएको थिएन र अर्को पुनःजडान असफल हुनेछ।

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

फर्वार्डिङ र NAT को निर्णय गर्नुहोस्

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT नियम त्यो छोटो बाटो हो जुन सर्भरले एक्सेस पोइन्ट प्रिफिक्स स्वीकार नगर्दा काम गर्छ, तर यसको मूल्य पल्लो छेउको लगमा हरेक क्लाइन्ट Pi को टनेल ठेगानाको रूपमा देखिनु हो। NAT बिना प्रिफिक्स राउट गर्दा ठेगानाहरू देखिने रहन्छन् र घरतर्फ 192.168.50.0/24 को लागि फर्कने रुटमा निर्भर हुन्छ।

फायरवाल नियमहरूको छेउमा छनोट लेख्नुहोस्, किनभने डिजाइनमा अदृश्य NAT नियम छ महिनापछि अस्पष्ट हुन्छ। IPv6 लाई उही निर्णयमा राख्नुहोस्; बिग्रिएको IPv6 बाटोको छेउमा काम गर्ने IPv4 बाटो ब्राउजरमा अझै आधा बिग्रिएको रूपमै पढिन्छ।

क्लाइन्टबाट प्रमाणित गर्नुहोस्, त्यसपछि सफा रोलब्याक गर्नुहोस्

एक्सेस पोइन्टमा रहेको फोन वा ल्यापटपबाट यो क्रममा परीक्षण गर्नुहोस्: dnsmasq बाट भाडा, ब्रिज ठेगानामा ping, त्यसपछि टनेलको पल्लो छेउमा गन्तव्य। हरेक चरणले एउटा तह अलग गर्छ, एउटै बेकार असफलता उत्पन्न गर्नुको सट्टा।

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

त्यसपछि Pi सँग अझै आफ्नै बाहिर जाने बाटो छ भनी पुष्टि गर्नुहोस्: ip route get 203.0.113.10 ले अन्तर्निहित यन्त्रको नाम दिनुपर्छ, र सर्भरले ICMP अनुमति दिए ping -c 3 -I br0 203.0.113.10 ले जवाफ दिनुपर्छ। पहिला दुई क्लाइन्ट चरण पास भएर तेस्रो असफल भयो भने, त्रुटि फर्वार्डिङ वा NAT मा छ। दोस्रो चरण असफल भयो भने, ब्रिज वा DHCP अझै अपूर्ण छ।

रोलब्याक भनेको एउटा फाइल सम्पादन र दुई आदेश हुन्: ब्लक हटाउनुहोस्, dhcpcd पुनः सुरु गर्नुहोस्, र पूर्वनिर्धारित रुटलाई स्पष्ट रूपमा ip route replace default via 192.168.50.1 dev br0 ले बदल्नुहोस्। मर्मत विन्डो बन्द हुनुअघि यो गर्नुहोस्, पछि होइन, किनभने पूर्वनिर्धारित रुट गुमाएको Pi मर्मतका लागि प्रयोग गर्ने नेटवर्कबाट पुग्न सकिँदैन।