كيفية نقل خادم VPN على Raspberry Pi إلى 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. اخفض أولوية الرابط اللاسلكي بدل تعطيله، ليبقى مسار التراجع على بعد أمر واحد.

أثبت النفق من الخارج، لا من الشبكة المحلية

اتصال VPN يعمل من الأريكة يثبت أقل مما يبدو. فالمرور من داخل الشبكة المحلية إلى العنوان العام يمر عبر قواعد hairpin أو انعكاس تنفذها الموجّهات بشكل غير متسق، لذا يمكن أن ينجح اختبار محلي بينما المسار الخارجي مكسور. استخدم هاتفًا ببيانات خلوية، أو أي مضيف خارج الشبكة، لاختبار القبول. أبقِ محاولة الشبكة المحلية تشخيصًا اختياريًا منفصلًا.

ثم اقرأ السجل بالترتيب الذي تصل به الحزم. لا شيء على الإطلاق يعني أن المصافحة لم تصل إلى 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 وقارن القيم المسجلة بالقيم الحية.