Làm thế nào dễ dàng để phát hiện VPN đang được sử dụng?

Mạng riêng ảo (VPN) giải quyết rất nhiều vấn đề riêng tư. Vì VPN thường mã hóa lưu lượng giữa máy tính của bạn và nhà cung cấp VPN, nên người quan sát rất khó xem lưu lượng của bạn để xem bạn đang làm gì. Tuy nhiên, có nhiều người muốn có thể che giấu sự thật rằng họ đã sử dụng VPN; chẳng hạn như những người ở các quốc gia cấm VPN hoặc các tình huống khác trong đó việc sử dụng VPN thường không được phép hoặc bị chặn thông qua các phương tiện kỹ thuật. Trong bài viết này, chúng tôi tập trung vào loại dữ liệu mà người quan sát có thể thu thập từ các gói chụp mạng và cách sử dụng dữ liệu đó để phát hiện sử dụng VPN.

Bối cảnh của vấn đề

Câu hỏi hóc búa là tại sao vì sao? Ai quan tâm nếu ai đó phát hiện ra bạn đang chạy VPN? Nếu lưu lượng được mã hóa mạnh bằng mọi cách, thì vấn đề là gì?

Điều đó đúng là trong nhiều tình huống và ở nhiều quốc gia, điều đó hoàn toàn không thành vấn đề nếu một người quan sát phát hiện ra việc sử dụng VPN. Tuy nhiên, có nhiều quốc gia cấm sử dụng VPN và điều đó rất quan trọng đối với người dùng VPN ở những quốc gia đó để biết cách phát hiện ra chúng.

Để xác định xem VPN có được sử dụng hay không, người quan sát phải có quyền truy cập vào bộ định tuyến mà lưu lượng đích đang đi qua. Trong trường hợp nạn nhân bị nhắm mục tiêu, kẻ tấn công có thể sử dụng các nguồn lực lớn để xác định cách thức chiếm lấy bộ định tuyến mà nạn nhân cụ thể sử dụng. Trong trường hợp giám sát nhà nước quốc gia, phát hiện hiệu quả sẽ yêu cầu kiểm soát rất nhiều bộ định tuyến. Khi bạn kết hợp hai thứ đó, một tổ chức quan tâm nếu bạn sử dụng và VPN và cũng có khả năng điều khiển một số lượng lớn các bộ định tuyến, thường chỉ ra một tác nhân đe dọa cấp quốc gia.

Hãy nhớ rằng bài viết này đề cập đến các cách thức sử dụng VPN có thể được phát hiện bởi các nhà quan sát. Điều đó không nhất thiết có nghĩa là dữ liệu được mã hóa trong đường hầm VPN dễ khai thác hơn.

Phương pháp kiểm tra

Không có quyền truy cập vào tài nguyên cấp nhà nước, nền tảng và phương pháp thử nghiệm của tôi có quy mô nhỏ hơn một chút. Tôi đã tạo một mạng nội bộ nhỏ bằng ba Máy ảo (VM) với VirtualBox. Cấu trúc liên kết mạng là như vậy:

Tôi đã cài đặt phần mềm đánh hơi gói trên VM bộ định tuyến OpenWRT và sau đó thử nghiệm các cấu hình VPN khác nhau trên hai máy ảo khác. Phần mềm đánh hơi gói tin, tcpdump, cho phép tôi nắm bắt lưu lượng mạng VM để phân tích. Trong một thiết lập thực tế hơn, phần mềm chụp gói có thể sẽ được cài đặt trong các bộ định tuyến trên Internet, hoặc ít nhất là trong mạng ISP ISP. Vị trí chiến lược của phần mềm phân tích sẽ đòi hỏi một số kiến ​​thức về các điểm hội tụ quan tâm trên internet nơi lưu lượng truy cập mục tiêu có khả năng chảy. Trong mạng thử nghiệm của tôi, tôi biết chắc chắn 100% rằng tất cả lưu lượng truy cập đến và từ các máy ảo của tôi sẽ đi qua bộ định tuyến OpenWRT đó. Do đó, nó là nơi tốt nhất để tôi đặt các công cụ thu thập của mình.

Nguồn phi kỹ thuật của các chỉ số VPN

Không phải tất cả các nguồn dữ liệu cho thấy việc sử dụng VPN là kỹ thuật. Trong khi một số rất kỹ thuật, chẳng hạn như phân tích gói, một số rất phi kỹ thuật, chẳng hạn như lỗi của con người và thói quen hàng ngày.

