Am urmatoarea retea:
.__________. ._______.
| vm-cli | <==> <enp1s0| vm-gw |enp2s0> <==> internet
AAAA·
vm-cli are adresa 192.168.255.2; enp1s0@vm-gw are 192.168.255.1; enp2s0@vm-gw, nu contează.
Vreau toate traficul de internet să treacă prin Tor. Pentru asta, configurez Tor să folosească un socket transparent și să folosesc rutarea politicii pentru a redirecționa traficul către acesta.Mai întâi adaug o regulă de rutare și definesc o tabelă de rutare alternativă care direcționează totul către localhost:
regulă ip adăugați fwmark 1 tabelul 1
IP route add local 0.0.0.0/0 dev lo tabelul 1
Apoi configurez mai întâi firewall-ul să redirecționeze vm-gw
ieșire către proxy:
table proxy {
# transmiteți traficul redirecționat către proxy
deviere în lanț {
tip filter hook prerouting priority filter; acceptarea politicii;
protocol ip tcp mark 1 tproxy la :9040
}
}
tabel local {
# utilizați NAT de destinație pentru traficul DNS, deoarece nu funcționează cu tproxy
lanț dstNAT {
tip nat hook output priority mangle; acceptarea politicii;
redirecționarea domeniului udp dport către :9053
}
# marcați tot traficul non-Tor care merge către interfața conectată la internet pentru a fi redirecționat
redirecționare în lanț {
tip route hook output priority mangle; acceptarea politicii;
oif enp2s0 skuid != tor ip protocol tcp meta mark set 1
}
}
Frumos, îl testez cu săpa
și răsuci
: totul trece prin Tor.
Ce nu merge
Acum adaug următoarea regulă pentru a redirecționa traficul de la vm-cli
sau orice altă gazdă care folosește vm-gw
ca gateway:
telecomandă de masă {
redirecționare în lanț {
tip nat hook prerouting priority mangle; acceptarea politicii;
# trafic DNS NAT de destinație
redirecționarea domeniului udp dport către :9053
# marca traficul tcp de la enp1s0 pentru rutarea politicii
iif enp1s0 ip protocol tcp meta mark set 1
}
}
Încerc să fac o interogare DNS, funcționează. Încerc să fac o solicitare HTTP, fără răspuns...
Urmărirea pachetelor
Urmărind pachetele și uitându-mă la jurnalul Tor, văd asta vm-cli
Traficul TCP ajunge la Tor. Dar răsuci
pe vm-cli
se pare că nu vede niciun răspuns HTTP.
Așa că încerc să urmăresc răspunsul serverului HTTP. Deoarece vine de la Tor, nu voi vedea niciun trafic HTTP în intrare, dar îl voi vedea în vm-gw
ieșire. Apoi adaug următoarea regulă pentru urmărire:
tabel local {
ieșire în lanț {
tip filtru cârlig ieșire filtru prioritar; acceptarea politicii;
tcp sport 80 ip daddr 192.168.255.2 meta nftrace set 1
}
[â¦]
}
Face curl http://perdu.com
pe vm-cli
Primesc urmatoarea urma vm-gw
:
trace id 2fc29112 ip local output packet: oif "enp1s0" ip saddr 208.97.177.124 ip daddr 192.168.255.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 0 ip lungime = 60 tcp dport 80 tcp dport = 60 tcp7 dport fereastra tcp 65160
trace id 2fc29112 ip local output rule tcp sport 80 ip daddr 192.168.255.2 meta nftrace set 1 (verdictul continuă)
trace id 2fc29112 ip verdictul de ieșire locală continuă
trace id 2fc29112 ip politica locală de ieșire acceptă
Și acolo, totul mi se pare corect... există un răspuns de la serverul HTTP, destinația este vm-cli
folosind enp1s0
interfață.
Încerc să urmăresc pachetul vm-cli
. Acolo putem vedea pachetul de ieșire și răspunsul acestuia:
trace id d9101d30 ip filter output packet: oif "enp2s0" ip saddr 192.168.255.2 ip daddr 208.97.177.124 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 40142 ip 40142 tc 40142 tc2 sport = tc571 tc2 lungime fereastra tcp 64240
trace id d9101d30 ip filter output rule tcp dport 80 meta nftrace set 1 (verdictul continuă)
trace id d9101d30 ip filter output verdict continua
trace id d9101d30 ip filter output policy accept
trace id 51163d64 ip filter prerouting packet: iif "enp2s0" ether saddr 52:54:00:bd:38:6d ether daddr 52:54:00:f0:a2:51 ip saddr 208.97.177.124. ips dp5162. cs0 ip ecn not-ect ip ttl 64 ip id 0 ip length 60 tcp sport 80 tcp dport 57124 tcp flags == 0x12 tcp window 65160
trace id 51163d64 ip filter prerouting regula meta nftrace set 1 (verdictul continuă)
trace id 51163d64 verdictul de preroutare a filtrului ip continuă
trace id 51163d64 IP filter prerouting policy accept
Pot vedea:
- un pachet de ieșire de la 192.168.255.2:57124 la 208.97.177.124:80
- un răspuns de la 208.97.177.124:80 la 192.168.255.2:57124
Adresele și porturile se potrivesc... curl --verbos
spune că conexiunea este stabilită, dar de ce cererea HTTP nu primește niciun răspuns?
netcat
îmi confirmă că răspunsul HTTP nu ajunge la aplicație. am incercat si eu hping
, iar cu configurarea tproxy primesc duplicate:
hping perdu.com --destport 80 --syn --count 10
HPING perdu.com (enp2s0 208.97.177.124): set S, 40 anteturi + 0 octeți de date
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=64240 rtt=9,8 ms
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=64240 rtt=9,8 ms
DUP! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=64240 rtt=1049.9 ms
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=64240 rtt=9,8 ms
DUP! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=64240 rtt=1099.9 ms
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=3 win=64240 rtt=29.8 ms
DUP! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=64240 rtt=1059.9 ms
DUP! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=64240 rtt=3120.0 ms
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=4 win=64240 rtt=29.8 ms
DUP! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=3 win=64240 rtt=1079.9 ms
--- perdu.com hping statistic ---
5 pachete transmise, 10 pachete primite, -100% pierdere de pachete
dus-întors min/medie/max = 9,8/749,9/3120,0 ms