Quan sát lưu lượng của một máy khách OpenVPN ở đâu trên cổng

Bạn muốn biết máy khách đang kết nối chạm tới những đích nào, nên bạn mở một shell trên máy chủ VPN và gõ ss. Không có gì hữu ích xuất hiện, và kết luận rằng đường hầm hỏng đến hơi quá dễ dàng. Một cổng OpenVPN định tuyến chuyển tiếp các gói của máy khách; nó không kết thúc các kết nối TCP của chúng và không sở hữu socket cho chúng. Bằng chứng sống ở nơi khác, và nơi nào tùy thuộc vào cách lưu lượng được xử lý sau khi ra khỏi đường hầm.

Xác định bạn đang nhìn vào cách bố trí nào

Hai hình thức phổ biến tạo ra bằng chứng hoàn toàn khác nhau. Cổng định tuyến giải đóng gói, chuyển tiếp và có thể thực hiện NAT nguồn, nên kết nối của máy khách vẫn tồn tại từ đầu đến cuối mà không có socket cục bộ.

Proxy kết thúc lưu lượng: nó chấp nhận kết nối, rồi mở kết nối thượng nguồn của chính nó. Trong cách bố trí đó có hai kết nối cho một yêu cầu, và mối liên hệ giữa chúng chỉ tồn tại trong hồ sơ của chính proxy. Biết bạn đã triển khai cách nào trong hai cách quyết định xem bạn nên đọc trạng thái luồng của nhân hay nhật ký ứng dụng.

Phần lớn sự nhầm lẫn đến từ phỏng đoán. Hãy xác nhận hình thức trước khi chọn công cụ. Trước tiên hãy đọc cấu hình máy chủ xem có chỉ thị proxy không, vì sự hiện diện của nó thay đổi mọi bước sau. Không có nó thì đường đi của gói là định tuyến và trạng thái luồng của nhân là bằng chứng của bạn.

Trước tiên hãy gắn địa chỉ với một phiên

Bắt đầu từ trạng thái phiên của máy chủ và xác định địa chỉ nội bộ hiện tại của máy khách. Địa chỉ trong nhóm được tái sử dụng, nên một địa chỉ tự nó chỉ là một hợp đồng thuê, không phải một người.

Ghi lại thời gian và danh tính đã xác thực cùng nhau, và để ý xem có cả một mạng LAN ẩn sau máy khách đó không. Nếu đầu xa định tuyến một mạng con, các địa chỉ nội bộ bạn thấy có thể là máy chủ gốc hoặc đã được dịch.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Cặp đó trả lời hai câu hỏi cùng lúc: giao diện đường hầm phục vụ tiền tố nào, và phiên nào đang hoạt động trong khoảng thời gian bạn quan tâm. Hãy làm điều này trước khi diễn giải bất kỳ mục luồng nào, vì một tuple thuyết phục gắn với sai phiên còn tệ hơn không có bằng chứng nào.

Đọc bảng luồng trên một cổng định tuyến

Khi địa chỉ và khoảng thời gian đã được xác lập, một danh sách chỉ đọc các kết nối được theo dõi cho thấy cổng đang chuyển tiếp gì cho nó. Lọc theo nguồn gốc để bạn không phải đọc toàn bộ bảng.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Mỗi mục chứa hai tuple, gốc và trả lời, là hai chiều của một luồng chứ không phải hai ứng dụng. Trên đường có NAT nguồn, tuple gốc giữ địa chỉ của đường hầm trong khi phía trả lời hiển thị địa chỉ cổng đã dịch, và chính điều đó khiến đầu ra trông sai ngay từ cái nhìn đầu tiên.

Hãy coi danh sách là trạng thái sống chứ không phải lịch sử. Các luồng ngắn có thể đã hết hạn, lưu lượng không được theo dõi không bao giờ xuất hiện, và một không gian tên mạng khác hiển thị bảng khác. Tài liệu tham chiếu conntrack mô tả các bộ lọc và đầu ra hai chiều.

Một lần bắt gói giới hạn để xác nhận việc đọc

Nếu giao diện đường hầm hiển thị ở nơi bạn đang nhìn, một lần bắt gói giới hạn sẽ quyết định liệu các gói bạn đã xác định có phải là những gói trên dây không. Giữ bộ lọc hẹp và giới hạn số gói nhỏ.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

So sánh dấu thời gian, giao thức và cổng với mục luồng và với yêu cầu bạn đã làm như một bài kiểm tra. Một lần bắt gói sau NAT chỉ hiển thị địa chỉ công cộng của cổng, trong khi phía đường hầm vẫn có thể hiển thị địa chỉ của máy khách, và sự khác biệt đó là thông tin chứ không phải mâu thuẫn.

Nếu giao diện không thấy gì, hãy kiểm tra đường đi của dữ liệu trước khi kết luận máy khách đang rảnh: lưu lượng giữa các máy khách và một số đường dỡ tải không bao giờ đi qua điểm bạn đang quan sát.

Nhật ký proxy, và giới hạn của những gì bạn đã thấy

Khi một proxy nằm trên đường, các socket thượng nguồn của nó hiển thị trong bảng socket nhưng chúng không ánh xạ một-một với máy khách VPN, đặc biệt khi có gộp nhóm hoặc ghép kênh. Hãy dùng nhật ký giao dịch đã cấu hình của proxy để tương quan danh tính máy khách, đích, dấu thời gian và bất kỳ mã nhận dạng yêu cầu nào nó ghi lại.

Hãy kiểm tra cấu hình ghi nhật ký của phiên bản đã triển khai thay vì cho rằng mọi yêu cầu đều được ghi mặc định.

Cuối cùng, hãy chính xác về phạm vi. Địa chỉ đích và cổng là siêu dữ liệu, không phải URL và không phải nội dung trang, vì phiên HTTPS bên trong vẫn giữ sự bảo vệ riêng bất kể đường hầm. Hãy báo cáo những gì bạn quan sát, từ điểm quan sát nào và vào thời điểm nào.