VPN Pi nhiều router: đặt mỗi tuyến trên thiết bị ra quyết định
Router phía dưới thêm một subnet máy khách thứ hai, và mỗi thiết bị trong bốn thiết bị sở hữu một quyết định. Đặt các tuyến, kiểm tra nguồn, rồi thử từ một máy khách thật.
Đặt một hộp Wi-Fi sau Pi biến một quyết định định tuyến thành bốn, và kế hoạch vỡ khi cả bốn đều được đưa ra trên một thiết bị. Câu hỏi đầu tiên không phải thêm tuyến nào. Mà là hộp mới làm cầu nối hay định tuyến, vì câu trả lời đó quyết định có bao nhiêu subnet và thiết bị nào phải học về chúng. Hãy chọn mô hình kết nối trước; mọi tuyến đều xuất phát từ đó.
Cầu nối hay định tuyến: lựa chọn quyết định số lượng
Cầu nối đặt các máy khách mới vào cùng subnet mà Pi đã phục vụ. Một subnet, một thẩm quyền DHCP và không có chuyển giao nào để định tuyến. Đây là cách bố trí đơn giản hơn và đúng khi một mạng máy khách riêng chưa bao giờ là yêu cầu. Liên kết định tuyến là một thiết kế khác: hộp giữ subnet riêng của nó, và tiền tố đó phải được mang đến mọi nơi lưu lượng đi.
Phần còn lại của kế hoạch giữ router phía dưới và bảo toàn địa chỉ nguồn của máy khách. Mục tiêu là một mạng VPN riêng, không phải một cửa ra internet đầy đủ. Viết mô hình trước các địa chỉ, vì danh sách dưới đây chỉ là ví dụ về một kết nối định tuyến.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Ai quyết định điều gì
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Mỗi thiết bị đưa ra một quyết định, và không thiết bị nào có thể ra quyết định thay thiết bị khác. Pi cần hai mục chứ không phải một, và đường quay về là thứ người ta quên. Lưu lượng được chuyển tiếp đến mạng riêng một cách chính xác rồi chết trên đường về, vì Pi không biết 10.41.0.0/24 sống ở đâu. Điều đó trông như sự cố tường lửa và thực ra là một tuyến bị thiếu.
Phía xa cũng cần tuyến riêng. Nếu dịch vụ ở đầu xa không biết rằng 10.41.0.0/24 có thể đến được qua đường hầm của bạn, các phản hồi dừng ở bước nhảy đầu tiên không có câu trả lời. Thêm cả hai chiều trước khi đọc bộ lọc gói.
Các bước nhảy tiếp theo đến từ kết nối
Bước nhảy tiếp theo phải là một địa chỉ trên mạng mà thiết bị thực sự có thể đến. Địa chỉ công khai của đối tác VPN không phải bước nhảy tiếp theo cho một subnet riêng, và mạng dịch vụ xa hoàn toàn không phải bước nhảy tiếp theo. Một tuyến đến cổng không thể đến được trông đúng trong danh sách và bỏ mọi gói. Kiểm tra xem cổng có trả lời không trước khi đổ lỗi cho đích.
Giữ đối tác VPN bên ngoài của Pi có thể đến được qua tuyến lớp dưới của chính nó. Mục đó tách biệt khỏi các tuyến tải trọng, và trộn chúng lại cho ra một đường hầm không thể thiết lập lại sau khi đường đi thay đổi.
Tài liệu về tuyến tĩnh làm rõ sự khác biệt giữa đích và cổng, dù mỗi nền tảng đặt tên menu khác nhau. Hãy đọc tài liệu của thiết bị trước mặt thay vì sao chép màn hình của nhà cung cấp khác. Các lệnh dưới đây cho thấy hình dạng của các mục trên Linux.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Việc dịch làm gì với nguồn
Nếu router phía dưới đã dịch máy khách của nó sang địa chỉ trung chuyển, Pi thấy một nguồn đã dịch thay vì địa chỉ riêng của từng máy khách. Đó là một thiết kế khác với thiết kế giữ nguyên nguồn ở trên. Nó thay đổi chính sách dựa trên nguồn, ghi nhật ký và bên nào có thể khởi tạo kết nối. Cả hai thiết kế đều hoạt động; chúng trả lời những câu hỏi khác nhau.
Khi một dịch vụ VPN phía trên từ chối định tuyến tiền tố máy khách trở lại, một bản dịch hẹp ở cửa ra đường hầm của Pi có thể là một giải pháp hợp lệ. Đó không phải bằng chứng rằng tuyến bị thiếu là không cần thiết. Ghi lại địa chỉ mà mạng xa thực sự thấy và đường về nào phát sinh.
Chọn tuyến, quyền chuyển tiếp và dịch nguồn vẫn là ba công việc riêng. Xả một chuỗi NAT dùng chung hoặc cho phép mọi giao diện vì một máy khách có dây hoạt động chính là cách một bài kiểm tra đang chạy trở thành một bộ chuyển tiếp mở.
Chứng minh điều đó từ một máy khách
Gửi một yêu cầu từ một máy trên LAN phía dưới, rồi theo dõi nguồn của nó ra ngoài và quay về. Một ping do Pi phát ra không bao giờ thực hành tuyến về phía dưới, vì vậy một ping thành công chứng minh ít hơn vẻ ngoài của nó. Thêm bài kiểm tra thứ hai từ một máy khách có dây trên LAN của chính Pi để so sánh hai đường. Lặp lại cả hai sau khi khởi động lại bất kỳ thiết bị nào.
Các tuyến thêm bằng tay và các bản dịch chưa bao giờ được lưu biến mất cùng nhau. Khi đó cặp đôi trông như một lỗi mới thay vì công việc chưa xong.
Lưu mô hình kết nối cùng với các tuyến, dịch vụ riêng được phép và mọi bản dịch trong một ghi chú. Chính ghi chú đó ngăn người tiếp theo coi việc đặt vị trí không dây là một câu hỏi về chính sách định tuyến.