چگونه سرور 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 دوباره بالا بیاورید و مقادیر ثبت‌شده را با مقادیر زنده بسنجید.