Cách chuyển máy chủ VPN Raspberry Pi sang Ethernet

Đổi Pi từ Wi-Fi sang cáp trông như việc năm phút, và nó chỉ giữ nguyên như vậy nếu bạn coi việc chuyển là bốn thiết lập riêng biệt thay vì một. Tên điểm cuối mà máy khách của bạn gọi có thể giữ nguyên hệt như cũ trong khi địa chỉ bên dưới thay đổi. Thứ thực sự hỏng là một listener bị ghim vào địa chỉ cũ, một chuyển tiếp cổng vẫn nhắm vào lease không dây, hoặc một đường trả về đi ra qua giao diện mà bạn tưởng đã cho nghỉ. Hướng dẫn này giữ một đường khôi phục mở ở mỗi bước, nên một lần chuyển hỏng chỉ tốn một lần khởi động lại.

Ghi lại bốn chủ sở hữu trước khi bạn rút bất cứ thứ gì

Bốn thiết lập quyết định việc chuyển có sống sót hay không: địa chỉ Pi, địa chỉ ràng buộc OpenVPN, mục tiêu chuyển hướng của router và đường đi của các phản hồi. Ghi lại cả bốn trước khi chạm vào cáp, vì khi lease không dây biến mất bạn không còn đọc được các giá trị cũ từ máy. Giao diện có dây không kế thừa hồ sơ không dây, và trên Bookworm địa chỉ nằm trong NetworkManager trong khi Bullseye giữ nó trong dhcpcd.conf. Một đặt trước ghim địa chỉ MAC không dây không nói gì về eth0. Hãy coi địa chỉ mới là một gán mới cần bằng chứng riêng.

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

Listener là chủ sở hữu thứ hai. Nếu dịch vụ được khởi động với một địa chỉ ràng buộc cụ thể, socket chết cùng giao diện cũ; nếu nó ràng buộc mọi địa chỉ, socket sống sót và quy tắc router trở thành thứ duy nhất còn lại phải sửa.

Mục tiêu chuyển hướng và đường trả về là những chủ sở hữu mà người ta bỏ qua. Một chuyển tiếp vẫn trỏ tới 10.42.7.24 gửi các bắt tay đến một địa chỉ mà Pi không còn giữ, nên máy khách hết thời gian mà không có một dòng log nào ở phía máy chủ. Đường trả về quan trọng khi cả hai liên kết cùng hoạt động trong chốc lát, vì Pi trả lời từ giao diện mà bảng định tuyến ưu tiên, và đó không phải lúc nào cũng là giao diện mà gói tin đến. Truy vấn tuyến bên dưới cho thấy kernel chọn nguồn nào.

Đọc socket thực tế trước khi tin vào địa chỉ mới

Các tệp cấu hình mô tả ý định và socket mô tả thực tế. Hãy hỏi dịch vụ đang chạy xem nó ràng buộc vào đâu thay vì tin vào cấu hình bạn nhớ. Hướng dẫn OpenVPN 2.6 định nghĩa --local là ràng buộc vào một địa chỉ và lưu ý rằng bỏ qua nó sẽ ràng buộc mọi giao diện.

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

Đọc cột địa chỉ cục bộ thay vì cột trạng thái. Một dòng hiển thị 10.42.7.24:1194 nghĩa là socket bị ghim vào địa chỉ bạn sắp gỡ bỏ, trong khi 0.0.0.0:1194 hoặc *:1194 nghĩa là daemon sẽ tự theo sự thay đổi giao diện. Nếu địa chỉ bị ghim, hãy sửa hồ sơ và khởi động lại unit thay vì tự tay viết lại socket đang sống, rồi xác nhận dịch vụ vẫn tới được các tệp chứng chỉ và khóa của nó.

Thực hiện việc chuyển theo thứ tự giữ cho bạn luôn truy cập được

Thứ tự ở đây quan trọng hơn tốc độ. Bật liên kết có dây khi liên kết không dây vẫn hoạt động, xác nhận địa chỉ mới và đường trả về, rồi mới cho hồ sơ không dây nghỉ. Trình tự đó giữ một phiên làm việc mở cho tới khi bản thay thế được chứng minh.

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

