Cách ghi lại và xác minh địa chỉ thoát VPN bạn đã dùng
Ứng dụng khách hiển thị tên vị trí, không phải địa chỉ mà lưu lượng của bạn đã đi ra. Ghi lại IP thoát lúc kết nối và so sánh với một đường cơ sở trực tiếp.
Hỏi một ứng dụng VPN trên máy tính xem bạn đã dùng máy chủ nào, và câu trả lời trung thực thường là một tên vị trí. Tên đó là điểm vào bạn đã chọn, và địa chỉ mà lưu lượng của bạn đi ra có thể là một máy hoàn toàn khác. Không có gì trong ứng dụng được thiết kế để giữ con số thứ hai, nên bản ghi phải được dựng ngay lúc dùng. Có hai cách tiếp cận, và chỉ một trong số đó sống sót qua một ca hỗ trợ.
Hai bản ghi, và chỉ một trong số đó tồn tại
Góc nhìn của chính ứng dụng khách, trong trường hợp tốt nhất, là danh sách các vị trí đã chọn kèm dấu thời gian. Đó là quyết định thiết kế chứ không phải sơ suất: địa chỉ là chi tiết vận hành, chúng luân chuyển giữa các lần gán, và việc công khai ánh xạ khiến cả hỗ trợ lẫn xử lý lạm dụng khó hơn. Các nhà cung cấp đặt phiên bản đám mây trước mạng của họ chính là để điểm cuối có thể chuyển đi mà không báo cho ai. Điều ứng dụng hiển thị cho bạn là lựa chọn bạn đã thực hiện, không phải tuyến đường mà lưu lượng đã đi.
Bản ghi bạn có thể tự dựng là một tệp cục bộ gồm một địa chỉ công khai và một dấu thời gian UTC trên mỗi dòng. Nó nhỏ hơn, xấu hơn và hữu ích hơn nhiều, vì nó mô tả đúng điều mà một quan sát viên bên ngoài cũng có thể thấy.
Phương án A: tự ghi lại địa chỉ thoát
Một dịch vụ dội trả về địa chỉ nguồn mà yêu cầu đến từ đó, mà theo định nghĩa chính là địa chỉ thoát. Chạy việc ghi lại sau khi đường hầm báo đã kết nối, vì một ứng dụng khách nói đã kết nối trước khi tuyến và DNS ổn định sẽ ghi địa chỉ trước đường hầm và làm hỏng bản ghi ngay từ dòng đầu.
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"Hai chi tiết khiến đoạn đó dùng được chứ không phải để trang trí. Dấu thời gian và địa chỉ nằm chung một dòng, nên lần phân tích sau không phải ghép cặp bản ghi, và umask 077 giữ tệp riêng tư ngay từ khi tạo. Hãy chạy nó một lần mỗi lần kết nối chứ không phải một lần mỗi lần khởi động, và giữ một tệp cho mỗi thiết bị.
Bản ghi ghi lại lúc bạn dùng một đường hầm và bạn xuất hiện từ mạng nào, điều này gần với lịch sử duyệt web hơn là một bộ đếm. Chọn một thời hạn lưu trữ bạn có thể bảo vệ được, giữ tệp ngoài các thư mục đồng bộ chia sẻ và xóa nó một cách có ý thức.
Phương án B: xin lịch sử từ nhà cung cấp
Một số nhà cung cấp lưu nhật ký kết nối và sẽ trả lời một câu hỏi hỗ trợ bằng dấu thời gian và tên máy chủ. Bản ghi đó mô tả hạ tầng của họ chứ không phải lưu lượng của bạn, và nó chỉ đáng giá bằng cửa sổ lưu trữ cùng thiện chí xem xét của họ. Nó cũng mô tả một phiên, không phải một yêu cầu. Cửa sổ thường ngắn, và được đo từ phía nhà cung cấp của đường hầm.
Nhà cung cấp quảng cáo không lưu nhật ký thì không thể cung cấp điều này theo yêu cầu, và danh sách vị trí gần đây ở phía ứng dụng khách không phải là cùng một thứ. Yêu cầu một nhà cung cấp không nhật ký cho địa chỉ thoát thường kết thúc bằng lời giải thích vì sao dữ liệu đó không tồn tại.
Mỗi bản ghi chứng minh được gì trong một ca hỗ trợ
Hai bản ghi trả lời hai câu hỏi khác nhau, và chính ở bảng so sánh thì việc đối chiếu thôi mang tính hàn lâm.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
Chỉ cột đầu tiên nằm trong tay bạn. Bản ghi của nhà cung cấp có thể xác nhận một tài khoản đã kết nối vào một thời điểm, nhưng không thể xác nhận yêu cầu nào đã dùng đường hầm, và sẽ không nêu tên một địa chỉ mà nhà cung cấp coi là chi tiết vận hành. Không bản ghi nào nhận diện một người, vì một địa chỉ thoát chia sẻ có thể mang nhiều khách hàng trong cùng một phút.
So sánh cả hai với một đường cơ sở trước khi tin bất kỳ bản ghi nào
Một địa chỉ tự nó không chứng minh gì. Ghi địa chỉ trực tiếp trước khi kết nối, địa chỉ qua đường hầm sau đó, và so sánh chúng. Giá trị giống nhau nghĩa là đường hầm không mang yêu cầu đó, dù vì một đường hầm chia tách, một proxy chi phối hay một ứng dụng khách đã rơi về đường trực tiếp.
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1Lặp lại việc so sánh cho DNS và cho IPv6, vì tiếng dội địa chỉ chứng minh đường đi của một yêu cầu HTTP duy nhất và không nói gì về việc trình phân giải nào đã trả lời. Một thiết bị rò rỉ ở một trong hai có thể trông hoàn toàn khỏe mạnh ở cái còn lại.