HTTP qua ZeroTier có được mã hóa không? Kiểm tra nơi overlay kết thúc
ZeroTier mã hóa các chặng peer-to-peer, không mã hóa phần LAN phía sau router hay bridge. Hãy kiểm tra nơi overlay kết thúc trước khi coi HTTP thường là an toàn.
Hãy làm các kiểm tra này theo thứ tự và dừng ở kiểm tra đầu tiên thất bại, vì mỗi câu trả lời thay đổi ý nghĩa của bước tiếp theo. Câu hỏi thật thì hẹp: HTTP thường trên một mạng ZeroTier có đi qua internet ở dạng rõ không? Giữa hai peer ZeroTier thì thường là không, vì overlay mã hóa chặng đó. Nhưng đó là phát biểu về hai điểm cuối, không phải về mọi đoạn mà một yêu cầu đi qua. Router, bridge hay reverse proxy dịch chuyển điểm cuối, và văn bản rõ lại bắt đầu ở phía bên kia của nó.
Kiểm tra 1: tìm địa chỉ mà trình duyệt gọi tới
So sánh URL với những gì máy thực sự có. ip -brief addr show liệt kê giao diện zt và địa chỉ overlay do bộ điều khiển mạng cấp; nếu URL dùng địa chỉ đó, socket của trình duyệt đi vào overlay.
Khi tên thay vào đó phân giải thành một địa chỉ LAN, overlay có thể không tham gia chút nào, bất kể chỉ báo trạng thái của client gợi ý gì. ip route get 10.147.20.5 in ra giao diện và địa chỉ nguồn mà kernel sẽ chọn, nên một giao diện zt ở đó nghĩa là gói tin đi vào overlay và tên NIC vật lý của bạn nghĩa là nó không đi vào. Tên thêm một lớp nữa: một bản ghi trỏ tới địa chỉ overlay hành xử khác với bản ghi trỏ tới địa chỉ LAN, và hậu tố tìm kiếm hay một mục trong tệp hosts có thể lặng lẽ quyết định bạn nhận được cái nào.
Kiểm tra 2: xác nhận cả hai đầu là peer, không phải relay giải mã
ZeroTier mã hóa giữa các peer, và ở nơi không có đường trực tiếp các gói được chuyển tiếp qua một root vẫn chuyển chúng đi trong trạng thái đã mã hóa. zerotier-cli peers đánh dấu đường của mỗi peer là DIRECT hoặc RELAY kèm một con số độ trễ. Đường được chuyển tiếp tốn các lượt khứ hồi, không tốn tính bí mật.
Điều làm thay đổi câu trả lời là một thành viên không thực sự là điểm cuối. Khi phía bên kia là một thành viên ZeroTier định tuyến hoặc bắc cầu vào một LAN vật lý, overlay kết thúc tại thành viên đó và chặng tiếp theo là Ethernet thường.
Kiểm tra 3: quan sát nơi yêu cầu trở nên đọc được
Trên máy chủ mà bạn tin là phục vụ trang, hãy bắt gói trên giao diện overlay khi tải lại: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Một dòng yêu cầu đọc được trong đầu ra đó chứng minh lưu lượng đã đến máy chủ ấy ở dạng đã giải mã, và đó chính là ranh giới bạn đang tìm.
Sau đó bắt gói trên giao diện hướng ra phần còn lại của LAN. Nếu cùng yêu cầu đó xuất hiện ở đó ở dạng rõ, nó đã rời overlay trước khi tới ứng dụng và mọi thiết bị trong đoạn đó đều đọc được. Nếu không có gì xuất hiện phía LAN mà trang vẫn tải, ứng dụng đang kết thúc ngay trên máy chủ ZeroTier.
Bắt loopback cũng quan trọng khi có reverse proxy phía trước, vì proxy nhận HTTPS và chuyển tiếp HTTP sẽ dời ranh giới về backend của chính nó.
Kiểm tra 4: tính đến mọi chặng phía sau router hoặc bridge
Một thành viên được cấu hình để định tuyến giữa overlay và một LAN là thiết kế thông thường và là nơi phần lớn các giả định này vỡ. Overlay bảo vệ đoạn từ trình duyệt tới router và không gì sau đó. Bridge kể cùng câu chuyện bằng cơ chế khác: overlay và đoạn vật lý trở thành một miền quảng bá duy nhất, nên yêu cầu từ một laptop được bắc cầu đi qua Ethernet thường dù laptop đó nằm trên mạng ZeroTier.
Hãy lần theo nó thay vì giả định. traceroute từ client tới địa chỉ dịch vụ cùng bảng định tuyến trên thành viên gateway cho thấy chặng cuối là zt hay eth.
ZeroTier cũng cung cấp chế độ trusted-path có thể bỏ bảo mật vận chuyển trên những đường cục bộ được chỉ định để lấy hiệu năng. Một mạng dùng nó không thừa hưởng giả định thông thường về đường đã mã hóa, nên hãy đọc cấu hình mạng trước khi trích dẫn một cái. Tài liệu giao thức mô tả cả việc mã hóa giữa các peer lẫn ngoại lệ đó.
Kiểm tra 5: quyết định ứng dụng còn phải làm gì
Tư cách thành viên overlay xác thực một thiết bị với một mạng và không nói gì về việc dịch vụ ở đầu bên kia có phải là thứ bạn định tới hay không. HTTPS trả lời một câu hỏi khác bằng cách gắn tên máy chủ với một khóa, nên hai lớp bảo vệ chồng lên nhau mà không thay thế nhau. Một peer được cấp quyền vẫn có thể là dịch vụ sai, và một điểm cuối bị xâm phạm đọc yêu cầu cả trước khi mã hóa lẫn sau khi giải mã. Không cơ chế nào kiểm toán những gì ứng dụng ghi lại.
Với bất cứ thứ gì có phiên dùng lại được hoặc mật khẩu, hãy kết thúc TLS tại ứng dụng hoặc tại proxy bạn kiểm soát và để bật xác thực chứng chỉ. Khi một dịch vụ cũ buộc phải ở lại HTTP thường, hãy ghi lại đường từ máy chủ tới máy chủ chính xác mà nó được phép dùng, ai có thể tới được và đoạn nào vẫn không được bảo vệ; ghi chú đó chính là thứ một người đánh giá sau này cần.
"VPN đã kết nối" không phải là đánh giá bất cứ điều gì trong số này. Phiên bản trung thực nêu tên cả hai điểm cuối, đường đi giữa chúng và chặng đầu tiên không được che phủ.
Giữ đầu ra bắt gói và danh sách peer bên cạnh tài liệu dịch vụ, để ai thay đổi tuyến hay thêm bridge đều thấy mình sắp phá vỡ giả định nào.