Lệnh đầu tiên trả lời liệu eth0 có nhận được địa chỉ bạn dự định hay không, và lệnh thứ hai in ra địa chỉ nguồn mà kernel sẽ dùng cho một đích bên ngoài, nên hãy chạy nó trước và sau khi thay đổi. Nếu nguồn đó vẫn là địa chỉ không dây, liên kết có dây chưa phải đường ưu tiên và bài kiểm tra từ bên ngoài sẽ hỏng vì một lý do không liên quan gì đến OpenVPN. Sửa ưu tiên định tuyến trước khi chạm vào chuyển tiếp.

Khi cả hai liên kết hoạt động, Pi có thể ưu tiên tuyến mặc định không dây vì nó được cài trước hoặc vì liên kết có dây mang metric cao hơn. Trên Bookworm thiết lập được hỗ trợ là ipv4.route-metric trên kết nối, và trên Bullseye tương đương là dòng metric riêng cho giao diện trong dhcpcd.conf. Hạ ưu tiên liên kết không dây thay vì tắt nó, để đường quay lui vẫn cách một lệnh.

Chứng minh đường hầm từ bên ngoài, không phải từ LAN

Một kết nối VPN chạy được từ ghế sofa chứng minh ít hơn vẻ bề ngoài. Lưu lượng từ trong LAN tới địa chỉ công cộng đi qua các quy tắc hairpin hoặc phản xạ mà router triển khai không nhất quán, nên một bài kiểm tra LAN thành công có thể cùng tồn tại với đường bên ngoài hỏng. Hãy dùng điện thoại có dữ liệu di động, hoặc bất kỳ máy chủ nào ngoài mạng, cho bài kiểm tra chấp nhận. Giữ lần thử LAN như một chẩn đoán tùy chọn riêng.

Sau đó đọc log theo thứ tự gói tin đến. Không có gì cả nghĩa là bắt tay chưa bao giờ tới Pi, nên mục tiêu chuyển hướng hoặc tường lửa của máy chủ bị sai. Một bắt tay bắt đầu rồi kẹt cho thấy khóa, chứng chỉ hoặc MTU. Một phiên hoàn tất rồi rơi thường nghĩa là đường trả về hoặc tuyến mặc định thứ hai, và dòng log của máy khách Initialization Sequence Completed cho bạn biết chính đường hầm đã lên.

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

Nếu không có gì xuất hiện trong log máy chủ khi máy khách thử lại, hãy ngừng đọc cấu hình OpenVPN và quay lại mục tiêu chuyển hướng. Bản chụp trả lời câu hỏi về việc đến trong vài giây, và các gói vào không có phản hồi thu hẹp vấn đề vào tuyến.

Giữ một bước quay lui và cho hồ sơ không dây nghỉ

Để hồ sơ không dây được cài cho tới khi cách bố trí có dây qua được một lần khởi động lại. nmcli con show liệt kê các tên hồ sơ bạn sẽ cần, và một hồ sơ đã xóa phải được dựng lại từ trí nhớ vào lúc tệ nhất. Ghi lại tên giao diện, phương thức địa chỉ và metric bên cạnh bốn giá trị kia. Một bước quay lui bạn có thể gõ từ ghi chú đáng giá hơn một bước phải dựng lại.

Cho sự phụ thuộc không dây nghỉ là thay đổi thuộc tính chứ không phải xóa bỏ. Khi đặt connection.autoconnect no thông tin đăng nhập và lịch sử địa chỉ vẫn nguyên vẹn trong khi Pi bị ngăn kết nối lại vào mạng bạn đã rời đi.

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

Trước khi tuyên bố công việc xong, hãy xác nhận bốn điều: mục tiêu chuyển hướng khớp với địa chỉ có dây, listener sống sót qua một lần khởi động lại, máy khách từ bên ngoài hoàn tất bắt tay, và Pi vẫn trả lời trên địa chỉ có dây sau khi khởi động lại. Khởi động lại là cách rẻ nhất để bắt được một gán chỉ tồn tại trong kernel đang chạy. Nếu bất kỳ điều nào trong bốn hỏng, hãy bật lại hồ sơ không dây bằng sudo nmcli con up và so sánh các giá trị đã ghi với giá trị đang sống.