Lưu lượng truy cập mạng ngoài ý muốn

Hầu hết người dùng VPN có phần mềm máy khách phải được khởi chạy để VPN được thiết lập. Nó rất khó để đảm bảo rằng không có lưu lượng truy cập qua internet trước khi VPN được thiết lập khi máy tính khởi động. Ngay cả những VPN có khóa chuyển đổi có thể không thể làm bất cứ điều gì về lưu lượng đi qua trong khi khởi động hệ thống.

Để kiểm tra điều này, tôi đặt các tùy chọn chuyển đổi tự động kết nối và tắt của VyprVPN trong máy ảo Windows. Sau đó tôi tắt máy Windows, bắt đầu chụp gói trên bộ định tuyến OpenWRT và khởi động máy Windows. Điều đó tạo ra rất nhiều gói và quan tâm là hai chuỗi này.

Đầu tiên, chúng ta có thể thấy rất nhiều ping đến một dải IP tương tự. Tôi không cố tình nhóm các gói này – đây là cách chúng được gửi hữu cơ:

Điều này cho thấy rằng một cái gì đó đang cố gắng liệt kê các máy chủ. Một nguyên nhân rất phổ biến của loại lưu lượng này trong kịch bản VPN là máy khách VPN cố gắng xác định máy chủ nhanh nhất. Một phương pháp để thực hiện việc này là gửi gói ICMP (được gọi là ping) đến một bộ máy chủ để xem cái nào quay lại nhanh nhất.

Chúng ta có thể thấy từ ảnh chụp màn hình đầu tiên rằng 209,99,63,34 đã trả về nhanh nhất trong 99 mili giây. Xa hơn trong việc chụp gói, chúng tôi đột nhiên thấy rằng hầu hết lưu lượng truy cập từ thời điểm đó trở đi được mã hóa và được dành cho 209,99.63.34

Phần tiếp theo của câu đố là tìm hiểu những gì ở các IP đó. Sử dụng IP WHOIS, trong đó nêu rõ chủ sở hữu đã đăng ký của IP, chúng ta có thể thấy rằng tất cả trừ một trong số các IP này thuộc về Tập đoàn YHC và giải quyết các máy chủ trong trung tâm dữ liệu của Found Foundry:

209,99.108,46
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99.109.167
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99.113,70
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209-99-115-97
209,99.117.82
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,21,36
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
OrgTechEmail: [email protected]
209,99,22,46
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,60,34
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,61,42
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,62,34
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
OrgName: Quản lý nhà máy điện, Inc.
OrgTechEmail: [email protected]
209,99,63,34
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,63,34
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,67,41
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,72,70
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,75,70
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,93,34
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,94,37
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]
209,99,95,40
OrgName: Tập đoàn YHC
OrgTechEmail: [email protected]

Bước tiếp theo hợp lý sẽ là quét các IP đó để xem chúng đang chạy dịch vụ nào. Tôi đã giành được thông tin chi tiết về cách cung cấp, nhưng thử nghiệm của tôi cho thấy các biểu ngữ kết nối mặc định mà hầu hết các máy chủ hiển thị đã bị xóa khỏi máy chủ VyprVPN, do đó, không có thông tin rõ ràng nào về việc các IP này đang chạy máy chủ VPN.

Có rất nhiều điều bạn có thể làm về cách thức hoạt động của máy tính trước khi khởi động. Do đó, nếu bạn muốn làm xáo trộn loại trình tự thiết lập này, bạn sẽ cần phải chạy một VPN VPN ở phía trước máy tính của bạn. Chạy máy khách VPN trên bộ định tuyến của bạn thay vì chạy máy khách trên máy tính của bạn là một cách để làm điều này. Bạn vẫn sẽ chạy vào cùng một chuỗi khởi động khi bộ định tuyến khởi động lại, nhưng điều đó thường ít hơn so với máy tính của bạn.

Không có gói không được mã hóa

Như tôi đã đề cập ở trên, một khi các lệnh ping hoàn tất, việc chụp gói cho thấy lưu lượng được mã hóa đến IP nhanh nhất. Nếu một người quan sát chỉ nhìn thấy các gói được mã hóa và không phải là một gói không được mã hóa, đó có thể là dấu hiệu có VPN đang được sử dụng. Mặc dù thế giới đang nhanh chóng hướng tới việc mã hóa càng nhiều dữ liệu càng tốt trên web, nhưng vẫn có một số yêu cầu thường không được mã hóa. Trong số này có các truy vấn tra cứu DNS, truy vấn NNTP (máy chủ thời gian) và phân tán các yêu cầu giao thức khác như FTP và Telnet đôi khi được sử dụng trong một số ứng dụng của chúng tôi, nhưng hoàn toàn không hỗ trợ mã hóa.

