ความคิดของคุณเป็นไปไม่ได้ด้วยเหตุผลหลายประการ:
1)
เท่าที่ฉันจำได้ไม่มีคุณสมบัติใน OpenVPN เองที่จะไพพ์ข้อมูลจากการเชื่อมต่อ VPN ไปยังกระบวนการที่กำหนดเองก่อนที่จะส่งต่อ
สำหรับการอ้างอิงอย่างรวดเร็ว: ตรวจสอบตำแหน่งที่ใช้ TCP/IP ในสแตก OSI
OpenVPN อยู่บนเลเยอร์ 3 ของสแต็ก OSI (เลเยอร์เครือข่าย) ในขณะที่แพ็คเกจ TCP อยู่ในเลเยอร์ 4 (เลเยอร์การขนส่ง)
คำถามของคุณคือเหตุผลนี้เพียงอย่างเดียวที่อยู่นอกเหนือขอบเขตของสิ่งที่ OpenVPN ต้องการบรรลุ
สิ่งเดียวที่คุณจัดการได้คือสิ่งที่จะเกิดขึ้นเมื่อไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์หรือยกเลิกการเชื่อมต่อ
สถานการณ์เหล่านั้นสามารถกำหนดได้ในไฟล์คอนฟิกูเรชันเซิร์ฟเวอร์ของคุณผ่านการตั้งค่าต่อไปนี้:
# ลูกค้าเชื่อมต่อกับเซิร์ฟเวอร์ VPN
ลูกค้าเชื่อมต่อ "/script/client_connect.sh"
# ไคลเอ็นต์ถูกตัดการเชื่อมต่อจากเซิร์ฟเวอร์ VPN
ลูกค้าตัดการเชื่อมต่อ "/script/client_disconnect.sh"
ตัวแปรสภาพแวดล้อมทั้งหมดที่พร้อมใช้งานสำหรับสคริปต์แบบกำหนดเองของคุณมีอยู่ที่นี่:
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/#scripting-and-environmental-variables
แต่โดยพื้นฐานแล้ว ข้อมูลเดียวที่คุณสามารถตรวจสอบได้คือใบรับรองไคลเอนต์ใดที่ใช้เชื่อมต่อกับเซิร์ฟเวอร์และที่อยู่ IP ใดถูกกำหนดให้กับไคลเอนต์ จากนั้นสร้างตรรกะที่กำหนดเองบนเซิร์ฟเวอร์โดยขึ้นอยู่กับว่าใครเชื่อมต่อและจะทำอย่างไรเมื่อพวกเขายกเลิกการเชื่อมต่ออีกครั้ง
การตั้งค่าทั่วไปอย่างหนึ่งอาจเป็นการใช้ฝั่งเซิร์ฟเวอร์ DNS แบบไดนามิกหรือทำการกำหนดเส้นทางแบบกำหนดเองบางอย่าง เช่น การกำหนดเส้นทางเมื่อเกิดข้อผิดพลาด โดยขึ้นอยู่กับการเชื่อมต่อ VPN ที่ใช้
2)
อ้างถึงไดอะแกรมของแพ็กเก็ต IPv4 จาก วิกิพีเดีย:
โดยพื้นฐานแล้ว สิ่งที่คุณต้องการทำคือการจัดการฟิลด์ข้อมูล ขึ้นอยู่กับที่อยู่ต้นทางหรือปลายทาง
สิ่งนี้เรียกอีกอย่างว่าการโจมตีแบบคนอยู่ตรงกลาง
ในขณะที่คุณพบว่ามันยากที่จะทำโดยการฟังบนอินเทอร์เฟซ OpenVPN เนื่องจากเนื้อหาทั้งหมดได้รับการเข้ารหัส สิ่งที่เกิดขึ้นคือแพ็กเก็ต IPv4 ที่กำหนดไว้สำหรับอินเทอร์เน็ตนั้นถูกห่อหุ้มไว้ในแพ็กเก็ต IPv4 อื่น ซึ่งกำหนดไว้สำหรับเซิร์ฟเวอร์ OpenVPN
แพ็กเก็ต IPv4 ที่ห่อหุ้มจะถูกเก็บไว้ในช่องข้อมูลในไดอะแกรมด้านบน
เป็นแพ็กเก็ตที่ถอดรหัสแล้วซึ่งส่งต่อไปยังอินเทอร์เน็ตจากเซิร์ฟเวอร์ VPN
อย่างไรก็ตามมีข้อแม้คือ
ฉันคิดว่าไคลเอนต์ VPN ทำ ไม่ มีที่อยู่ IP สาธารณะ ซึ่งหมายความว่ามีการแปล NAT และที่อยู่ต้นทางจะถูกเขียนใหม่ให้เป็นที่อยู่ของเซิร์ฟเวอร์ VPN ก่อนที่โฮสต์ใด ๆ จะได้รับการติดต่อบนอินเทอร์เน็ต
ในทำนองเดียวกันเมื่อโฮสต์ตอบกลับมาพร้อมกับคำตอบว่าเรามีที่อยู่ IPv4 ปลายทางเหมือนกับเซิร์ฟเวอร์ VPN
ซึ่งหมายความว่าในการจัดการกับฟิลด์ข้อมูล เราจำเป็นต้องติดตามว่าพอร์ตใดถูกใช้ใน ตารางการแปลที่อยู่เครือข่าย
(หรือที่เรียกว่า NAT)
โดยปกติแล้วพอร์ตที่ใช้จะเป็นแบบไดนามิก เนื่องจากไคลเอนต์ VPN มากกว่าหนึ่งตัวสามารถเชื่อมต่อกับอินเทอร์เน็ตผ่าน VPN และ NAT และทุกเซสชัน TCP (เมล เว็บ ssh อะไรก็ตาม) จะใช้พอร์ตที่แตกต่างกัน
ดังนั้นหากคุณต้องการจัดการ ถอดรหัสแพ็กเก็ต TCP จะต้องเกิดขึ้นหลังจากการถอดรหัส แต่ก่อนแปลใน NAT
ในทางทฤษฎีคุณสามารถสกัดกั้นแพ็กเก็ตโดยใช้ iptables
แต่ไม่ใช่เรื่องเล็กน้อยเมื่อ VPN และ NAT อยู่ในเครื่องเดียวกัน
อีกวิธีหนึ่งคือการโจมตีทราฟฟิก OpenVPN ที่เข้ารหัสโดยตรง เนื่องจากคุณควบคุมเซิร์ฟเวอร์ OpenVPN หมายความว่าคุณยังควบคุมใบรับรองและคีย์ส่วนตัวที่ใช้ทั้งบนเซิร์ฟเวอร์และไคลเอ็นต์
สิ่งนี้สามารถทำได้ในฐานะการโจมตีแบบคลาสสิกจากคนตรงกลาง ฉันไม่รู้ว่ามันทำอย่างไร :-)
... แต่สิ่งนี้ทำให้ฉันมีข้อโต้แย้งสุดท้าย:
3)
การรับส่งข้อมูลส่วนใหญ่บนอินเทอร์เน็ตคือการเข้ารหัส TLS
ดังนั้นแม้หลังจากที่คุณถอดรหัสทราฟฟิก OpenVPN แล้ว ยังมีการเข้ารหัสอีกชั้นหนึ่งที่คุณต้องเอาชนะเพื่อจัดการเนื้อหาของฟิลด์ข้อมูล
ส่วนนี้โจมตีได้ยากกว่าการโจมตีทราฟฟิก OpenVPN ที่เข้ารหัส เนื่องจากคุณไม่ได้ควบคุมคีย์การเข้ารหัสที่ใช้สำหรับเซสชัน
แม้ว่าคุณจะพยายามถอดรหัสทราฟฟิก TLS และเข้ารหัสเนื้อหาอีกครั้ง ดังนั้นสำหรับผู้ใช้ปลายทางดูเหมือนว่าทราฟฟิกที่เข้ารหัสนั้นมาจาก YouTube หรืออะไรก็ตาม ก็ยังคงใช้ไม่ได้ เนื่องจากใบรับรองที่คุณใช้เพื่อเข้ารหัสทราฟฟิก https นั้น ไม่น่าเชื่อถือ โดยเบราว์เซอร์บนคอมพิวเตอร์ของผู้ใช้ปลายทาง
สิ่งนี้ทำให้การโจมตีแบบคนตรงกลางของคุณไร้ประโยชน์
ตอนนี้เกือบจะเป็นคำตอบที่สมบูรณ์สำหรับคำถามของคุณแล้ว
มีมุมอื่นๆ ในการโจมตีเซสชัน TCP แต่ตอนนี้เรากำลังดำเนินการในฟิลด์ขั้นสูงที่อยู่ในฟอรัมที่เต็มไปด้วยผู้เชี่ยวชาญด้านความปลอดภัย
ส่วนนั้นเป็นวิธีที่เกินคุณสมบัติของฉัน :-)