Nếu bạn thấy bất kỳ triệu chứng nào dưới đây ngay cả sau khi bật VPN, hãy nghi ngờ rò rỉ DNS hoặc rò rỉ WebRTC. Rò rỉ là khi thông tin được cho là đi qua đường dẫn VPN rời khỏi đường dẫn đó (còn gọi là rò rỉ).
- IP máy chủ VPN được hiển thị trên trang xác minh IP, nhưng máy chủ DNS của công ty viễn thông hoặc bộ định tuyến được hiển thị trong kiểm tra DNS.
- Địa chỉ IPv4 đã thay đổi nhưng địa chỉ IPv6 vẫn giữ nguyên như trước khi tắt VPN.
- Trên trang thử nghiệm WebRTC, IP công cộng xuất hiện như trước khi tắt VPN.
- IP gốc chỉ hiển thị ngay sau khi chuyển từ Wi-Fi sang dữ liệu di động hoặc thức dậy từ chế độ ngủ.
- Tôi đã bật StageVPN cho Chrome nhưng các trình duyệt và chương trình PC khác kết nối bằng IP gốc.
- Ngay cả khi bật VPN, trang web vẫn hiển thị ngôn ngữ và nội dung dựa trên khu vực ban đầu (điều này có thể là do cài đặt tài khoản/cookie).
Rò rỉ DNS là hiện tượng giao tiếp web đi qua đường hầm khi VPN được bật nhưng chỉ các truy vấn DNS đi ra ngoài đường hầm và tên miền hiển thị với máy chủ DNS của công ty viễn thông hoặc Wi-Fi. Rò rỉ WebRTC là hiện tượng trong đó WebRTC của trình duyệt gửi yêu cầu STUN trực tiếp ra khỏi VPN/proxy, cho phép trang web khám phá IP công cộng thực tế. Không có hiện tượng nào có nghĩa là nội dung trang bị rò rỉ. Tuy nhiên, nó tiết lộ 'ai đang truy cập ở đâu'. Bài viết này bắt đầu với các triệu chứng và tiến hành qua sáu giai đoạn chẩn đoán, giải quyết theo nguyên nhân và kiểm tra lại.
Chẩn đoán: Cách kiểm tra rò rỉ trong 6 bước
Nguyên tắc kiểm tra rò rỉ là so sánh các giá trị khi VPN bị tắt và khi VPN được bật. So sánh IP được hiển thị trên trang web, máy chủ đã nhận được truy vấn DNS và địa chỉ ứng viên WebRTC. Nếu các giá trị ban đầu vẫn hiển thị ngay cả sau khi bật VPN thì đó là rò rỉ. Việc kiểm tra chỉ có ý nghĩa trên các thiết bị và trình duyệt bạn thực sự sử dụng. Ngay cả khi bạn không có trang web kiểm tra cụ thể, bạn vẫn có thể kiểm tra hầu hết mọi thứ chỉ bằng cách sử dụng trình duyệt. Trang xác minh IP là trang web hiển thị địa chỉ IP công khai của người được kết nối trên màn hình. Bạn có thể tìm thấy nó trong công cụ tìm kiếm dưới dạng ‘Kiểm tra IP’. Tìm trang kiểm tra rò rỉ DNS và trang kiểm tra WebRTC theo cách tương tự. Nguyên tắc là như nhau cho dù bạn sử dụng trang nào, vì vậy bạn không cần phải dựa vào một trang cụ thể.
- Tắt VPN và ghi lại IP của bạn. Mở trang xác minh IP và ghi lại địa chỉ IPv4 công cộng và địa chỉ IPv6 nếu có. Giá trị này là cơ sở cho tất cả các so sánh tiếp theo.
- Bật VPN của bạn và so sánh IP. Sau khi kiểm tra chỉ báo hoàn thành kết nối trên ứng dụng StageVPN hoặc chỉ báo BẬT màu xanh lục trên biểu tượng StageVPN dành cho Chrome, hãy mở lại cùng một trang. IPv4 nên được thay thế bằng địa chỉ máy chủ VPN của bạn.
- Kiểm tra máy chủ DNS của bạn. Mở trang Kiểm tra rò rỉ DNS. Các trang này truy vấn các tên miền phụ ngẫu nhiên và sau đó hiển thị máy chủ DNS đã gửi truy vấn. Nếu bạn có thể thấy máy chủ của nhà cung cấp dịch vụ hoặc bộ định tuyến thì đó là rò rỉ DNS.
- Mở chrome://webrtc-internals. Nhập địa chỉ này vào thanh địa chỉ Chrome sẽ hiển thị các kết nối WebRTC đang diễn ra và địa chỉ ứng viên. Mục này sẽ xuất hiện nếu bạn mở trang thử nghiệm WebRTC hoặc trang cuộc gọi điện video trong tab khác.
- Kiểm tra IP ứng viên. Nếu địa chỉ của ứng cử viên srflx (phản ánh máy chủ) giống với IP công khai ban đầu ở bước 1 thì đó là rò rỉ WebRTC. Nếu đó là IP máy chủ VPN hoặc chỉ hiển thị tên .local và IP riêng thì IP công cộng sẽ không bị lộ.
- Kiểm tra IPv6. Nếu bạn có địa chỉ IPv6 ở bước 1, hãy bật VPN và xem địa chỉ đó đã biến mất hay thay đổi chưa. Nếu đúng như vậy thì IPv6 đang rời khỏi đường hầm. Chuyển đổi giữa Wi-Fi và dữ liệu di động, đồng thời lặp lại để xem kết quả có giống nhau sau khi khởi động lại trình duyệt hay không.
| Kết quả quan sát | nghĩa | Nguyên nhân tiếp theo |
|---|---|---|
| IP máy chủ VPN hiển thị trên trang web | Giao tiếp trên web đi qua đường dẫn VPN | Bình thường, bước tiếp theo |
| IPv4 đã thay đổi, nhưng IPv6 là địa chỉ gốc | IPv6 rời khỏi đường hầm | Nguyên nhân 2 |
| Máy chủ DNS đến từ công ty viễn thông hoặc bộ định tuyến. | rò rỉ DNS | Nguyên nhân 1, 3, 4, 5 |
| Máy chủ DNS là nhà cung cấp DNS công cộng | DNS trong cấu hình VPN của bạn hoặc DNS an toàn do bạn tự chỉ định. | Đừng cho rằng đó là rò rỉ chỉ dựa vào tên doanh nghiệp, hãy kiểm tra nguyên nhân 4 |
| IP công khai ban đầu hiển thị trong WebRTC | Rò rỉ WebRTC | Nguyên nhân 6 và 7 |
| Chỉ tên .local hoặc IP riêng mới hiển thị trong WebRTC | IP công cộng không bị lộ | nói chung là bình thường |
| IP gốc chỉ ngay sau khi chuyển mạng | khoảng cách tại thời điểm chuyển tiếp | Nguyên nhân 8 |
Kết quả có thể khác nhau tùy theo địa điểm thử nghiệm. Có những nơi chỉ xem IPv4 và những nơi xem IPv6 và các phương pháp tìm máy chủ DNS cũng khác nhau. So sánh ở nhiều nơi và bằng cách chuyển sang nhiều mạng.
Truy vấn DNS tiết lộ điều gì?
Truy vấn DNS chứa tên miền. Nội dung trang hoặc giá trị đã nhập không được bao gồm. DNS là hệ thống sổ địa chỉ của Internet có chức năng chuyển đổi tên miền được con người đọc thành địa chỉ IP được máy tính sử dụng. Mỗi khi bạn nhập một địa chỉ vào trình duyệt hoặc một ứng dụng liên hệ với máy chủ, trước tiên thiết bị của bạn sẽ hỏi máy chủ DNS 'địa chỉ của tên này là gì?' Vì vậy, chỉ cần nhìn vào lịch sử truy vấn, bạn có thể biết nhiều điều về thời điểm và dịch vụ nào bạn đã cố truy cập.
- thiết bị của tôiỨng dụng/Trình duyệt
- Truy vấn DNS văn bản thuần túy
- Wi-Fi công cộngbộ định tuyến quán cà phê
- Truy vấn DNS văn bản thuần túy
- DNS của nhà cung cấp dịch vụmáy chủ hiện có
- Các khu vực có thể bị lộ
- thiết bị của tôiỨng dụng/Trình duyệt
- DNS trong đường hầm
- Wi-Fi công cộngbộ định tuyến quán cà phê
- DNS trong đường hầm
- Máy chủ VPNStageVPN
- Truy vấn theo IP máy chủ VPN
- máy chủ DNSChỉ định trong cấu hình VPN
- Mã hóa VPN
Truy vấn DNS truyền thống đi tới cổng UDP 53 không được mã hóa. Để bù đắp cho điều này, DoH (RFC 8484), bao bọc các truy vấn trong HTTPS và DoT (RFC 7858), bao bọc các truy vấn trong TLS, đã được tạo. Tuy nhiên, ngay cả khi bạn sử dụng DNS được mã hóa, tên máy chủ (SNI) được gửi khi kết nối với một trang web qua HTTPS có thể hiển thị trên mạng nếu trang web và trình duyệt không hỗ trợ ECH (Xin chào máy khách được mã hóa).
| phương thức giao hàng | Người quan sát trên cùng một Wi-Fi | Công ty điều hành/truyền thông Wi-Fi | Máy chủ DNS nhận được truy vấn |
|---|---|---|---|
| DNS đơn giản (văn bản rõ ràng) | có thể nhìn thấy | có thể nhìn thấy | Hiển thị, với IP công cộng của tôi |
| DoH/DoT (DNS được mã hóa) | không thể nhìn thấy | Không hiển thị, địa chỉ máy chủ DNS hiển thị | Hiển thị, với IP công cộng của tôi |
| DNS bên trong đường hầm VPN | không thể nhìn thấy | Không hiển thị, chỉ thấy rằng nó đang liên lạc với máy chủ VPN | Hiển thị, với IP máy chủ VPN |
| tình trạng rò rỉ DNS | Nếu nó là văn bản đơn giản, bạn có thể nhìn thấy nó. | có thể nhìn thấy | Hiển thị, với IP công cộng của tôi |
DNS bảo mật (DoH) và VPN có các mục đích khác nhau. DoH chỉ mã hóa các truy vấn DNS; trang web tự truy cập và IP mà trang web nhìn thấy vẫn giữ nguyên. VPN mã hóa toàn bộ giao tiếp giữa thiết bị hoặc trình duyệt của bạn với máy chủ VPN và thay đổi IP mà các trang web nhìn thấy. Chế độ ẩn danh cũng không ngăn được rò rỉ. Chế độ ẩn danh là chức năng không để lại lịch sử hoặc cookie trên thiết bị và không thay đổi các truy vấn DNS hoặc tuyến WebRTC.
WebRTC xác định địa chỉ IP như thế nào?
WebRTC tìm địa chỉ riêng của mình theo nhiều cách để kết nối hai thiết bị thông qua đường dẫn ngắn nhất và chuyển kết quả tới tập lệnh trên trang web. WebRTC là công nghệ tiêu chuẩn web cho phép bạn thực hiện cuộc gọi video, cuộc gọi thoại và truyền tệp mà không cần plugin trong trình duyệt. Quá trình thu thập địa chỉ được gọi là ICE (RFC 8445). Ngay cả những trang không thực hiện cuộc gọi điện video cũng có thể bắt đầu quá trình này bằng một tập lệnh.
- Tạo đối tượng kết nốiTập lệnh trang web tạo RTCPeerConnection
- Tập hợp ứng viên địa phươngTrình duyệt của bạn thu thập địa chỉ các thiết bị mạng trên thiết bị của bạn
- Truy vấn STUNHỏi máy chủ STUN 'địa chỉ của tôi trông như thế nào' với UDP
- giao ứng viênDanh sách các ứng cử viên bao gồm các địa chỉ công cộng do máy chủ STUN cung cấp sẽ được gửi đến trang.
| Loại ứng viên | thứ gì đó | Thông tin có thể bị tiết lộ | Bảo vệ các trình duyệt gần đây |
|---|---|---|---|
| chủ nhà | Địa chỉ thiết bị mạng của máy | IP riêng (192.168.x, v.v.) | Được che giấu bằng tên .local ngẫu nhiên (mDNS), nhưng có thể được nhìn thấy trên các trang web đã cấp quyền cho máy ảnh và micrô. |
| srflx (phản ánh máy chủ) | Địa chỉ công khai của tôi được máy chủ STUN nhìn thấy | IP công cộng, IP thực nếu bạn bỏ qua proxy | Có thể bị hạn chế bởi chính sách xử lý IP của WebRTC |
| tiếp sức | TURN Địa chỉ của máy chủ chuyển tiếp | IP máy chủ chuyển tiếp | Nếu bạn sử dụng chuyển tiếp, bên kia sẽ thấy địa chỉ máy chủ thay vì IP của bạn. |
Vấn đề là ở truy vấn STUN ở bước 3. Proxy của trình duyệt chuyển tiếp các yêu cầu web nhưng giao tiếp UDP của WebRTC không đi qua proxy trong cài đặt mặc định của trình duyệt. Vì vậy, địa chỉ do máy chủ STUN cung cấp không phải là máy chủ proxy mà là IP công cộng ban đầu của tôi. Mọi thứ sẽ khác với VPN trên toàn thiết bị. Vì tất cả giao tiếp UDP, bao gồm cả các yêu cầu STUN, đều đi vào đường hầm, nên địa chỉ mà máy chủ STUN nhìn thấy cũng chính là IP của máy chủ VPN.
Proxy trình duyệt và chính sách mặc định
- Yêu cầu web đi qua proxy
- Yêu cầu STUN chuyển trực tiếp đến UDP
- Trang có thể thấy IP công cộng thực sự
Proxy trình duyệt và vô hiệu hóa_non_proxied_udp
- Ngăn chặn UDP đi qua proxy
- WebRTC chỉ sử dụng đường dẫn proxy
- Một số cuộc gọi có phương thức hoặc chất lượng kết nối khác nhau
VPN toàn thiết bị
- Yêu cầu STUN cũng đi qua đường hầm.
- Ứng cử viên địa chỉ công cộng là IP máy chủ VPN
- Việc ngắt kết nối và xử lý IPv6 yêu cầu xác nhận
Chrome có 'Chính sách xử lý IP WebRTC' xác định địa chỉ nào WebRTC sẽ sử dụng và các tiện ích mở rộng có thể thay đổi giá trị này. Mỗi giá trị tương ứng với bốn phương pháp được nêu trong Khuyến nghị xử lý địa chỉ IP WebRTC của IETF (RFC 8828).
| giá trị chính sách | sự chuyển động | phạm vi tiếp xúc |
|---|---|---|
| mặc định | Thu thập ứng viên từ tất cả các thiết bị mạng | Rộng nhất (địa chỉ cục bộ được mDNS che dấu) |
| default_public_and_private_interfaces | Chỉ sử dụng các thiết bị trên tuyến mặc định, sử dụng cả địa chỉ công khai và riêng tư | Không để lộ địa chỉ của các thiết bị khác |
| mặc định_public_interface_only | Chỉ sử dụng địa chỉ công cộng của tuyến đường mặc định | Địa chỉ riêng tư không bị lộ |
| vô hiệu hóa_non_proxied_udp | Không có UDP thông qua proxy, sử dụng TCP thông qua proxy nếu proxy không hỗ trợ UDP | Không để lộ địa chỉ của các tuyến đường bên ngoài proxy |
Giải pháp: Cách kiểm tra và khắc phục theo nguyên nhân
Hầu hết các rò rỉ đều có một trong tám nguyên nhân: Điều này thường xảy ra do cài đặt chồng chéo. Bắt đầu bằng cách kiểm tra số nguyên nhân được chỉ ra trong bảng chẩn đoán và mỗi lần bạn sửa một nguyên nhân, hãy lặp lại bước 6 trong hình trên để xem kết quả có thay đổi hay không. Nếu bạn thay đổi nhiều cài đặt cùng một lúc, bạn sẽ không biết cài đặt nào hiệu quả.
Nguyên nhân 1 · Không có máy chủ DNS trong cấu hình VPN hoặc thiết bị sử dụng DNS khác.
kiểm tra Khi VPN được bật, quá trình kiểm tra DNS sẽ hiển thị bộ định tuyến Wi-Fi hoặc máy chủ DNS của nhà cung cấp dịch vụ. Bạn thường có DNS thủ công trong cài đặt Wi-Fi của thiết bị.
gỡ rối Ứng dụng StageVPN bao gồm máy chủ DNS trong cấu hình VPN và gửi truy vấn vào đường hầm. Hoàn nguyên DNS thủ công về tự động trong cài đặt mạng của thiết bị, sau đó ngắt kết nối và kết nối lại với VPN. Nếu sự cố vẫn như cũ, hãy kiểm tra nguyên nhân 3 và 5.
Nguyên nhân 2 IPv6 đi ra khỏi đường hầm
kiểm tra IPv4 đã được thay đổi thành địa chỉ máy chủ VPN, nhưng IPv6 vẫn giữ nguyên giá trị được ghi ở bước 1. Nếu VPN chỉ chuyển đổi IPv4 thì các truy vấn và liên lạc IPv6 sẽ đi theo lộ trình ban đầu.
gỡ rối Ứng dụng StageVPN cũng được định cấu hình để gửi thông tin liên lạc IPv6 đến đường hầm (AllowedIPs 0.0.0.0/0, ::/0), do đó thường không cần phải tắt ứng dụng này. Nếu IPv6 vẫn xuất hiện như bình thường, trước tiên hãy kiểm tra xem liệu cài đặt thiết bị hoặc ứng dụng VPN khác có đang thay đổi tuyến đường hay không. Một số trang web thử nghiệm không hỗ trợ IPv6, vì vậy hãy so sánh ở nhiều trang web.
Nguyên nhân 3 · Hệ điều hành truy vấn DNS của nhiều thiết bị mạng cùng một lúc.
kiểm tra Đặc biệt là trong quá trình kết nối VPN trên PC Windows, quá trình kiểm tra DNS sẽ hiển thị cả DNS của VPN và DNS của nhà cung cấp dịch vụ của bạn. Điều này là do một tính năng yêu cầu đồng thời tất cả các thiết bị mạng, chẳng hạn như Độ phân giải tên nhiều nhà thông minh của Windows.
gỡ rối Luôn cập nhật hệ điều hành và phần mềm VPN của bạn và lặp lại thử nghiệm. Hiện tượng này chủ yếu được báo cáo với VPN trên toàn thiết bị trên PC và không xảy ra theo cách tương tự trên ứng dụng StageVPN trên điện thoại thông minh và StageVPN dành cho Chrome trên Chrome do cấu trúc khác nhau.
Nguyên nhân 4 · DNS an toàn (DoH) được chỉ định riêng trong trình duyệt hoặc thiết bị
kiểm tra Kiểm tra DNS hiển thị các máy chủ từ các nhà cung cấp DNS công cộng. Trong trường hợp này, đó có thể không phải là rò rỉ mà là cài đặt do bạn tự chỉ định. Nếu bạn có VPN trên toàn thiết bị, truy vấn này cũng sẽ đi qua đường hầm nhưng nhà cung cấp được chỉ định sẽ nhận thay vì DNS trong cấu hình VPN của bạn.
gỡ rối Nếu đây là cài đặt dự định, bạn có thể để nguyên như vậy. Nếu bạn muốn sử dụng DNS cho cấu hình VPN của mình, nó sẽ tự động thay đổi cài đặt DNS an toàn trên trình duyệt và thiết bị của bạn. Điều quan trọng là không được cho rằng đó là sự rò rỉ thông tin chỉ bằng cách nhìn vào tên doanh nghiệp.
Nguyên nhân 5 · Các ứng dụng VPN, proxy và bảo mật khác cũng được bật
kiểm tra Tính năng mạng của các ứng dụng VPN, tiện ích mở rộng proxy, bộ lọc quảng cáo hoặc chương trình bảo mật khác được bật cùng lúc. Cài đặt tuyến đường ghi đè lên nhau, khiến một số truy vấn chuyển về tuyến đường ban đầu.
gỡ rối Mỗi lần chỉ bật một cái. Tắt các ứng dụng và tiện ích mở rộng khác, ngắt kết nối và kết nối lại StageVPN rồi lặp lại bước 6. Cài đặt proxy của Chrome chỉ có thể kiểm soát một tiện ích mở rộng tại một thời điểm, vì vậy nếu một tiện ích mở rộng khác đang sử dụng proxy thì StageVPN dành cho Chrome sẽ không kết nối và sẽ cho bạn biết lý do.
Nguyên nhân 6 · Chỉ sử dụng proxy trình duyệt nhưng dự kiến sẽ có giao tiếp bên ngoài trình duyệt
kiểm tra Tôi đã bật StageVPN cho Chrome nhưng các trình duyệt, trình nhắn tin trên PC và chương trình thư khác kết nối bằng IP gốc và DNS gốc. Đây không phải là rò rỉ, đây là phạm vi được thiết kế. Tiện ích mở rộng chỉ bao gồm giao tiếp trong Chrome.
gỡ rối Nếu bạn cần bảo vệ các chương trình bên ngoài Chrome, hãy sử dụng VPN áp dụng cho toàn bộ thiết bị. Trên điện thoại thông minh, ứng dụng StageVPN thực hiện được điều đó. Sự khác biệt về phạm vi giữa hai phương pháp là VPN trình duyệt và VPN ứng dụngTôi đã tổ chức nó ở định dạng .
Nguyên nhân 7 chính sách WebRTC không được áp dụng
kiểm tra Tôi đã bật StageVPN cho Chrome và tôi có thể thấy IP công khai ban đầu trong thử nghiệm WebRTC hoặc trong ứng cử viên srflx trong chrome://webrtc-internals. Nếu tiện ích mở rộng khác hoặc chính sách quản lý của công ty/tổ chức kiểm soát cài đặt WebRTC trước tiên thì StageVPN dành cho Chrome sẽ không thay đổi chính sách và sẽ giữ nguyên chính sách đó.
gỡ rối Tắt mọi tiện ích mở rộng khác kiểm soát cài đặt WebRTC và kết nối lại StageVPN cho Chrome. Nếu chính sách quản lý là nguyên nhân, hãy liên hệ với quản trị viên của bạn. Để viết trong cửa sổ ẩn danh, bạn phải bật 'Cho phép ở chế độ ẩn danh' trong màn hình quản lý tiện ích mở rộng. Khi tắt, thông tin liên lạc trong cửa sổ ẩn danh sẽ không đi qua proxy.
Nguyên nhân 8 · Thời điểm mất kết nối VPN
kiểm tra IP gốc chỉ hiển thị ngay sau khi chuyển mạng hoặc thức dậy từ chế độ ngủ và sau một thời gian thì bình thường. Trong quá trình ngắt kết nối, tất cả các truy vấn và thông tin liên lạc sẽ đi theo lộ trình thông thường.
gỡ rối Trước khi thực hiện bất kỳ công việc nhạy cảm nào, hãy kiểm tra xem chỉ báo hoàn thành kết nối của ứng dụng hoặc biểu tượng tiện ích mở rộng có BẬT hay không. WireGuard, được ứng dụng StageVPN sử dụng, không thiết lập lại đường hầm ngay cả khi thay đổi từ Wi-Fi sang LTE, nhưng giao thức không thể bù đắp cho việc ngắt kết nối tạm thời trong mạng. Khả năng tự động chặn liên lạc khi VPN bị ngắt kết nối không phải là tính năng do StageVPN cung cấp. Nguyên tắc là Giải thích nguyên tắc của WireGuardNó ở trong
Làm cách nào để ứng dụng StageVPN và StageVPN dành cho Chrome ngăn chặn rò rỉ?
Ứng dụng StageVPN giảm rò rỉ bằng cách tạo đường hầm cho tất cả giao tiếp, trong khi StageVPN dành cho Chrome tra cứu tên proxy và điều chỉnh các chính sách WebRTC. Vì phạm vi bảo vệ là khác nhau nên cách xử lý cũng khác nhau.
| mục | Ứng dụng StageVPN (iPhone·iPad·Android) | StageVPN dành cho Chrome |
|---|---|---|
| phạm vi bảo vệ | Tất cả các thiết bị | Trình duyệt Chrome |
| Thông tin liên lạc được gửi qua tuyến VPN | IPv4·IPv6 Tất cả (AllowedIPs 0.0.0.0/0, ::/0) | Yêu cầu web đi qua proxy (không bao gồm các dải IP riêng và localhost) |
| truy vấn DNS | Chuyển tiếp trong đường hầm tới máy chủ DNS được chỉ định trong cấu hình VPN. | Các yêu cầu đi qua proxy không được Chrome tra cứu mà bởi máy chủ proxy. |
| WebRTC | Tất cả các giao tiếp UDP đều đi qua đường hầm. | vô hiệu hóa_non_proxied_udp được áp dụng trong khi kết nối và trở về cài đặt ban đầu khi bị ngắt kết nối. |
| Những gì bạn hiện thấy trên mạng | Thực tế là có giao tiếp được mã hóa với máy chủ VPN và lượng dữ liệu | Tra cứu tên của địa chỉ máy chủ proxy, kết nối được mã hóa với proxy và thông tin liên lạc từ các ứng dụng bên ngoài Chrome |
| Những trường hợp có thể không áp dụng | Trong khi kết nối VPN bị mất, khi một ứng dụng VPN khác định tuyến lại | Cửa sổ ẩn danh có chế độ Cho phép ẩn danh bị tắt khi tiện ích mở rộng hoặc chính sách quản lý khác kiểm soát cài đặt proxy/WebRTC |
| Lịch sử truy cập (93 ngày) | Tên miền đã xem không được ghi lại | Tên máy chủ đích được kết nối được ghi lại nhưng đường dẫn hoặc cụm từ tìm kiếm không được ghi lại. |
StageVPN không hướng dẫn bạn qua menu cài đặt bảo vệ rò rỉ DNS riêng biệt như một tính năng của các dịch vụ của nó. Hành vi trên phụ thuộc vào cấu hình VPN mặc định của ứng dụng và phương thức kết nối của tiện ích mở rộng. Phạm vi cung cấp là Tính năng và phạm vi cung cấpBạn có thể kiểm tra nó ở đây.
Không có rò rỉ có nghĩa là các truy vấn và thông tin liên lạc đi qua đường dẫn VPN thay vì nhà cung cấp dịch vụ. Điều này không có nghĩa là sẽ không có hồ sơ nào được lưu giữ. StageVPN lưu giữ hồ sơ truy cập trong 93 ngày theo Đạo luật bảo vệ bí mật liên lạc và không ghi lại nội dung liên lạc. Mục này là Truy cập thông báo lưu trữ hồ sơVâng, lý do tôi tiết lộ nó là Tại sao chúng tôi tiết lộ chính sách lưu giữ hồ sơ truy cập của mình?giải thích.
Kiểm tra lại danh sách kiểm tra: Bạn kiểm tra lại những gì sau khi thực hiện thay đổi?
Mỗi lần bạn khắc phục một nguyên nhân, hãy kiểm tra lại các mục bên dưới từ đầu. Nếu tất cả đều vượt qua, không có rò rỉ. Nếu bất kỳ mục nào bị lỗi, nó sẽ quay trở lại thẻ nguyên nhân tương ứng.
- Sau khi ngắt kết nối và kết nối lại VPN, tôi đã kiểm tra xem ứng dụng có hiển thị hoàn thành kết nối hay biểu tượng mở rộng hiển thị BẬT hay không.
- Trên trang xác minh IP, bạn sẽ thấy địa chỉ máy chủ VPN cho cả IPv4 và IPv6 hoặc bạn sẽ không thấy IPv6.
- Kiểm tra DNS không hiển thị máy chủ DNS của công ty viễn thông hoặc bộ định tuyến.
- Ứng cử viên srflx trong chrome://webrtc-internals không có IP công khai ban đầu.
- Tính năng mạng của các ứng dụng VPN, proxy/tiện ích mở rộng VPN và chương trình bảo mật khác đều bị tắt.
- Nếu bạn đã đặt DNS thủ công hoặc DNS an toàn cho thiết bị và trình duyệt của mình, bạn đã xác minh rằng đây là cài đặt dự định.
- Hệ điều hành, trình duyệt cũng như các ứng dụng và tiện ích mở rộng StageVPN của bạn đã được cập nhật.
- Kết quả tương tự ngay cả sau khi chuyển đổi giữa Wi-Fi và dữ liệu di động và khởi động lại trình duyệt.
- Nếu cần bảo vệ các chương trình bên ngoài Chrome, bạn có thể sử dụng VPN trên toàn thiết bị thay vì tiện ích mở rộng.
Bạn cũng nên xác định khi nào cần kiểm tra lại. Đó là sau khi có bản cập nhật lớn cho hệ điều hành hoặc trình duyệt của bạn, sau khi cài đặt tiện ích mở rộng hoặc ứng dụng bảo mật mới hoặc trước khi thực hiện bất kỳ công việc nhạy cảm nào trên mạng mà bạn kết nối lần đầu tiên. Nếu cài đặt giống nhau nhưng kết quả đã thay đổi thì một trong ba điều sau thường là nguyên nhân. Khi bạn đã hiểu rõ, 6 giai đoạn chẩn đoán có thể được hoàn thành chỉ sau vài phút.
Nếu sự cố vẫn tiếp diễn, hãy sắp xếp kiểu thiết bị, hệ điều hành và phiên bản ứng dụng, thời gian xảy ra và kết quả kiểm tra. hỗ trợ khách hàngVui lòng liên hệ với chúng tôi. Vui lòng không gửi mật khẩu hoặc mã xác minh của bạn. Các cài đặt thiết bị cần được kiểm tra cùng với việc kiểm tra rò rỉ là: 10 cài đặt quyền riêng tư trên điện thoại thông minhChà, có những rủi ro không thể giải quyết chỉ bằng VPN. Những gì VPN ngăn chặn và không thể ngăn chặnChà, thói quen của bạn trên mạng công cộng là Quy tắc an toàn Wi-Fi công cộngTôi đã tổ chức nó ở định dạng .
tài liệu tham khảo
- RFC 1034: Tên miền - Khái niệm và tiện ích — Cấu trúc DNS và vai trò của trình phân giải (IETF)
- RFC 8484: Truy vấn DNS qua HTTPS (DoH) — Cách mã hóa truy vấn DNS qua HTTPS (IETF)
- RFC 7858: DNS qua TLS — Cách mã hóa truy vấn DNS bằng TLS (IETF)
- RFC 8445: Thiết lập kết nối tương tác (ICE) - Các loại ứng cử viên kết nối WebRTC và quy trình thu thập (IETF)
- RFC 8828: Yêu cầu xử lý địa chỉ IP WebRTC — Phạm vi địa chỉ mà trình duyệt hiển thị cho WebRTC (IETF)
- API chrome.privacy — Giá trị chính sách xử lý IP WebRTC của Chrome (Chrome dành cho nhà phát triển)
- API chrome.proxy — Cài đặt proxy tiện ích mở rộng, danh sách bỏ qua và mức độ ưu tiên kiểm soát (Chrome dành cho nhà phát triển)
- API WebRTC — RTCPeerConnection và khái niệm về ứng viên ICE (MDN Web Docs)