Rò rỉ từ bảo mật hoạt động cẩu thả của con người (OpSec)

Rất nhiều dữ liệu có ý nghĩa có thể thu được từ một mục tiêu bằng cách sử dụng thông tin có vẻ tầm thường. Nhiều người dành rất nhiều thời gian và nỗ lực để giảm thiểu những gì họ cảm nhận là những thứ quan trọng của YouTube chỉ được xác định bằng thông tin tầm thường mà họ không nghĩ tới. Một số ví dụ bao gồm bộ nhớ dài về internet tiết lộ quản trị viên email Hillary Clinton, rất có thể là một chàng trai tên Paul Combetta; Dread Pirate Roberts, AKA Ross Ulbricht, kẻ được cho là chủ mưu của thị trường internet Silk Road bất hợp pháp, đã bị truy tố phần lớn do dữ liệu trên máy tính xách tay của anh ta được lấy từ anh ta trong khi bị phân tâm tại một thư viện công cộng.

Ít kịch tính hơn, người quan sát có thể thường xuyên sử dụng những thứ như chu kỳ hoạt động để xác định múi giờ mục tiêu hoặc sự hiện diện của các ký tự đặc biệt trong thông báo để xác định bố cục ngôn ngữ tương ứng với quốc gia mục tiêu. Không có danh sách đầy đủ những điều cần tính đến khi xem xét bảo mật hoạt động bởi vì đưa ra những cách mới để dữ liệu tham chiếu chéo chủ yếu là một bài tập về trí tưởng tượng và tài nguyên.

Tuy nhiên, có một số điều cụ thể liên quan đến việc bắt gói có thể xác định việc sử dụng VPN.

Dấu hiệu nhận biết từ siêu dữ liệu gói

Các khóa lại PFS có thể dự đoán được

Vì lưu lượng VPN thường được mã hóa, nên nó thường ẩn khỏi con mắt tò mò. Mã hóa hoạt động bởi vì rất khó để brute buộc dữ liệu được mã hóa thành dữ liệu để lộ nội dung văn bản rõ ràng của nó. Trên thực tế, việc phá vỡ mã hóa khó đến mức các dự án giám sát quy mô lớn đôi khi chỉ thu thập tất cả dữ liệu họ có thể với hy vọng họ có thể phá vỡ mã hóa vào một ngày nào đó trong tương lai khi tăng sức mạnh máy tính hoặc họ có thể lấy được các khóa đã được sử dụng để mã hóa dữ liệu. Bí mật chuyển tiếp hoàn hảo (PFS) là một phương pháp có thể được sử dụng để ngăn chặn kịch bản sau.

Perfect Forward Secrecy tạo lại các khóa mã hóa được sử dụng để mã hóa lưu lượng VPN theo định kỳ. Khi một cặp khóa mới được tạo, cặp trước đó sẽ bị hủy. Điều này có nghĩa là mọi gói được mã hóa được thu thập không thể được giải mã vào một ngày sau đó vì khóa được sử dụng để mã hóa chúng không còn tồn tại.

OpenVPN hỗ trợ PFS. Trong khi thu thập dữ liệu cho bài viết này, tôi đã giảm tốc độ đạp xe xuống còn 10 giây để nắm bắt quá trình đó đang diễn ra. Tôi thấy rằng khi quá trình tái tạo khóa diễn ra, chuỗi các gói sau được tạo ra:

09: 01: 48.461276 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 94
09: 01: 54.749114 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 65
09: 01: 58.895381 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 86
09: 01: 58.951091 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 94
09: 01: 58.951614 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 259
09: 01: 59.007916 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 94
09: 01: 59.008027 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 94
09: 01: 59.008265 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 94
09: 01: 59.008300 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 94
09: 01: 59,062927 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, chiều dài 256
09: 01: 59.106521 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, dài 575

Điều đáng chú ý về trình tự này là kích thước gói giống hệt nhau mỗi lần thực hiện quá trình tái tạo khóa. Do đó, bất cứ khi nào tôi thấy một chuỗi các gói có kích thước này trong quá trình chụp gói của mình, tôi biết rằng việc đạp xe chính đang diễn ra:

