![[HaBo]](/styles/default/logoklein.png){kind=small}
Hackse
0
Hallo,
Debian Linux, Tor auf Port 9050, Privoxy auf Port 8118, leitet an Tor weiter. Ziel ist es zwecks Anonymisierung alle ausgehenden HTTP-Verbindungen über den lokalen Proxy weiterzuleiten. Folgende funktionierende iptables-Konfiguration verwende ich hierfür.
Nun setze ich für den wget noch den Proxy-Server:
Und lade mir dann über meine LAN-IP 192.168.1.40 über den lokalen Proxy und Tor exemplarisch Google mit der IP-Adresse 173.194.70.102 herunter:
Das funktioniert auch. Netstat zeigt, dass ausschließlich via Tor verbunden wird:
Letzteres habe ich auf einem meiner eigenen Web-Server via tcpdump verifizieren können.
Bis hierhin ist alles dem Anschein nach o.k.
Was ich zu solch später Stunde nicht mehr nachvollziehen kann ist, dass das o.g. Szenario nicht funktioniert, wenn ich den export der http_proxy-Variable weglasse:
Ich erwarte nun aufgrund der vorletzten iptables-Regel (NAT), dass die HTTP-Anfrage von wget durch den lokalen Proxy geschleust wird. Aus irgend einem Grund geschieht das aber nicht, wget versucht trotz der NAT-Regel eine Direkt-Verbindung zu Google aufzubauen:
und wird dann glücklicherweise von der letzten iptables-Regel brav blockiert:
Mir ist nicht klar wie der SYN_SENT des Users root zustande kommt. Dieser HTTP-Verbindungsversuch müsste IMHO aufgrund der NAT-Regel durch den Proxy auf localhost:8118 geschleust werden, wie es auch der Fall ist, wenn der http_proxy gesetzt ist, oder?
Manch andere Programme ignorieren die http_proxy Variable, daher ist es wichtig, dass die NAT-Regel funktioniert.
Gruß
Hackse
Debian Linux, Tor auf Port 9050, Privoxy auf Port 8118, leitet an Tor weiter. Ziel ist es zwecks Anonymisierung alle ausgehenden HTTP-Verbindungen über den lokalen Proxy weiterzuleiten. Folgende funktionierende iptables-Konfiguration verwende ich hierfür.
Code:
# Accept tor-user output connections
iptables -A OUTPUT -j ACCEPT -m owner --uid-owner debian-tor
# Accept local connections
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A INPUT -j ACCEPT -i lo
# Accept already established connections
iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Redirect http traffic to local proxy
iptables -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner privoxy -j ACCEPT
iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner privoxy --dport 80 -j REDIRECT --to-port 8118
# Drop everything else
iptables -P OUTPUT DROP
Code:
export http_proxy=localhost:8118
Code:
wget -r 173.194.70.102
Code:
netstat -te | egrep -v "localhost.*localhost"
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode
tcp 0 0 192.168.1.40:44395 lh21184.voxility.n:9001 ESTABLISHED debian-tor 19184
tcp 0 0 192.168.1.40:35955 us02.nyr.be:https ESTABLISHED debian-tor 10793Bis hierhin ist alles dem Anschein nach o.k.
Was ich zu solch später Stunde nicht mehr nachvollziehen kann ist, dass das o.g. Szenario nicht funktioniert, wenn ich den export der http_proxy-Variable weglasse:
Code:
unset http_proxy
Code:
wget -r 173.194.70.102
--2013-07-28 05:07:49-- http://173.194.70.102/
Connecting to 173.194.70.102:80...
Code:
netstat -te | egrep -v "localhost.*localhost"
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode
tcp 0 0 192.168.1.40:44395 lh21184.voxility.n:9001 ESTABLISHED debian-tor 19184
[B]tcp 0 1 192.168.1.40:44473 fa-in-f102.1e100.n:http SYN_SENT root 19782 [/B]
tcp 0 0 192.168.1.40:35955 us02.nyr.be:https ESTABLISHED debian-tor 10793Manch andere Programme ignorieren die http_proxy Variable, daher ist es wichtig, dass die NAT-Regel funktioniert.
Gruß
Hackse
