hostapd và OpenVPN trên một Pi: tuyến mặc định thuộc về ai?

Điện thoại kết nối với điểm truy cập, nhận địa chỉ, rồi không tới được gì ngay khi đường hầm lên. hostapd thường vẫn khỏe trong trạng thái đó, và OpenVPN cũng vậy; thứ hỏng là tuyến mặc định, hoặc chưa từng tồn tại trên cầu hoặc đã bị đường hầm thay thế mà không để lại đường tới chính máy chủ VPN. Hướng dẫn này đưa tuyến đó về đúng chỗ và chứng minh kết quả từ một máy khách chứ không phải từ Pi. Mỗi bước đều có thể hoàn tác, và không có gì ở đây thay đổi cấu hình của đường hầm cho tới khi bạn biết mình muốn loại lưu lượng nào bên trong nó.

Kiểm kê các giao diện trước khi bạn sửa bất cứ thứ gì

Cách bố trí quen thuộc đặt radio không dây và cổng có dây bên trong br0, khởi động hostapd với cầu và cấp phát thuê từ dnsmasq, trong khi một máy khách OpenVPN tạo tun0. Khi đó ba yêu cầu riêng biệt trông như một: máy khách của điểm truy cập cần Pi làm cổng của chúng, Pi cần tuyến tới internet để tới máy chủ của nó, và cầu cần một địa chỉ cổng mà những máy khách đó có thể dùng.

Đọc trạng thái hiện tại trước khi thay đổi, vì bốn lệnh này tách một vấn đề giao diện khỏi một vấn đề định tuyến.

ip -br addr
ip route show
ip link show master br0
bridge link show

Nếu br0 có địa chỉ nhưng không có tuyến mặc định, máy khách tới được Pi và không gì xa hơn. Nếu tuyến mặc định trỏ tới tun0 trong khi đường hầm xuống, Pi không có đường nào hoạt động, và triệu chứng ở máy khách trông y hệt. Cả hai trường hợp trông giống nhau từ điện thoại, vì thế phải đọc bảng tuyến trực tiếp.

Cho cầu một tuyến mặc định thuộc về nó

Raspberry Pi OS thường để cầu không có tuyến mặc định khi cầu xuất hiện sau khi tệp giao diện đã được ghi. Khối lệnh thuộc về /etc/dhcpcd.conf, và nó nên nêu tên router thượng nguồn chứ không phải Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Trong ví dụ đó 192.168.50.1 là router hiện có và 192.168.50.2 là địa chỉ cầu của Pi trong cùng mạng con, vì thế hãy thay bằng kế hoạch của bạn thay vì sao chép các con số. Các thành viên của cầu cũng không được yêu cầu router, nếu không Pi sẽ còn lại các tuyến mặc định cạnh tranh mà người thắng phụ thuộc vào metric và thời điểm chứ không phải ý định.

Sau systemctl restart dhcpcd, ip route show default phải liệt kê br0 một lần và không có bản trùng từ cổng có dây. Xác nhận truy vấn chứ không phải bảng, vì một mục cũ có thể nằm cạnh một mục thắng: ip -4 route get 203.0.113.10 phải nêu br0. Địa chỉ đó đến từ dải tài liệu TEST-NET-3, nên nó không thể đụng với một máy chủ thật khi bạn đọc điều này.

Ngăn đường hầm chiếm đoạt đường tới máy chủ của chính nó

Một máy khách OpenVPN chấp nhận redirect-gateway sẽ lấy tuyến mặc định và trỏ nó vào đường hầm. Điều đó đúng khi mọi máy khách của điểm truy cập nên dùng VPN, và sai khi chỉ một số đích nên dùng. Dù thế nào, kết nối của chính Pi tới máy chủ không được đi bên trong đường hầm mà nó còn đang dựng. OpenVPN thêm một tuyến host tới phía xa qua cổng gốc khi nó chuyển hướng tuyến mặc định, và đó chính là hành vi giữ cho vận chuyển sống; nếu tuyến đó thiếu, đường hầm sụp ngay khi thiết lập xong.

So sánh nhanh đường vận chuyển đó trước và sau khi kết nối đáng giá mười giây ấy. ip -4 route get 203.0.113.10 phải nêu thiết bị lớp dưới trong cả hai trạng thái, chỉ có metric thay đổi. Nếu nó nêu tun0 sau khi đường hầm lên, tuyến host chưa bao giờ được cài và lần kết nối lại tiếp theo sẽ thất bại.

Khi chỉ những tiền tố được chọn nên đi qua đường hầm, hãy dùng route-nopull và thêm các tuyến bạn muốn bằng tay, hoặc đẩy một tập hẹp hơn từ máy chủ. Trong thiết kế đó cầu giữ tuyến mặc định, và DNS trở thành quyết định tiếp theo: chuyển tiếp dnsmasq tới một bộ phân giải trong nhà chỉ có nghĩa với những tên thực sự sống ở đó.

Quyết định chuyện chuyển tiếp và NAT

Đường hầm đầy đủ cần bật chuyển tiếp trên Pi và một cổng ở phía xa sẵn lòng định tuyến mạng con của điểm truy cập. Kiểm tra chuyển tiếp trước mọi thứ khác, vì số không khiến mọi thay đổi tuyến trở nên vô nghĩa.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Quy tắc NAT là lối tắt hoạt động khi máy chủ không chấp nhận tiền tố của điểm truy cập, với cái giá là mọi máy khách hiện ra như địa chỉ đường hầm của Pi trong nhật ký phía xa. Định tuyến tiền tố mà không NAT giữ địa chỉ hiển thị và phụ thuộc vào một tuyến quay về cho 192.168.50.0/24 ở phía nhà.

Ghi lựa chọn bên cạnh các quy tắc tường lửa, vì một quy tắc NAT vô hình trong thiết kế sẽ trở nên không thể giải thích sau sáu tháng. Giữ IPv6 trong cùng quyết định; một đường IPv4 đang chạy bên cạnh một đường IPv6 hỏng vẫn bị đọc là hỏng một nửa trong trình duyệt.

Xác minh từ một máy khách, rồi hoàn tác gọn gàng

Hãy thử theo thứ tự này từ điện thoại hoặc máy tính xách tay trên điểm truy cập: một thuê bao từ dnsmasq, một ping tới địa chỉ cầu, rồi một đích ở phía bên kia đường hầm. Mỗi bước cô lập một lớp thay vì tạo ra một thất bại duy nhất vô ích.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Sau đó xác nhận Pi vẫn có lối ra của riêng nó: ip route get 203.0.113.10 phải nêu thiết bị lớp dưới, và ping -c 3 -I br0 203.0.113.10 phải trả lời nếu máy chủ cho phép ICMP. Nếu hai bước đầu của máy khách qua và bước thứ ba hỏng, lỗi nằm ở chuyển tiếp hoặc NAT. Nếu bước thứ hai hỏng, cầu hoặc DHCP vẫn chưa hoàn chỉnh.

Hoàn tác là một lần sửa tệp và hai lệnh: xóa khối, khởi động lại dhcpcd, và thay tuyến mặc định một cách tường minh bằng ip route replace default via 192.168.50.1 dev br0. Hãy làm điều đó trước khi cửa sổ bảo trì đóng chứ không phải sau, vì một Pi đã mất tuyến mặc định thì không thể tới được từ chính mạng bạn sẽ dùng để sửa nó.