Ideea ta este imposibilă din mai multe motive:
1)
Din câte îmi amintesc, nu există o funcție în OpenVPN în sine care să conducă datele de la o conexiune VPN într-un proces personalizat, înainte de redirecționare.
Pentru referință rapidă: verificați unde este utilizat TCP/IP în stiva OSI.
OpenVPN se află pe stratul 3 al stivei OSI (stratul de rețea), în timp ce pachetele TCP aparțin stratului 4 (stratul de transport).
Întrebarea dvs. este doar din acest motiv în afara domeniului de aplicare a ceea ce dorește să obțină OpenVPN.
Singurul lucru cu care puteți manipula este ceea ce se întâmplă atunci când un client se conectează la server sau se deconectează.
Aceste situații pot fi definite în fișierul dvs. de configurare a serverului prin următoarele setări:
# client conectat la serverul VPN
client-connect „/script/client_connect.sh”
# client deconectat de la serverul VPN
client-disconnect „/script/client_disconnect.sh”
Toate variabilele de mediu care sunt disponibile pentru scriptul personalizat sunt disponibile aici:
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/#scripting-and-environmental-variables
Dar, în esență, singura informație pe care o puteți monitoriza este ce certificat de client a fost folosit pentru a vă conecta la server și ce adresă ip a fost atribuită clientului și apoi faceți o logică personalizată pe server, în funcție de cine se conectează și ce să facă când se deconectează din nou.
O configurație tipică ar putea fi implementarea unei părți dinamice a serverului DNS sau efectuarea unor rute personalizate, cum ar fi rutarea de failover, în funcție de conexiunea VPN activată.
2)
Referindu-ne la această diagramă a unui pachet IPv4 de la WikiPedia:
În esență, ceea ce doriți este să manipulați câmpul de date, în funcție de adresa sursă sau de destinație.
Acesta este, de asemenea, cunoscut sub numele de atacul omului din mijloc.
După cum ați aflat greu, faceți-o ascultând pe interfața OpenVPN, deoarece tot conținutul este criptat. Ce se întâmplă este că pachetul IPv4 destinat Internetului este încapsulat într-un alt pachet IPv4, care este destinat serverului OpenVPN.
Pachetul IPv4 încapsulat este stocat în câmpul de date din diagrama de mai sus.
Este pachetul decapsulat care este redirecționat către Internet de la serverul VPN.
Cu toate acestea, există o avertizare:
Presupun că clientul VPN o face nu au o adresă IP publică. Aceasta înseamnă că traducerea NAT este implicată și adresa sursă este rescrisă pentru a fi cea a serverului VPN înainte ca orice gazdă să fie contactată pe Internet.
La fel, atunci când gazda răspunde cu un răspuns, avem adresa IPv4 de destinație aceeași cu serverul VPN.
Aceasta înseamnă că, pentru a manipula câmpul de date, trebuie să urmărim ce porturi sunt utilizate în tabelul de traducere a adreselor de rețea (alias NAT).
Porturile utilizate sunt în mod normal de natură dinamică, deoarece mai mult de un client VPN se poate conecta la Internet prin VPN și NAT și fiecare sesiune TCP (mail, web, ssh orice) folosește un port diferit.
Deci, dacă vrei să manipulezi pachet TCP decriptat trebuie să se întâmple după decriptare, dar înainte de a fi tradus în NAT.
În teorie, puteți intercepta pachetul folosind iptables, dar nu este banal atunci când VPN și NAT se află pe aceeași mașină.
O altă abordare este să atacați direct traficul criptat OpenVPN, deoarece controlați serverul OpenVPN înseamnă că controlați și ce certificate și chei private sunt utilizate atât pe server, cât și pe client.
Acest lucru este realizabil ca un atac clasic de tip man-in-the-middle. Nu știu totuși cum se face asta. :-)
... dar asta mă duce la ultimul meu argument:
3)
Majoritatea traficului de pe Internet este criptat TLS.
Deci, chiar și după ce ați decriptat traficul OpenVPN, există un alt nivel de criptare pe care trebuie să îl învingeți pentru a manipula conținutul câmpului de date.
Această parte este chiar mai greu de atacat decât doar atacarea traficului criptat OpenVPN, deoarece nu deții controlul cheilor de criptare utilizate pentru sesiune.
Chiar dacă ați încerca să decriptați traficul TLS și să recriptați conținutul, astfel încât pentru utilizatorul final să pară că traficul criptat a provenit într-adevăr de pe YouTube sau orice altceva, atunci ar fi inutil, deoarece certificatul pe care îl utilizați pentru a cripta traficul https este nu de încredere de browserele de pe computerele utilizatorilor finali.
Numai asta face ca atacul tău omul din mijloc să fie inutil.
Acum, acesta este cât mai aproape de un răspuns complet la întrebarea dvs.
Există și alte unghiuri pentru a ataca o sesiune TCP, dar acum mergem la un domeniu avansat care aparține unui forum plin de experți în securitate.
Acea parte este CU MULT peste calificările mele. :-)
