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 से वायरलेस प्रोफ़ाइल फिर से उठाएँ और लिखे हुए मानों की तुलना चालू मानों से करें।