94
65
86
94
259
94
94
94
94
256
575

Có thể cho rằng, bất kỳ quá trình lặp lại nào về mặt lý thuyết sẽ tạo ra một chuỗi các gói như thế này, nhưng nó vẫn có thể được sử dụng như một chỉ báo cho thấy PFS có thể đang hoạt động. Kết hợp với dữ liệu khác, thông tin này có thể đủ để xác nhận kết nối VPN.

Tất cả các gói được gửi đến cùng một IP

Trong quá trình sử dụng internet thông thường, mọi người và máy tính yêu cầu dữ liệu từ nhiều trang web khác nhau. Mỗi trang web có một địa chỉ IP khác nhau. Khi sử dụng VPN, mọi gói tin sẽ được chuyển đến máy chủ VPN. Máy chủ VPN bóc lớp mã hóa VPN ra khỏi mỗi gói để tiết lộ gói thực và sau đó gửi nó trên đường đến đích thực sự của nó. Máy chủ VPN thực hiện tương tự với các phản hồi. Nó nhận các gói phản hồi, bọc chúng trong một lớp mã hóa và sau đó gửi gói đến máy tính người dùng.

Một gói chụp cho thấy một máy tính gửi 100% lưu lượng truy cập của nó đến một IP duy nhất là một chỉ báo tốt cho thấy VPN hoặc proxy đang được sử dụng.

Psiphon là một công cụ kiểm duyệt kiểm duyệt internet. Nó có một chức năng thú vị có thể chống lại điều này ở một mức độ nào đó. Nó đã phân chia chế độ đường hầm mà về cơ bản chỉ sử dụng đường hầm Psiphon cho giao thông rời khỏi đất nước của bạn.

Để xem điều này trông như thế nào ở cấp độ gói, tôi đã khởi chạy Psiphon và thử nghiệm hai trang web. Tôi đang ở Canada và ở đây, một mẫu lưu lượng truy cập dành cho nhà đăng ký tên miền .CA của chúng tôi. Trong trường hợp này, đích đến của tôi được hiển thị rõ ràng trong việc chụp gói.

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Cờ [.], ack 1026833, thắng 64240, dài 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Cờ [.], Seq 1026833: 1028293, ack 715, thắng 5094, dài 1460
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Cờ [.], Seq 1028293: 1031213, ack 715, thắng 5094, dài 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Cờ [.], ack 1031213, thắng 64240, dài 0

Sau đó tôi đã truy cập trang web so sánh được lưu trữ tại Hoa Kỳ:

8: 29: 48.028789 IP li832-56.members.linode.com > 192.168.1.210.58659: Cờ [P.], seq 107809: 108277, ack 19080, thắng 1392, dài 468
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Cờ [.], ack 108277, thắng 856, dài 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Cờ [P.], seq 19080: 19132, ack 108277, thắng 856, dài 52
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Cờ [.], Ack 19132, thắng 1392, dài 0

Lưu ý cách lưu lượng truy cập dành cho Hoa Kỳ được gửi đến máy chủ Linode thay vì tới soitech.com. Linode là một công ty máy chủ rất lớn và nó không có gì lạ khi thấy lưu lượng truy cập dành cho máy chủ Linode. Psiphon làm xáo trộn thêm lưu lượng truy cập đó bằng cách sử dụng đường hầm SSH để ẩn bất kỳ dấu vết nào của VPN. Đồng thời, DNS ngược (rDNS) cho máy chủ Psiphon tại Linode không phản bội sự liên kết của nó với Psiphon; rDNS chỉ cho thấy Linode sở hữu IP, dự kiến. Có nhiều hơn về rDNS trong phần obfuscation sau này trong bài viết này.

Sự không nhất quán trong hệ điều hành và dữ liệu vân tay gói

Mặc dù mạng TCP là hệ điều hành bất khả tri, các hệ điều hành khác nhau tạo ra các gói với một số giá trị khác nhau. Ví dụ: giá trị Time-To-Live (TTL) gói mặc định khác nhau trong các gói được tạo trên các hệ thống khác nhau. Hầu hết các hệ thống Windows sẽ đặt gói TTL thành 128 theo mặc định trong khi hầu hết các hệ thống Linux sẽ đặt nó thành 64. Vì TTL là một phần hiển thị của gói bị bắt, nên nó có thể xác định hệ điều hành nào có khả năng tạo ra gói đó. Ngoài ra còn có các dấu hiệu khác trong xây dựng gói như chiều dài và Kích thước phân đoạn tối đa (MSS) cũng khác nhau tùy theo hệ điều hành đến hệ điều hành.

