Raspberry Pi VPN सर्भरलाई Ethernet मा कसरी सार्ने

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

केही पनि निकाल्नुअघि चार मालिक लेख्नुहोस्

चार सेटिङले कटओभर बाँच्ने वा नबाँच्ने निर्धारण गर्छन्: Pi को ठेगाना, OpenVPN को बाइन्डिङ ठेगाना, राउटरको रिडाइरेक्ट लक्ष्य र जवाफ जाने बाटो। केबल छुनुअघि चारै लेख्नुहोस्, किनकि वायरलेस लिज हराएपछि तपाईं मेसिनबाट पुराना मान पढ्न सक्नुहुन्न। वायर्ड इन्टरफेसले वायरलेस प्रोफाइल उत्तराधिकारमा पाउँदैन, र Bookworm मा ठेगाना NetworkManager मा बस्छ जबकि Bullseye यसलाई dhcpcd.conf मा राख्छ। जुन आरक्षणले वायरलेस MAC ठेगाना पिन गरेको थियो, त्यसले eth0 को बारेमा केही भन्दैन। नयाँ ठेगानालाई आफ्नै प्रमाण चाहिने नयाँ आवण्टनका रूपमा लिनुहोस्।

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

लिस्नर दोस्रो मालिक हो। यदि सेवा कुनै विशेष बाइन्डिङ ठेगानासँग सुरु भएको थियो भने सकेट पुरानो इन्टरफेससँगै मर्छ; यदि यसले सबै ठेगाना बाँध्छ भने सकेट बाँच्छ र राउटरको नियम मात्र ठीक गर्न बाँकी हुन्छ।

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

नयाँ ठेगानामा विश्वास गर्नुअघि वास्तविक सकेट पढ्नुहोस्

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

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

स्थिति स्तम्भको सट्टा स्थानीय ठेगाना स्तम्भ पढ्नुहोस्। जुन लाइनले 10.42.7.24:1194 देखाउँछ त्यसको अर्थ सकेट तपाईं भर्खर हटाउन लागेको ठेगानामा पिन भएको छ, जबकि 0.0.0.0:1194 वा *:1194 को अर्थ डेमन आफैं इन्टरफेस परिवर्तन पछ्याउनेछ। ठेगाना पिन भएको छ भने चलिरहेको सकेट हातैले पुनः नलेखी प्रोफाइल सम्पादन गर्नुहोस् र युनिट रिस्टार्ट गर्नुहोस्, त्यसपछि सेवा अझै आफ्ना प्रमाणपत्र र कुञ्जी फाइलहरूसम्म पुग्छ भनी पुष्टि गर्नुहोस्।

परिवर्तन तपाईंलाई पुग्नयोग्य राख्ने क्रममा गर्नुहोस्

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

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

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

दुवै लिंक सक्रिय हुँदा Pi ले वायरलेस पूर्वनिर्धारित रुटलाई प्राथमिकता दिन सक्छ किनकि त्यो पहिले जडान भयो वा किनकि वायर्ड लिंकको मेट्रिक बढी छ। Bookworm मा समर्थित सेटिङ जडानमा ipv4.route-metric हो, र Bullseye मा यसको समकक्ष इन्टरफेस-विशिष्ट metric लाइन dhcpcd.conf मा छ। रोलब्याक बाटो एक कमान्डको दूरीमा राख्न वायरलेस लिंक बन्द गर्नुको सट्टा त्यसको प्राथमिकता घटाउनुहोस्।

टनेल बाहिरबाट प्रमाणित गर्नुहोस्, LAN बाट होइन

सोफाबाट चल्ने VPN जडानले देखिनेभन्दा कम प्रमाणित गर्छ। LAN भित्रबाट सार्वजनिक ठेगानातर्फ जाने ट्राफिक hairpin वा परावर्तन नियमहरूबाट जान्छ जसलाई राउटरहरू असंगत रूपमा लागू गर्छन्, त्यसैले उत्तीर्ण LAN परीक्षण भाँचिएको बाहिरी बाटोसँगै रहन सक्छ। स्वीकृति परीक्षणका लागि सेलुलर डेटा भएको फोन वा नेटवर्कबाहिरको कुनै पनि होस्ट प्रयोग गर्नुहोस्। LAN प्रयासलाई छुट्टै ऐच्छिक निदानका रूपमा राख्नुहोस्।

त्यसपछि लगलाई प्याकेट आउने क्रममै पढ्नुहोस्। केही पनि नहुनु भनेको ह्यान्डशेक Pi सम्म कहिल्यै पुगेन, त्यसैले रिडाइरेक्ट लक्ष्य वा होस्ट फायरवाल गलत छ। सुरु भएर अड्किने ह्यान्डशेकले कुञ्जी, प्रमाणपत्र वा MTU तर्फ संकेत गर्छ। पूरा भएर खस्ने सेसनले सामान्यतया फर्किने बाटो वा दोस्रो पूर्वनिर्धारित रुट जनाउँछ, र क्लाइन्टको लग लाइन Initialization Sequence Completed ले टनेल आफैं माथि आएको बताउँछ।

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

क्लाइन्ट पुनः प्रयास गर्दा सर्भर लगमा केही देखिएन भने OpenVPN कन्फिग पढ्न छोड्नुहोस् र रिडाइरेक्ट लक्ष्यमा फर्कनुहोस्। क्याप्चरले पुग्ने प्रश्नको जवाफ सेकेन्डमा दिन्छ, र जवाफ नभएका आउने प्याकेटले समस्यालाई रुटसम्म सीमित गर्छ।

एक-चरणीय रोलब्याक राख्नुहोस् र वायरलेस प्रोफाइल अवकाश दिनुहोस्

वायर्ड व्यवस्थाले एक रिबुट पार नगरेसम्म वायरलेस प्रोफाइल इन्स्टल रहन दिनुहोस्। nmcli con show तपाईंलाई चाहिने प्रोफाइल नामहरू सूचीबद्ध गर्छ, र मेटिएको प्रोफाइल सबैभन्दा नराम्रो क्षणमा सम्झनाबाट पुनः बनाउनुपर्छ। इन्टरफेसको नाम, ठेगाना विधि र मेट्रिक अरू चार मानको छेउमा लेख्नुहोस्। नोटबाट टाइप गर्न सकिने रोलब्याक पुनः बनाउनुपर्नेभन्दा बढी मूल्यवान् हुन्छ।

वायरलेस निर्भरता अवकाश दिनु हटाउनु होइन, गुण परिवर्तन हो। connection.autoconnect no सेट गर्दा प्रमाणहरू र ठेगाना इतिहास सुरक्षित रहन्छन् जबकि Pi तपाईंले छोडेको नेटवर्कमा फेरि जोडिनबाट रोकिन्छ।

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

काम सकियो भनी घोषणा गर्नुअघि चार कुरा पुष्टि गर्नुहोस्: रिडाइरेक्ट लक्ष्य वायर्ड ठेगानासँग मिल्छ, लिस्नर एक रिस्टार्टबाट बाँच्यो, बाहिरी क्लाइन्टले ह्यान्डशेक पूरा गर्छ, र रिबुटपछि पनि Pi वायर्ड ठेगानामा जवाफ दिन्छ। रिबुट चलिरहेको कर्नेलमा मात्र भएको आवण्टन पक्रने सबैभन्दा सस्तो उपाय हो। चारमध्ये कुनै पनि असफल भयो भने, sudo nmcli con up प्रयोग गरी वायरलेस प्रोफाइल फेरि माथि उठाउनुहोस् र लेखिएका मानको चालु मानसँग तुलना गर्नुहोस्।