Máy khách hotspot trên Pi không tới được LAN trong nhà qua VPN TUN

Các máy khách Wi-Fi và Ethernet cục bộ kết nối với hotspot của Pi, lấy địa chỉ từ dải DHCP của nó và tải trang internet mà không phàn nàn. Sau đó chính các máy khách này bị hết thời gian khi mở chia sẻ tệp hoặc giao diện web trong LAN của nhà, trong khi bản thân Pi vẫn tới được LAN đó qua đường hầm. Không có gì hỏng trong tầng không dây. Thứ còn thiếu là một hợp đồng định tuyến: tiền tố của hotspot phải được đưa vào giao diện TUN, và một thứ gì đó phía nhà phải biết cách gửi câu trả lời ngược lại. Cả hai nửa phải cùng tồn tại trước khi một gói tin có thể hoàn tất chuyến đi khứ hồi.

Ba kết nối với ba nhiệm vụ khác nhau

Cầu nối Ethernet của Linux chuyển tiếp khung theo địa chỉ MAC đích. OpenVPN ở chế độ TUN mang gói IP và hoàn toàn không có tầng MAC, nên việc thêm một cầu nối cục bộ không bao giờ đăng ký đường hầm như một cổng. tài liệu TUN/TAP của hạt nhân giải thích sự tách đó: thiết bị TAP trông như giao diện Ethernet, thiết bị TUN thì không. Một thiết kế bắc cầu hai cổng cục bộ rồi định tuyến chính là router, bất kể tên giao diện nói gì.

Sự khác biệt đó quyết định quyền sở hữu. Subnet của máy khách, cổng mặc định của chúng và thẩm quyền DHCP cho dải đó thuộc về kế hoạch cục bộ của Pi. Quảng bá DHCP trong nhà không vượt qua một đường hầm được định tuyến, và không cấu hình cầu nối nào thay đổi điều đó; hướng máy khách tới máy chủ DHCP trong nhà là một thiết kế relay riêng, có chủ đích với các kiểu hỏng của riêng nó.

Cũng giữ modem ngoài cầu nối máy khách. Kết nối PPP không phải thiết bị Ethernet mang nhãn khác, và logic tuyến mặc định được ghi trong tài liệu của pppd chạy sau đàm phán IPCP và rút tuyến của nó khi liên kết đó hỏng. Sao chép mẫu DHCP và đổi tên từng usb0 thành ppp0 không chứng minh gì về cổng, metric hay vòng đời.

Chọn tiền tố trước khi sửa bất kỳ cấu hình nào

Tiền tố chồng lấn tốn nhiều buổi tối hơn các quy tắc tường lửa, vì chồng lấn đẩy việc tra tuyến tới giao diện sai ngay cả khi đường hầm khỏe mạnh. Hãy bắt đầu bằng việc liệt kê những gì đã có trên Pi, rồi đọc kết quả như bốn bể riêng biệt.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Bể thứ nhất là địa chỉ underlay mà nhà mạng cấp cho modem; nó phải nằm ngoài mọi kế hoạch hướng tới máy khách. Bể thứ hai là subnet của đường hầm do máy chủ chọn, thường là /24 riêng của nó. Bể thứ ba là cầu nối hotspot, và bể thứ tư là tiền tố trong nhà bạn muốn chạm tới. Trong chuyến này hotspot nhận 172.28.90.0/24 với cầu nối ở 172.28.90.1, và LAN dịch vụ trong nhà giữ 192.168.77.0/24, điều này tránh các mặc định 192.168.1.0/24 và 10.0.0.0/24 mà router tiêu dùng mang theo cùng dải nhà mạng 100.64.0.0/10.

Trong dải DHCP của hotspot chỉ quảng bá địa chỉ cầu nối làm cổng, không gì khác. Không bao giờ cấp địa chỉ trong nhà làm cổng cho máy khách hotspot; chúng không có đường ở tầng liên kết tới đoạn đó.

Định tuyến mỗi hướng ở phía sở hữu nó

Pi cần một tuyến tới tiền tố trong nhà qua đường hầm. Máy chủ ở chế độ máy chủ thường đẩy tuyến đó, nên trước hết hãy xác nhận chuyển tiếp đang bật và hạt nhân phân giải địa chỉ trong nhà từ tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Nếu ip route get vẫn báo giao diện underlay, hãy dừng ở đó; không gì xa hơn trên đường có thể sửa một lần tra sai.