Đoạn mã dưới đây là một phần của gói được tạo từ hệ thống Windows. Lưu ý ttl 127 giá trị trên dòng cuối cùng được đặt thành 127. Điều này là do TTL được thể hiện bằng số bước nhảy hoa hồng. Mỗi khi một gói đi qua một thiết bị như bộ định tuyến, thì thiết bị của nó sẽ bị giảm bởi một thiết bị. Trong trường hợp này, TTL bắt đầu ở mức 128 nhưng vì tôi đã bắt được nó trên bộ định tuyến. Sau một bước nhảy thì bây giờ là 127. Tuy nhiên, tôi vẫn có thể nói rằng nó chưa bao giờ là 64 nên đây có thể là một gói được tạo trên hệ thống Windows.

08: 08: 51.657495 IP (to 0x0, ttl 64, id 32150, offset 0, cờ [DF], proto UDP (17), chiều dài 177)
google-công-dns-a.google.com.domain > 192.168.2.139.59414: 40501 3/0/0 cdn-3.convertexperiment.com. CNAME cdn-3.convertexperiment.com.edgekey.net., Cdn-3.convertexperiment.com.edgekey.net. CNAME e5289.g.akamaiedge.net., E5289.g.akamaiedge.net. Một 104,94,35.212 (149)
08: 08: 51.659278 IP (to 0x0, ttl 127, id 3890, offset 0, cờ [DF], proto TCP (6), chiều dài 52)

Một gói được chụp từ máy Linux có chỉ số TTL là 63 sau bước nhảy đầu tiên. Điều này là do hầu hết các máy Linux đặt giá trị ban đầu của gói TTL là 64.

08: 15: 55.913493 IP (to 0x0, ttl 63, id 41443, offset 0, cờ [DF], proto UDP (17), chiều dài 56)
192.168.2.139.48635 > độ phân giải1.ihgip.net.domain: 47200+ A? google.com. (28)

Nhưng cái gì cơ? Tại sao điều quan trọng là phải biết hệ điều hành nào tạo ra một gói?

Nếu một người quan sát có kiến ​​thức chuyên môn về một mục tiêu thì nó có thể quan trọng rất nhiều. Nếu mục tiêu được biết là sử dụng Windows, có lẽ là thành viên của tổ chức lớn sử dụng Windows trong toàn bộ nhưng các gói được lấy từ mục tiêu đó cho thấy chúng có khả năng được tạo trên máy Linux, đó là một chỉ báo tốt cho thấy VPN hoặc proxy của một số loại đang được sử dụng. Điều đáng chú ý là hầu như tất cả các máy chủ VPN đều chạy trên các máy chủ giống Linux hoặc Unix.

Nó có thể điều chỉnh các tham số gói trên hầu hết các hệ thống nhưng rất ít người đi đến độ dài này.

Kỹ thuật obfuscation không đủ từ các nhà cung cấp VPN

Có nhiều phân tích mạng hơn là chỉ thu thập các gói. Các quy trình phụ trợ như DNS có thể đóng một vai trò. Nhiều người dùng VPN biết về DNS vì việc gửi các truy vấn DNS rõ ràng là một cách để người quan sát xác định nơi bạn đang truy cập hoặc sắp ghé thăm. Tuy nhiên, ít người dùng biết đến Reverse DNS (rDNS). Giống như DNS liên kết một tên miền với một địa chỉ IP, rDNS liên kết một địa chỉ IP với một tên máy chủ và tên máy chủ thường xác định chủ sở hữu của IP. Ngoài ra, hầu hết các thư viện lập trình và hệ điều hành đều đi kèm với một số phiên bản của các hàm gethostnamwise * () tiêu chuẩn mở rộng khả năng của hệ thống để liên kết IP và tên máy chủ.

Reverse DNS không quan trọng bằng DNS DNS thông thường vì rDNS không đóng vai trò gì trong việc định tuyến lưu lượng. Thay vào đó, nó được sử dụng chủ yếu như một phương tiện để xác định quyền sở hữu IP. Chỉ chủ sở hữu địa chỉ IP mới có thể liên kết bản ghi rDNS với địa chỉ đó. Do đó, việc kiểm tra bản ghi rDNS của một địa chỉ IP cung cấp sự đảm bảo hợp lý về người sở hữu nó, hoặc ít nhất, ai là chủ sở hữu muốn bạn nghĩ rằng sở hữu nó. Lưu ý rằng rDNS không bắt buộc và nhiều địa chỉ IP hoàn toàn không có mục nhập rDNS.

