Ý tưởng của bạn không khả thi vì một số lý do:
1)
Theo như tôi nhớ thì bản thân OpenVPN không có tính năng nào để chuyển dữ liệu từ kết nối VPN sang một quy trình tùy chỉnh, trước khi chuyển tiếp.
Để tham khảo nhanh: Kiểm tra xem TCP/IP đang được sử dụng ở đâu trong ngăn xếp OSI.
OpenVPN nằm ở lớp 3 của ngăn xếp OSI (Lớp mạng), trong khi các gói TCP thuộc lớp 4 (Lớp vận chuyển).
Câu hỏi của bạn chỉ vì lý do này nằm ngoài phạm vi những gì OpenVPN muốn đạt được.
Điều duy nhất bạn có thể thao tác là điều gì sẽ xảy ra khi máy khách kết nối với máy chủ hoặc ngắt kết nối.
Những tình huống đó có thể được xác định trong tệp cấu hình máy chủ của bạn thông qua các cài đặt sau:
# máy khách được kết nối với máy chủ VPN
kết nối máy khách "/script/client_connect.sh"
# máy khách bị ngắt kết nối với máy chủ VPN
ngắt kết nối máy khách "/script/client_disconnect.sh"
Tất cả các biến môi trường có sẵn cho tập lệnh tùy chỉnh của bạn đều có tại đây:
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/#scripting-and-environmental-variables
Nhưng về bản chất, thông tin duy nhất bạn có thể theo dõi là chứng chỉ ứng dụng khách nào đã được sử dụng để kết nối với máy chủ và địa chỉ IP nào được gán cho ứng dụng khách, sau đó thực hiện một số logic tùy chỉnh trên máy chủ tùy thuộc vào người kết nối và phải làm gì khi họ ngắt kết nối lại.
Một thiết lập điển hình có thể là triển khai phía máy chủ DNS động hoặc thực hiện một số định tuyến tùy chỉnh, chẳng hạn như định tuyến chuyển đổi dự phòng tùy thuộc vào kết nối VPN nào đang hoạt động.
2)
Đề cập đến sơ đồ này của gói IPv4 từ WikiPedia:
Về bản chất, điều bạn muốn làm là thao tác với trường dữ liệu, tùy thuộc vào địa chỉ nguồn hoặc địa chỉ đích.
Đây còn được gọi là tấn công trung gian.
Như bạn đã phát hiện ra, thật khó để làm điều đó bằng cách nghe trên giao diện OpenVPN vì tất cả nội dung đều là mã hóa. Điều xảy ra là gói IPv4 dành cho Internet được gói gọn trong một gói IPv4 khác, gói này dành cho máy chủ OpenVPN.
Gói IPv4 được đóng gói được lưu trữ trong trường dữ liệu trong sơ đồ trên.
Đó là gói giải mã được chuyển tiếp tới Internet từ máy chủ VPN.
Tuy nhiên có một lời cảnh báo:
Tôi đoán máy khách VPN không không phải có một địa chỉ ip công khai. Điều này có nghĩa là bản dịch NAT được mở rộng và địa chỉ nguồn được viết lại thành địa chỉ của máy chủ VPN trước khi bất kỳ máy chủ nào được liên hệ trên Internet.
Tương tự như vậy, khi máy chủ trả lời lại bằng câu trả lời, chúng tôi có địa chỉ IPv4 đích giống với máy chủ VPN.
Điều này có nghĩa là để thao tác với trường dữ liệu, chúng ta cần theo dõi cổng nào đang được sử dụng trong trường dữ liệu. bảng dịch địa chỉ mạng
(hay còn gọi là NAT).
Các cổng được sử dụng thường có bản chất động vì nhiều máy khách VPN có thể kết nối với Internet thông qua VPN và NAT và mọi phiên TCP (mail, web, ssh bất cứ thứ gì) đều sử dụng một cổng khác.
Vì vậy, nếu bạn muốn thao tác gói TCP được giải mã nó phải xảy ra sau khi giải mã, nhưng trước khi nó được dịch trong NAT.
Về lý thuyết, bạn có thể chặn gói bằng cách sử dụng iptables
, nhưng nó không tầm thường khi VPN và NAT nằm trên cùng một máy.
Một cách tiếp cận khác là tấn công trực tiếp lưu lượng OpenVPN được mã hóa, vì bạn kiểm soát máy chủ OpenVPN có nghĩa là bạn cũng kiểm soát chứng chỉ và khóa riêng nào đang được sử dụng trên cả máy chủ và máy khách.
Điều này có thể thực hiện được như một cuộc tấn công trung gian cổ điển. Tôi không biết làm thế nào điều này được thực hiện mặc dù. :-)
... nhưng điều này dẫn đến lập luận cuối cùng của tôi:
3)
Hầu hết lưu lượng truy cập trên Internet là mã hóa TLS.
Vì vậy, ngay cả sau khi bạn đã giải mã lưu lượng OpenVPN, vẫn có một lớp mã hóa khác mà bạn phải đánh bại để thao tác nội dung của trường dữ liệu.
Phần này thậm chí còn khó tấn công hơn là chỉ tấn công lưu lượng OpenVPN được mã hóa vì bạn không kiểm soát được các khóa mã hóa được sử dụng cho phiên.
Ngay cả khi bạn đã cố giải mã lưu lượng truy cập TLS và mã hóa lại nội dung để người dùng cuối có vẻ như lưu lượng truy cập được mã hóa thực sự bắt nguồn từ YouTube hoặc bất cứ thứ gì thì nó vẫn vô ích, vì chứng chỉ bạn sử dụng để mã hóa lưu lượng truy cập https là Không đáng tin cậy bởi các trình duyệt trên máy tính của người dùng cuối.
Điều này một mình làm cho cuộc tấn công trung gian của bạn trở nên vô ích.
Bây giờ điều này gần như là một câu trả lời hoàn chỉnh cho câu hỏi của bạn.
Có nhiều góc độ khác để tấn công phiên TCP, nhưng bây giờ chúng ta sẽ chuyển sang lĩnh vực nâng cao thuộc về một diễn đàn có nhiều chuyên gia bảo mật.
Phần đó là CÁCH vượt quá trình độ của tôi. :-)