Các thiết bị trong nhà không có tuyến tới 172.28.90.0/24, nên câu trả lời của chúng đi theo cổng mặc định và chết ở router. Có hai cách sửa được hỗ trợ. Hoặc thêm tuyến tĩnh trên router trong nhà trỏ tiền tố hotspot tới địa chỉ LAN của máy chủ VPN, hoặc khi máy chủ chính là cổng, hãy đăng ký tiền tố máy khách trong bảng định tuyến của chính máy chủ. Ở chế độ nhiều máy khách của OpenVPN, thư mục riêng cho máy khách mang liên kết đó: một tệp đặt tên theo common name của chứng chỉ máy khách, chứa iroute 172.28.90.0 255.255.255.0 cùng dòng route khớp để cài nó vào hạt nhân máy chủ. Một tuyến hạt nhân đoán được trên máy chủ không phải cùng một phát biểu với việc nói cho máy chủ biết máy khách nào sở hữu tiền tố.

Đừng chuyển dịch vụ DHCP của mạng trong nhà sang máy chủ VPN để việc này chạy. Thay cổng mặc định cho cả một ngôi nhà là thay đổi lớn hơn nhiều so với thêm một tuyến quay về riêng, và nó kéo DNS, đặt trước địa chỉ cùng mọi thiết bị bỏ qua hợp đồng thuê mới vào hỏng hóc.

Mở chuyển tiếp mà không đoán tường lửa

Chuyển tiếp bật không có nghĩa là gói tin được phép đi qua. Lưu lượng từ cầu nối tới đường hầm vẫn đụng các quy tắc lọc, và chính sách chuyển tiếp mặc định drop bỏ lưu lượng hotspot trong khi lưu lượng của chính Pi tiếp tục chạy, điều này tạo ra đúng triệu chứng chia đôi ở trên.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Tìm quy tắc chấp nhận từ br0 tới tun0 và hướng trả lời khớp, cùng quy tắc postrouting có thể viết lại nguồn. Nếu chính sách chuỗi là drop và không quy tắc nào khớp, hãy thêm các chấp nhận hẹp và kiểm tra lại thay vì lật chính sách thành accept.

Dịch địa chỉ là lựa chọn chính sách, không phải yêu cầu. NAT nguồn về phía LAN trong nhà làm mọi máy khách hotspot trông như địa chỉ đường hầm của Pi, điều này mất quy kết theo từng máy khách trong nhật ký nhà và phá các dịch vụ chờ nguồn gốc. Định tuyến không NAT giữ địa chỉ máy khách nhìn thấy được nhưng phụ thuộc tuyến quay về ở trên. Chọn một và xử lý DNS cùng IPv6 theo cùng cách, vì một đường IPv4 chạy được bên cạnh đường IPv6 hỏng vẫn bị đọc là hỏng một nửa trong trình duyệt.

Xác minh chuyến khứ hồi, rồi cố ý phá nó

Kiểm tra từ máy khách hotspot, không bao giờ từ Pi, vì lưu lượng của chính Pi đi vòng qua cả đường đi lẫn đường về. Quan sát cả hai giao diện khi một máy khách cố chạm tới một dịch vụ trong nhà.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Đọc cả hai bản ghi cùng nhau. Các yêu cầu trên br0 không bao giờ xuất hiện trên tun0 nghĩa là Pi không chuyển tiếp hoặc tuyến chỉ đi nơi khác. Các yêu cầu trên tun0 không có trả lời nghĩa là phía nhà không có tuyến quay về hoặc máy chủ đã lọc gói. Các trả lời trên tun0 không bao giờ xuất hiện lại trên br0 nghĩa là thiếu quy tắc lọc ngược, nơi đường hầm trông hoàn hảo mà máy khách vẫn không thấy gì.

Sau đó cố ý phá đường. Hạ kết nối modem rồi nâng lại và chạy lại các kiểm tra tuyến và bản ghi; một tuyến sống qua đường hầm nhưng biến mất khi kết nối lại thuộc về hồ sơ kết nối, không phải một lệnh một lần. Xác nhận rằng vận chuyển của đường hầm vẫn đi ra qua underlay chứ không qua chính nó, vòng lặp kinh điển khi một tuyến mặc định bị đẩy được chấp nhận mà không có tuyến host tới peer.

Chỉ chấp nhận thiết kế khi một máy khách hotspot phân giải được tên trong nhà, mở được dịch vụ TCP và giữ phiên sống qua một lần kết nối lại modem. Nếu một ứng dụng thực sự cần khám phá ở mức Ethernet trên đoạn trong nhà, hãy chọn thiết kế Layer 2 được hỗ trợ thay vì mô tả cầu nối cục bộ là đã bắc cầu và chờ quảng bá xuất hiện.