Ba quyết định địa chỉ trước khi đặt cảm biến IoT sau VPN
Ba địa chỉ đảm nhận ba vai trò: trung tâm công khai, đối tác trang đã xác thực và địa chỉ riêng của cảm biến. Hãy lập kế hoạch cho từng địa chỉ trước khi cấp phát bất cứ thứ gì công khai.
Ba địa chỉ quấn vào nhau trong mọi kế hoạch IoT qua VPN, và chúng không phải cùng một loại quyết định. Một là cách nhà điều hành từ xa tìm thấy điểm cuối của đường hầm, một là cách trang chứng minh rằng nó chính là trang đó, và một là nơi dịch vụ của cảm biến thực sự lắng nghe. Trả lời theo thứ tự đó và thiết kế phần lớn tự hiện ra. Trả lời chúng như một câu hỏi duy nhất và bạn sẽ đi đến chỗ cấp địa chỉ công khai cho những thiết bị chưa từng cần đến nó. Một cảm biến nằm sau đường hầm ra của trang có thể được nhà điều hành được ủy quyền truy cập mà không cần bất kỳ quy tắc vào nào trỏ tới cảm biến.
Bắt đầu bằng việc ai khởi tạo
Ai quay số quyết định gần như mọi thứ về sau. Khi trang quay số tới trung tâm, trang không cần khả năng tiếp cận vào, còn trung tâm cần một tên hoặc địa chỉ mà trang có thể phân giải. Lựa chọn duy nhất đó loại bỏ phần lớn cuộc tranh luận về địa chỉ công khai tĩnh trước khi nó bắt đầu.
Ba vai trò sau đó tách ra rõ ràng, và bảng dưới đây là dạng ngắn nhất của quyết định.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
Mỗi hàng có một chủ sở hữu khác nhau, và đó mới là điểm thực sự. Trung tâm thuộc về người vận hành dịch vụ VPN, đối tác trang thuộc nhóm mạng, và địa chỉ của cảm biến thuộc về người sở hữu thiết bị.
Địa chỉ trung tâm là khởi động, không phải đích đến
Một tên phân giải tới địa chỉ công khai được duy trì là đủ cho trung tâm. Bản ghi DNS có thể theo điểm cuối khi nó di chuyển, mà không phải sửa tay từng cấu hình trang. Điều DNS không làm là tạo khả năng tiếp cận hoặc làm mới một máy khách đang lưu câu trả lời cũ, và đó là những vấn đề riêng với cách khắc phục riêng.
Nếu bạn vận hành đường hầm trang-tới-trang không có trung tâm, logic tương tự vẫn đúng ở dạng khác: một bên cần điểm cuối có thể tiếp cận, hoặc cả hai bên quay số tới bên thứ ba. Vẫn phải có người sở hữu địa chỉ đó và các lần gia hạn của nó.
Đối tác trang là danh tính gắn với một tiền tố
Đối tác trước hết là danh tính và sau đó là tiền tố. Trong thuật ngữ WireGuard, đối tác giữ một cặp khóa và mục AllowedIPs của trung tâm gắn khóa đó với tiền tố của trang. Trong thuật ngữ IKEv2, chứng chỉ hoặc khóa chia sẻ trước xác định trang và các bộ chọn lưu lượng của nó cho biết nó có thể mang gì. Chỉ thay đổi một nửa sẽ phá vỡ cách bố trí, vì vậy thay đổi địa chỉ không bao giờ được coi là thay đổi danh tính.
Giữ quyền sở hữu khóa hoặc chứng chỉ ở phía trang thay vì ở nhà vận hành trung tâm, để việc đổi nhà cung cấp không trở thành đổi danh tính.
Tiền tố là phần người ta quên lập kế hoạch. Trung tâm phải liên kết mạng con của cảm biến với đúng đối tác, và máy khách của nhà điều hành cần một tuyến tới đó; một tuyến chỉ tồn tại trên máy khách sẽ đẩy lưu lượng vào một đường hầm lặng lẽ bỏ nó. Viết tiền tố vào bản ghi trang bên cạnh dấu vân tay khóa, để một cổng thay thế không thể xuất hiện với phạm vi khác mà không ai nhận ra.
Địa chỉ của cảm biến thuộc về ứng dụng
Một địa chỉ riêng từ kế hoạch của trang là đủ, và điều nó cần là sự ổn định chứ không phải khả năng tiếp cận công khai: một đặt trước DHCP, một gán tĩnh hoặc một tên trong vùng riêng của trang. Nếu thiết bị không thể đánh số lại, việc dịch địa chỉ trên cổng của trang là câu trả lời hợp lệ miễn là việc dịch được ghi lại và lưu lượng trở về đi theo nó.
Một thói quen nữa đáng giữ: đừng bao giờ dán địa chỉ công khai của trung tâm vào trường bước nhảy kế tiếp trên máy chủ của cảm biến. VPN cài đặt đường đi của riêng nó, và sự kề cận Ethernet thông thường với một điểm cuối công khai là một hư cấu tạo ra cấu hình trông có vẻ thuyết phục.
Câu trả lời là nửa bị bỏ qua. Thiết bị phải gửi câu trả lời của nó ngược về phía đường hầm, hoặc qua một tuyến tới máy khách của nhà điều hành, hoặc qua chính cổng đã dịch yêu cầu. Một cảm biến có cổng mặc định sai sẽ chấp nhận yêu cầu và trả lời vào hư không, và các ghi chú về chuyển tiếp giải thích vì sao việc đến và định tuyến câu trả lời là hai yêu cầu chứ không phải một.
Quyết định, rồi viết ranh giới
Viết ranh giới truy cập trước khi ai đó kết nối. Giới hạn cổng trong phân đoạn IoT và trong các dịch vụ cụ thể mà nhà điều hành cần, vì một tuyến đang hoạt động có xu hướng trở thành truy cập chung do vô tình. Giữ giám sát chỉ đọc và thẩm quyền cấu hình như những vai trò riêng với danh tính riêng, và nêu tên người gỡ bỏ quyền truy cập khi hợp đồng kết thúc.
Việc phê duyệt thuộc về chủ sở hữu mạng, và ở trong DMZ không phải là chính sách truy cập.
Bài kiểm tra sau triển khai thật nhàm chán và dứt khoát: một yêu cầu bên trong tiền tố được phép thành công, một bộ đếm tăng trên cổng, và một lần thử cố ý bên ngoài tiền tố thất bại.