Rủi ro dùng chung IP cho nhiều tài khoản

Phong ở Bình Dương có một gian TikTok Shop, ba gian Shopee, thêm hai fanpage và một Zalo OA để chăm khách sỉ. Cả nhóm bốn người ngồi chung văn phòng, dùng chung một đường wifi, nên mọi thao tác đều đi ra từ một địa chỉ IP công cộng. Hôm thứ Sáu tuần trước, một gian Shopee bị hạn chế đăng bán. Phong còn đang lo xử lý cái đó thì hôm sau gian thứ hai bị yêu cầu xác minh, rồi fanpage cũng đòi xác nhận danh tính. "Mình tưởng lỗi tại một shop thôi, ai ngờ dây sang hết", anh kể, giọng mệt mỏi vì đơn cuối tuần vẫn còn chất đống.

Không phải ngẫu nhiên mà các thông báo đến gần nhau như vậy. Sau khi gắn mỗi hồ sơ một tuyến mạng riêng trên BitBrowser, mấy gian hàng của Phong không còn đi chung một địa chỉ nữa, và nhóm cũng tranh thủ soát lại múi giờ, DNS lẫn WebRTC cho từng môi trường. Để hiểu vì sao một địa chỉ dùng chung lại kéo theo cả chuỗi, cần nhìn vào cách nền tảng tổ chức dữ liệu phiên đăng nhập.

Một địa chỉ, nhiều danh tính: quy trình kiểm tra đọc được gì

Mỗi lần bạn đăng nhập, phía máy chủ thường ghi lại một bản ghi khá đơn giản: địa chỉ IP, thời điểm, mã tài khoản, mã thiết bị hoặc mã phiên, đôi khi kèm vài thông số của trình duyệt. Bản ghi tự nó vô hại. Điều đáng chú ý là khi nhiều bản ghi được xếp cạnh nhau, một địa chỉ xuất hiện lặp đi lặp lại trên nhiều mã tài khoản, trong những khung giờ sát nhau, sẽ trở thành một điểm nối rất dễ thấy.

Bảng trên chỉ là cách hình dung, không phải công thức của riêng nền tảng nào. Nhưng nó giải thích được cảm giác "dây sang hết" của Phong: khi đã có một điểm nối mạng, hệ thống có thêm lý do để đọc kỹ hơn các tín hiệu còn lại của những tài khoản đi cùng điểm đó.

Từ một địa chỉ đến một đồ thị: cơ chế suy luận ở tầng dữ liệu

Kỹ thuật thường được mô tả dưới dạng đồ thị. Mỗi tài khoản, mỗi thiết bị, mỗi địa chỉ IP là một nút; hai nút được nối với nhau khi chúng cùng xuất hiện trong một phiên. Cạnh nối có trọng số, và trọng số tăng lên khi có thêm tín hiệu trùng: cùng IP, cùng thiết bị, cùng khung giờ, cùng chuỗi thao tác. Một quy trình đánh giá vì thế không hỏi "IP này có từng bị ghi nhận không", mà hỏi "cụm tài khoản này có mức tương đồng bao nhiêu so với phần còn lại". Đây là lý do nên nói về mức độ rủi ro thay vì những kết luận chắc chắn.

Cần nói thêm một điều cho công bằng: dùng chung IP là chuyện hết sức bình thường. Nhà mạng di động dùng CGNAT gom hàng ngàn thuê bao qua một cổng ra, quán cà phê, ký túc xá, tòa nhà văn phòng đều vậy, và IPv6 chưa phủ tới mọi hạ tầng ở Việt Nam. Các nền tảng hiểu điều đó, nên một địa chỉ dùng chung hiếm khi tự nó đủ để quyết định. Vấn đề chỉ trở nên rõ khi nó đi cùng những điểm trùng khác – chính là phần mà người vận hành có thể chủ động tách ra.

Ngược lại cũng đáng lưu ý: đổi IP mà giữ nguyên mọi thứ khác thì hiệu quả rất hạn chế. Cùng font, cùng Canvas, cùng WebGL, cùng thư mục cookie, chỉ khác mỗi địa chỉ – điểm nối mạng đã đứt nhưng điểm nối thiết bị vẫn còn nguyên. Đây là lý do các bài phân tích về VPN và về cấu trúc hồ sơ đều đi đến cùng một kết luận: tách phải tách đồng bộ, một mình lớp mạng không gánh hết.
Ai làm việc với dữ liệu có thể hình dung khâu gom nhóm qua một truy vấn kiểu này trên chính hệ thống nhật ký nội bộ của mình:

