Hai điểm mạng di động không có cổng vào: dựng một trung tâm hoạt động

Hai điểm trên các đường truyền di động gặp cùng một vấn đề ở cả hai chiều: không điểm nào có thể nhận một kết nối IPv4 không được yêu cầu, nên không điểm nào có thể đóng vai máy chủ trong một đường hầm trực tiếp. Kiến trúc hiệu quả đặt một bên thứ ba có thể truy cập vào giữa: mỗi điểm gọi ra ngoài và phần giữa chỉ chuyển tiếp lưu lượng mà bạn phê duyệt. Phần giữa đó có thể là bộ định tuyến do bạn vận hành hoặc một sản phẩm giới thiệu các peer, và hai thứ đó không giống nhau. Các bước dưới đây được sắp xếp để mỗi bước tạo ra bằng chứng trước khi bước sau phụ thuộc vào nó.

Không điểm nào có thể bị gọi vào, nên cả hai phải gọi ra ngoài

Xác nhận ràng buộc trước khi thiết kế quanh nó. Nếu nhà mạng cấp cho giao diện WAN một địa chỉ riêng, không quy tắc chuyển tiếp cổng nào trên bộ định tuyến của chính điểm đó làm nó truy cập được, vì việc dịch địa chỉ diễn ra ở phía trên. Một địa chỉ IPv6 công cộng có thể tồn tại trên cùng đường truyền và thay đổi hoàn toàn thiết kế, nên việc kiểm tra bao gồm cả hai họ địa chỉ. Ghi lại câu trả lời cho từng điểm, vì hai điểm hiếm khi có cùng ràng buộc dù dùng chung nhà mạng.

Trường hợp di động thông thường trông giống một địa chỉ từ dải đã dịch của nhà mạng với một tuyến mặc định đi qua nó. Đây không phải lỗi cần sửa; đây là lý do trung tâm tồn tại. Thứ bạn tìm là bất kỳ địa chỉ nào mà bên thứ ba có thể tới được mà điểm chưa hề nói trước.

Hai lệnh trả lời câu hỏi về địa chỉ cho điểm bạn đang đứng trước. Chạy chúng trên bộ định tuyến của điểm, không phải trên máy tính xách tay phía sau nó:

ip -4 addr show scope global
ip -6 addr show scope global

Ai giới thiệu các peer và ai mang các gói tin

Giới thiệu và truyền tải là hai công việc riêng biệt mà các sản phẩm thường gộp lại mà không làm rõ ranh giới. Cơ chế gặp gỡ giúp hai peer tìm được một đường đi ứng viên; bộ chuyển tiếp mang gói tin của họ khi không có đường trực tiếp. Mua một dịch vụ giới thiệu peer không cho bạn bộ định tuyến, và khác biệt đó quyết định thiết kế có cần trung tâm hay không.

Việc xuyên qua có từ vựng riêng, và các từ mô tả vai trò chứ không phải bảo đảm. Đặc tả ICE mô tả các ứng viên và kiểm tra kết nối, STUN mô tả một cách để biết về việc dịch địa chỉ, và TURN mô tả truyền tải qua bộ chuyển tiếp cho các ứng dụng triển khai nó. Không cơ chế nào trong số này xuất hiện trong một cổng mặc định vì bạn đã trỏ nó tới một địa chỉ khám phá. Hãy kiểm chứng việc xuyên qua như một năng lực của sản phẩm, và giả định có bộ chuyển tiếp cho tới khi một bài kiểm tra cho thấy điều ngược lại.

Một tuyến cho mỗi điểm, do một peer sở hữu

Trung tâm cần một đường hầm cho mỗi điểm, một tiền tố LAN riêng phía sau mỗi điểm, và một tuyến cho mỗi tiền tố nêu tên chủ sở hữu. Trong ví dụ, trung tâm là 10.61.0.1, điểm A là 10.61.0.11 với LAN 10.60.10.0/24, và điểm B là 10.61.0.12 với LAN 10.60.20.0/24. Mỗi tuyến dưới đây trỏ tới peer sở hữu tiền tố, không trỏ tới giao diện đường hầm:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

Phải bật chuyển tiếp, nếu không các gói tin dừng lại ở trung tâm mà không có lỗi nào chỉ ra nguyên nhân. Lệnh cuối trả lời câu hỏi thật, vì nó hỏi gói tin sẽ đi theo đường nào từ LAN của điểm A tới LAN của điểm B khi nguồn được đưa vào tra cứu. Hãy coi tra cứu nêu tên giao diện đường hầm là bằng chứng và tra cứu rơi về tuyến mặc định là tuyến bị thiếu, không phải điều bí ẩn. Sau đó chủ động giới hạn lưu lượng đi qua, vì một trung tâm chuyển tiếp giữa mọi peer biến hai điểm thành một mạng phẳng và chính sách truy cập bạn tưởng có sẽ không còn áp dụng.

Cũng phải quyết định nơi mã hóa kết thúc. Khi trung tâm giữ cả hai đầu đường hầm, người vận hành máy đó và khối lượng công việc của nó tham gia vào mô hình tin cậy và sẵn sàng, và băng thông của nó trở thành một phần của đường đi.

Giữ mọi ánh xạ sống qua nhà mạng

Mỗi điểm tự khởi tạo đường hầm của mình, và mỗi điểm phải giữ ánh xạ dịch địa chỉ sống, nếu không nhà mạng sẽ quên nó. Thông điệp giữ kết nối ở phía khởi tạo bảo toàn ánh xạ đó giữa các lần bắt tay. Giới hạn các tiền tố được phép ở địa chỉ trung tâm và LAN từ xa, để một peer bị xâm nhập không thể đòi một tiền tố mà nó không sở hữu:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

Sao chép khối này ở điểm kia với tiền tố từ xa của chính nó, và chống lại mong muốn cho phép toàn bộ dải đường hầm. Một lần bắt tay dừng rồi tiếp tục từ cổng nguồn mới là dấu hiệu của một ánh xạ đã hết hạn, và dấu thời gian của lần bắt tay là bằng chứng điều đó đã xảy ra. Một khoảng ngắn hơn thời gian chờ của nhà mạng ngăn việc hết hạn thay vì sửa nó sau đó. Khi nhà mạng thay đổi hành vi dịch địa chỉ, hãy dự kiến các mốc thời gian đó cũng thay đổi theo.

Chứng minh cả hai chiều, rồi chứng minh khả năng phục hồi

Việc kiểm chứng có tính hướng, nên một ping từ A tới B chứng minh một nửa thiết kế và không nói gì về tuyến quay lại. Kiểm tra đường phản hồi bằng cùng tra cứu nhận biết nguồn trên trung tâm, rồi lặp lại bài kiểm tra từ phía bên kia. Các lần bắt tay mới cũng thuộc phần bằng chứng, vì một đường hầm im lặng suốt một giờ có thể đang kiểm tra một ánh xạ cũ:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

Sau đó hãy kiểm tra sự cố bạn dự kiến, không phải thành công bạn muốn. Khởi động lại đường truyền của một điểm và xác nhận đường hầm trở lại mà không cần ai chạm vào đầu nào, vì một thiết kế cần người vận hành sau mỗi thay đổi của nhà mạng là chưa hoàn chỉnh. Ghi lại tuyến chính, phương án IPv6 khi có, và hành vi khi trung tâm không sẵn sàng. Trung tâm giờ là một phần mô hình sẵn sàng của bạn, nên hãy viết điều đó ra thay vì phát hiện trong lúc có sự cố.