Hãy cùng xem các ví dụ về tên miền facebook.com. Bản ghi DNS Một bản ghi được cung cấp bởi một truy vấn DNS tiêu chuẩn hiển thị địa chỉ IP này:

$ đào + facebook.com ngắn
31,13,67,35

Bây giờ, hãy cho phép sử dụng truy vấn DNS ngược hoặc hàm gethostnamitheraddr () để xem ai sở hữu IP đó:

$ máy chủ -n 31,13,67,35
35.67.13.31.in-addr.arpa con trỏ tên miền edge-star-mini-shv-01-mia3.facebook.com

Chúng ta có thể thấy rằng Facebook thực sự sở hữu địa chỉ IP đó. Tuy nhiên, hầu hết các trang web không sở hữu IP riêng của họ; chúng được cho thuê và thuộc về các tổ chức độc đoán hoặc có thể thuộc sở hữu của các thực thể ít rõ ràng hơn. Amazon là một ví dụ về một nhà cung cấp máy tính lớn được nhiều công ty sử dụng. Một truy vấn rDNS cho địa chỉ IP của nhiều dịch vụ internet chỉ đơn giản cho thấy Amazon sở hữu IP và do đó thông tin ít được sử dụng trong việc xác định ai vận hành IP. Một ví dụ khác là Google. Google tinh tế hơn một chút trong các mục rDNS của mình, nhưng nó vẫn duy trì thông tin sở hữu. Ở đây, cách thức DNS đảo ngược tìm IP của Google:

$ đào + google.com ngắn
216,58.207,46

$ máy chủ -n 216,58.207,46
46.207.58.216.in-addr.arpa con trỏ tên miền fra16s24-in-f14.1e100.net.

Google sở hữu tên miền 1e100.net, vì vậy chúng ta có thể thấy rằng IP này thực tế thuộc về Google.

Trong thế giới của VPN, các công cụ phân giải địa chỉ có khả năng có thể được sử dụng để xem liệu IP lưu lượng truy cập của bạn có thuộc về VPN hay không. Ví dụ: lệnh tcpdump mặc định trên bộ định tuyến OpenWRT sẽ cố gắng giải quyết các IP mà nó nhìn thấy trong các gói TCP. Dường như chủ yếu sử dụng gethostbyaddress () để thực hiện việc này và do đó, đôi khi có thể thấy các gói được định sẵn. Một bản chụp tcpdump mặc định của phiên IPV Biến minh họa điều này:

08: 23: 14.485768 IP 216-151-184-30.ipv Biến.com.3074 > 192.168.1.210.51061: UDP, dài 1441
08: 23: 14.485847 IP 216-151-184-30.ipv Biến.com.3074 > 192.168.1.210.51061: UDP, dài 1441
08: 23: 14.486144 IP 216-151-184-30.ipv Biến.com.3074 > 192.168.1.210.51061: UDP, dài 1441
08: 23: 14.486186 IP 216-151-184-30.ipv Biến.com.3074 > 192.168.1.210.51061: UDP, dài 385

Ứng dụng khách IPV Biến cho Windows cung cấp ba cấu hình: kết nối OpenVPN tiêu chuẩn, kết nối OpenVPN bằng HTTPS và kết nối bị xáo trộn.

Các gói ở trên đã được ghi lại trong một phiên sử dụng cài đặt kết nối OpenVPN bị xáo trộn, tuy nhiên WireShark vẫn có thể cung cấp thông tin đích.

Tóm tắt

Khi xác định mức độ sử dụng VPN, có rất ít viên đạn bạc bạc. Thông thường cần một số kỹ thuật hoặc quan sát để biên dịch đủ các chỉ số cho biết VPN đang được sử dụng và thậm chí sau đó có thể khó chắc chắn 100%. Các công ty có quyền lợi trong việc không cho phép sử dụng VPN như Netflix và các dịch vụ phát trực tuyến khác có các nhóm toàn thời gian dành riêng cho vấn đề này. Trong các trường hợp khác, nhiều quốc gia Đông Âu và Trung Đông) cấm sử dụng VPN và có các nhóm tương tự để loại bỏ người dùng VPN.