-- Đối chiếu các tài khoản cùng xuất hiện trên một địa chỉ
-- trong cùng khung giờ (chỉ minh họa cấu trúc, chạy trên log nội bộ)
SELECT ip,
      COUNT(DISTINCT account_id)  AS so_tai_khoan,
      MIN(login_at)               AS luc_dau,
      MAX(login_at)               AS luc_cuoi
FROM   login_sessions
WHERE  login_at >= NOW() - INTERVAL '1 day'
GROUP  BY ip
HAVING COUNT(DISTINCT account_id) > 1
ORDER  BY so_tai_khoan DESC;

Đoạn truy vấn không có gì bí hiểm: nó chỉ đếm xem một địa chỉ đang phục vụ bao nhiêu mã tài khoản trong ngày. Chạy định kỳ trên nhật ký của chính đội mình là cách đơn giản để phát hiện sớm chỗ đang dùng chung, trước khi phải đợi thông báo từ nền tảng. Với nhóm có quy trình tự động hóa, bước này có thể nối tiếp qua Local API để cập nhật lại danh sách hồ sơ cần tách tuyến.

Tác động khác nhau ở từng nhóm người dùng

Tách tuyến mà vẫn giữ cho các tham số khớp nhau

Với trường hợp của Phong, phần việc không nằm ở việc mua thêm bao nhiêu địa chỉ, mà ở chỗ mỗi địa chỉ phải đi cùng đúng hồ sơ của nó. Bảng dưới là phần đối chiếu trước và sau khi dọn lại.

1. Lập bảng đối soát: mã gian hàng – hồ sơ – tuyến mạng – người phụ trách – ngày bắt đầu dùng.
2. Gán từng proxy vào đúng một hồ sơ, bấm kiểm tra kết nối và đối chiếu ASN, vị trí với kỳ vọng.
3. Bật đồng bộ múi giờ, ngôn ngữ và vùng theo IP, rồi tắt các thiết lập thủ công đang chồng chéo.
4. Soát rò rỉ DNS và WebRTC. Đây là hai chỗ hay sót nhất khi lưu lượng đã đi qua proxy nhưng trình duyệt chưa được cấu hình đúng.
5. Dọn sạch cookie và bộ nhớ đệm cũ; mỗi hồ sơ chỉ đăng nhập một tài khoản.
6. Bật xác thực hai yếu tố cho hồ sơ, chạy lại truy vấn đối chiếu ở trên sau một tuần để xem còn điểm nối nào.

Với mảng chạy trên app, lớp thiết bị cũng cần tách tương tự. Điện thoại đám mây của BitBrowser cho phép mỗi môi trường giữ bộ thông số SIM, nhà mạng, cảm biến và tuyến mạng riêng; một số nền tảng đọc tín hiệu di động kỹ hơn hẳn trình duyệt web, nên chỉ tách IP trên PC là chưa đủ. Các sản phẩm trong nước như GPMlogin, GenLogin hay Hidemyacc cũng đều hỗ trợ gán proxy theo hồ sơ – điểm khác biệt nằm ở việc bên nào làm sẵn khâu đồng bộ múi giờ, đối chiếu kết nối và mở rộng sang thiết bị di động trong cùng một tài khoản.

Dùng chung IP tự nó là chuyện bình thường; rủi ro tăng lên khi nó đi cùng thiết bị, cookie và nhịp thao tác giống nhau. Một hệ thống đánh giá thường làm việc theo mức độ tương đồng trong một đồ thị, nên không có cấu hình nào cho kết quả như nhau trong mọi trường hợp – chỉ có cách giảm bớt các điểm nối không cần thiết. Và tách tuyến phải đi kèm đồng bộ tham số, nếu không thì đứt một cạnh mà cạnh khác vẫn còn.

AI có thể gánh phần soát lặp lại: một trợ lý kết nối qua MCP đọc nhật ký, phát hiện hai hồ sơ vừa cùng đi qua một địa chỉ, nhắc khi có proxy đổi nhưng múi giờ chưa cập nhật, hoặc tóm tắt những cụm tài khoản có mức tương đồng tăng bất thường. Hệ sinh thái AI trong nước đang lớn nhanh, và lớp kiểm tra chủ động này sẽ có giá trị hơn nhiều so với việc chờ đến lúc có thông báo rồi mới dò ngược. Còn với Phong, thay đổi có ích nhất hóa ra lại rất giản dị: ngồi xuống đặt tên lại từng hồ sơ, ghi rõ ai phụ trách cái nào. Từ hôm đó, câu hỏi không còn là "sao lại dây sang hết" nữa.