ubuntuusers.de

Hi,

ich möchte allen auf einem AppServer anfallenden, ins Internet ausgehenden Traffic (http) direkt von diesem aus umleiten auf meinen squid server. Dazu möchte ich auf dem jeweiligen Server eine Iptables regel einrichten.

Der Server hat ein internes interface eth0 auf dem er mit dem Servernetz und unter anderem mit dem squid server verbunden ist (welcher selbst auch mit dem internet verbunden ist).

Auf dem interface eth1 ist er mit dem internet verbunden, sämtlicher an diesem interface ausgehender http traffic soll über den proxy server gehen.

ipv4 forwarding ist gesetzt:

1
2

cat /proc/sys/net/ipv4/ip_forward
1

Die Folgende Regel habe ich im Moment aktiv, allerdings leitet sie nur an das interne netz gerichteten http traffic um zum proxy. Ausgehender Internettraffic geht weiterhin direkt über eth1 ins internet.

1

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888

Quelle für diese Regel war: http://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource

Die quelle schlägt desweiteren folgende regel vor:

1

iptables -t nat -A OUTPUT --match owner --uid-owner squid -p tcp --dport 80 -j ACCEPT

Allerdings verstehe ich den match auf owner nicht, woher soll auf meinem AppServer der owner/initiator des Squid prozesses auf dem Squidserver kommen?

Nun habe ich folgende zwei adaptionen versucht, allerdings zeigen diese regeln dann keinen effekt mehr und kein traffic läuft mehr über den proxy:

1

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888 -o eth1 

1

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888 ! -d192.168.0.0/24 

Ich würde mich sehr freuen wenn ihr mir weiter helfen könnt, ich verzweifle langsam. Habe schon sämtliche google ergebnisse zu dem thema abgegrast und das ist das erste anzeichen von erfolg, alle anderen vorschläge die ich so fand zeigten garkeinen effekt.

Kai990 schrieb:

ich möchte allen auf einem AppServer anfallenden, ins Internet ausgehenden Traffic (http) direkt von diesem aus umleiten auf meinen squid server.

Dazu gibt es unter Linux viele Möglichkeiten, die besser sind, als ein Umschreiben der Pakete im Kernel. Beispielsweise die http_proxy Umgebungsvariable.

Die quelle schlägt desweiteren folgende regel vor:

1	iptables -t nat -A OUTPUT --match owner --uid-owner squid -p tcp --dport 80 -j ACCEPT

Allerdings verstehe ich den match auf owner nicht, woher soll auf meinem AppServer der owner/initiator des Squid prozesses auf dem Squidserver kommen?

Ich zitiere mal: This configuration is given for use on a single client box. Das heißt, Squid würde direkt mit auf der Maschine laufen. Andernfalls, da hast du Recht, kann der Client nicht wissen, welche UID Squid auf dem Server hat.

1	iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888 -o eth1

Diese Regel greift vermutlich nicht, weil du -o eth1 definiert hast. Das ist logisch falsch, weil lokal generierte Pakete an dieser Stelle noch nicht geroutet wurden. Daher weiß der Kernel auch noch nicht, zu welchem Interface das Paket raus gehen würde.

1	iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888 ! -d192.168.0.0/24

Hier bin ich nicht sicher, warum es nicht funktioniert. Eventuell greift die Regel gar nicht, weil eine vorherige schon gewirkt hat und diese damit hinfällig ist. Mittels

iptables -t nat -nvL

kannst du auch sehen, wie viele Pakete/Bytes bisher von der Regel betroffen waren.

Aus meiner Sicher, wäre es außerdem sauberer, policy-basiertes Routing als Lösung für dein Problem zu verwenden. Selbiges ist hier beschrieben.

misterunknown schrieb:

Dazu gibt es unter Linux viele Möglichkeiten, die besser sind, als ein Umschreiben der Pakete im Kernel. Beispielsweise die http_proxy Umgebungsvariable.

http_proxy wird von unseren applikationen leider ignoriert, ich habe bereits viele tage damit verbracht es zum laufen zu bekommen, ohne erfolg.

Die quelle schlägt desweiteren folgende regel vor:

1	iptables -t nat -A OUTPUT --match owner --uid-owner squid -p tcp --dport 80 -j ACCEPT

Allerdings verstehe ich den match auf owner nicht, woher soll auf meinem AppServer der owner/initiator des Squid prozesses auf dem Squidserver kommen?

Ich zitiere mal: This configuration is given for use on a single client box. Das heißt, Squid würde direkt mit auf der Maschine laufen. Andernfalls, da hast du Recht, kann der Client nicht wissen, welche UID Squid auf dem Server hat.

Ich hatte das eher so verstanden dass ich eine einzelne "client" box hab die outgoing connections produziert die auf jeden fall über die squid maschine laufen müssen. Habe das Regelwerk soeben auch auf der squid box ausprobiert, es wäre auch eine denkbare lösung squid auf der selben maschine zu haben. Allerdings werden dann auch nur interne verbindungen über squid geroutet.

1	iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888 ! -d192.168.0.0/24

Hier bin ich nicht sicher, warum es nicht funktioniert. Eventuell greift die Regel gar nicht, weil eine vorherige schon gewirkt hat und diese damit hinfällig ist. Mittels

iptables -t nat -nvL

kannst du auch sehen, wie viele Pakete/Bytes bisher von der Regel betroffen waren.

Danke.

Ich habe nun folgende Regel aktiviert:

1

iptables -t nat -A OUTPUT -s 88.88.88.88 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888 

wobei 88.88.88.88 die public ip des servers ist. Rufe ich nun google mit curl www.google.de ab, dann erhalte ich die google seite und der output von iptables -t nat -nvL zeigt folgenden output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Chain PREROUTING (policy ACCEPT 2 packets, 112 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 2 packets, 112 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1 packets, 59 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  *      *       88.88.88.88        0.0.0.0/0            tcp dpt:80 to:192.168.0.155:8888

Chain POSTROUTING (policy ACCEPT 1 packets, 59 bytes)
 pkts bytes target     prot opt in     out     source               destination

(ich habe es mehrfach überprüft, das eine paket in der output chain ist tatsächlich von curl.)

Jedoch taucht im log des proxys nichts auf und auch wird die seite erfolgreich abgerufen obwohl die ACLs des Proxy das im moment (zu testzwecken) verbieten.

Aus meiner Sicher, wäre es außerdem sauberer, policy-basiertes Routing als Lösung für dein Problem zu verwenden. Selbiges ist hier beschrieben.

Danke, der artikel bezieht sich aber auf einen router. Es gibt allerdings keinen router in diesem setup. Server 1 produziert ausgehende verbindungen, Server 2 hat squid, Server 1 soll nun alles was an port 80 ins internet geroutet wird über das interne netzwerk auf server 2's squidport routen

Kai990 schrieb:

http_proxy wird von unseren applikationen leider ignoriert, ich habe bereits viele tage damit verbracht es zum laufen zu bekommen, ohne erfolg.

Was sind das für Applikationen?

Ich habe nun folgende Regel aktiviert:

1	iptables -t nat -A OUTPUT -s 88.88.88.88 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888

Wozu die Source-Adresse? Machs einfach so:

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888

Danke, der artikel bezieht sich aber auf einen router. Es gibt allerdings keinen router in diesem setup. Server 1 produziert ausgehende verbindungen, Server 2 hat squid, Server 1 soll nun alles was an port 80 ins internet geroutet wird über das interne netzwerk auf server 2's squidport routen

Dein PC ist auch ein Router. Alle Konfigurationen kannst du unter einem normalen Linux machen.

misterunknown schrieb:

Kai990 schrieb:

http_proxy wird von unseren applikationen leider ignoriert, ich habe bereits viele tage damit verbracht es zum laufen zu bekommen, ohne erfolg.

Was sind das für Applikationen?

XML transformationen in coldfusion (lucee) via Java und tomcat. Allerdings werden alle versuche, auch über java optionen, tomcat optionen und sämtliche andere proxyoptionen ignoriert.

Ich habe nun folgende Regel aktiviert:

1	iptables -t nat -A OUTPUT -s 88.88.88.88 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888

Wozu die Source-Adresse? Machs einfach so:

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888

Wenn ich diese Regel aktiviere wird nur der interne traffic an den proxy geleitet, wie zb:

curl 192.168.0.123/index.html

Also genau das Gegenteil.

curl www.google.de

läuft bspw. weiter direkt ins internet.

Danke, der artikel bezieht sich aber auf einen router. Es gibt allerdings keinen router in diesem setup. Server 1 produziert ausgehende verbindungen, Server 2 hat squid, Server 1 soll nun alles was an port 80 ins internet geroutet wird über das interne netzwerk auf server 2's squidport routen

Dein PC ist auch ein Router. Alle Konfigurationen kannst du unter einem normalen Linux machen.

Ja er ist ein Router, sicher, aber es gibt doch einen unterschied ob ich traffic der über die netzwerkinterfaces läuft umrouten möchte, oder traffic der auf dem server selbst von einer application erzeugt wird auf einen anderen server umleiten möchte, oder?

Der Vollständigkeit halber:

• Es gibt viele Möglichkeiten, Applikationen mehr oder weniger brutal zu zwingen einen Proxy zu nutzen (so, oder so).

• HTTPS funktioniert so generell nicht. Das heißt, wenn deine Applikation auch HTTPS nutzt, kannst du diese Methode nicht nutzen.

Kai990 schrieb:

XML transformationen in coldfusion (lucee) via Java und tomcat. Allerdings werden alle versuche, auch über java optionen, tomcat optionen und sämtliche andere proxyoptionen ignoriert.

Das kann ich mir nicht vorstellen. Hast du IPv6 aktiv?

curl www.google.de läuft bspw. weiter direkt ins internet.

Vermutlich läuft auch das über IPv6. Du kannst dafür ip6tables nutzen, oder IPv6 deaktivieren.

Ja er ist ein Router, sicher, aber es gibt doch einen unterschied ob ich traffic der über die netzwerkinterfaces läuft umrouten möchte, oder traffic der auf dem server selbst von einer application erzeugt wird auf einen anderen server umleiten möchte, oder?

Nö, routing ist routing. Sobald ip_forward auf 1 steht, ist dein System ein Router und kann damit auch potentiell von allen Geräten als Gateway genutzt werden.

misterunknown schrieb:

Kai990 schrieb:

XML transformationen in coldfusion (lucee) via Java und tomcat. Allerdings werden alle versuche, auch über java optionen, tomcat optionen und sämtliche andere proxyoptionen ignoriert.

Das kann ich mir nicht vorstellen. Hast du IPv6 aktiv?

Nein, hatte es zum testen deaktiviert. Habe es gerade erneut deaktiviert und erneut getestet. Sämtliche proxyeinstellungen werden übergangen. einzig die proxyeinstellung im funktionsaufruf von CFHTTP funktioniert, dies ist so aber in der applikation nicht umsetzbar, da keine cfhttp aufrufe verwendet werden.

curl www.google.de läuft bspw. weiter direkt ins internet.

Vermutlich läuft auch das über IPv6. Du kannst dafür ip6tables nutzen, oder IPv6 deaktivieren.

Ipv6 deaktiviert und mit nachfolgender iptables regel erneut getestet, curl www.google.de oder curl http://172.217.21.99 (google ip) werden nun nicht mehr aufgerufen. Immernoch keine einträge im squid log

1

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.155:8888

Ja er ist ein Router, sicher, aber es gibt doch einen unterschied ob ich traffic der über die netzwerkinterfaces läuft umrouten möchte, oder traffic der auf dem server selbst von einer application erzeugt wird auf einen anderen server umleiten möchte, oder?

Nö, routing ist routing. Sobald ip_forward auf 1 steht, ist dein System ein Router und kann damit auch potentiell von allen Geräten als Gateway genutzt werden.

Ok, aber eigentlich soll daraus kein gateway werden. Das wäre wohl die allerletzte notlösung, aber eigentlich soll wirklich nur der ausgehende port 80 traffic umgeleitet werden. Port 443 war eigentlich auch geplant, ist aber eher unwichtig.

Ich habe nun mal

http://www.chiark.greenend.org.uk/~peterb/linux/socksproxy/

befolgt. Das archiv geladen und mit make gebaut.

1
2
3
4
5
6

root@server:/home/lucee/socksproxy# export LD_PRELOAD=/home/user/socksproxy/socksproxy.so 
root@server:/home/lucee/socksproxy# export SOCKS_PROXY_NETWORK=0.0.0.0                
root@server:/home/lucee/socksproxy# export SOCKS_PROXY_USERNAME=                      
root@server:/home/lucee/socksproxy# export SOCKS_PROXY_PORT=8888  

ssh -2 -N -f user@192.168.0.155 -D 8888 

Dann habe ich den lucee server und damit tomcat und die jvm neugestartet.

Ping war nun garnicht mehr möglich:

1
2

root@server:/home/user/socksproxy# ping www.google.de                                    
ping: symbol lookup error: /home/user/socksproxy/socksproxy.so: undefined symbol: dlsym

Und der lucee server machte weiterhin ungehindert verbindungen direkt ins internet.

Ok ich habe gerade das adressbinding des squid http intercept ports aufgehoben so dass er an allen interfaces verfügbar ist und die vorhin erwähnte iptables regel mit der externen ip des squid servers aufgerufen:

1

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 55.55.55.55:8888 

Rufe ich nun mit curl google und ähnliche externe seiten ab, so laufen sie über den squidserver wie gewünscht.

Natürlich ist es aber aus sicherheitsgründen als lösung undenkbar den squid port ins internet zu öffnen. Aber vielleicht hilft das irgendwie weiter?

Kai990 schrieb:

1	iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 55.55.55.55:8888

Rufe ich nun mit curl google und ähnliche externe seiten ab, so laufen sie über den squidserver wie gewünscht.

Na dann läuft das doch.

Natürlich ist es aber aus sicherheitsgründen als lösung undenkbar den squid port ins internet zu öffnen. Aber vielleicht hilft das irgendwie weiter?

Nun, offenbar hattest du noch vorher noch einen Fehler beim Umleiten auf die interne IP des Squid drin. Wie sieht das Routing bei dir aus? Ist der Port 8888 von Squid korrekt gebunden? Im Zweifelsfall kannst du auch mit tcpdump nachschauen, welche Pakete wohin gehen.

misterunknown schrieb:

Kai990 schrieb:

1	iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 55.55.55.55:8888

Rufe ich nun mit curl google und ähnliche externe seiten ab, so laufen sie über den squidserver wie gewünscht.

Na dann läuft das doch.

Natürlich ist es aber aus sicherheitsgründen als lösung undenkbar den squid port ins internet zu öffnen. Aber vielleicht hilft das irgendwie weiter?

Nun, offenbar hattest du noch vorher noch einen Fehler beim Umleiten auf die interne IP des Squid drin. Wie sieht das Routing bei dir aus?

Ist der Port 8888 von Squid korrekt gebunden? Im Zweifelsfall kannst du auch mit tcpdump nachschauen, welche Pakete wohin gehen.

Der interne Port ist wie folgt gebunden in der squid.conf:

http_port 192.168.0.155:8888 intercept

nmap 192.168.0.155 -p 8888 auf squidserver zeigt:

1
2

PORT      STATE SERVICE                                                                             
8888/tcp open  unknown

Nicht über das "unknown" bei port 8888 wundern, ich schreibe den port aus sicherheitsgründen in jedem post händisch um.

nmap localhost -p 8888 zeigt:

1
2

PORT      STATE  SERVICE                                                                            
8888/tcp closed unknown 

nmap 55.55.55.55 -p 8888 zeigt:

1
2

PORT      STATE  SERVICE                                                                            
28888/tcp closed unknown  

route auf dem applikationsserver zeigt:

1
2
3
4
5
6

Kernel IP routing table                                                                             
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface                       
default         gateway.rechenzentrum.de 0.0.0.0         UG    0      0        0 eth1                        
192.168.0.0    *               255.255.255.0   U     0      0        0 eth0                       
192.178.0.0    192.168.0.1    255.255.255.0   UG    0      0        0 eth0                        
55.55.55.55   *               255.255.255.192 U     0      0        0 eth1    

mit tcpdump während curl www.google läuft sieht man dass die anfrage tatsächlich an den squidserver weitergeleitet wird:

1
2
3
4
5
6

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes                            
17:38:00.933847 IP gateway.rechenzentrum.de.49420 > 192.168.0.155.8888: Flags [S], seq 561852773, win 
29200, options [mss 1460,sackOK,TS val 43609663 ecr 0,nop,wscale 7], length 0                       
17:38:01.930671 IP gateway.rechenzentrum.de.49420 > 192.168.0.155.8888: Flags [S], seq 561852773, win 29200, options [mss 1460,sackOK,TS val 43609913 ecr 0,nop,wscale 7], length 0                       
17:38:03.934685 IP gateway.rechenzentrum.de.49420 > 192.168.0.155.8888: Flags [S], seq 561852773, win 
29200, options [mss 1460,sackOK,TS val 43610414 ecr 0,nop,wscale 7], length 0 

auch tcpdump auf squidserver zeigt die pakete:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes                            
17:40:04.807090 IP gateway.rechenzentrum.de.44101 > 192.168.0.155.8888: Flags [S], seq 1125811824, win
 29200, options [mss 1460,sackOK,TS val 43640632 ecr 0,nop,wscale 7], length 0                      
17:40:07.409206 IP gateway.rechenzentrum.de.49426 > 192.168.0.155.8888: Flags [S], seq 367272809, win 
29200, options [mss 1460,sackOK,TS val 43641282 ecr 0,nop,wscale 7], length 0                       
17:40:08.407089 IP gateway.rechenzentrum.de.49426 > 192.168.0.155.8888: Flags [S], seq 367272809, win 
29200, options [mss 1460,sackOK,TS val 43641532 ecr 0,nop,wscale 7], length 0                       
17:40:08.815027 IP gateway.rechenzentrum.de.44101 > 192.168.0.155.8888: Flags [S], seq 1125811824, win 29200, options [mss 1460,sackOK,TS val 43641634 ecr 0,nop,wscale 7], length 0                      
17:40:10.411170 IP gateway.rechenzentrum.de.49426 > 192.168.0.155.8888: Flags [S], seq 367272809, win 
29200, options [mss 1460,sackOK,TS val 43642033 ecr 0,nop,wscale 7], length 0   

interessant ist, dass hier als hostname für den applikationsserver plötzlich der selbe dns name wie das gateway verwendet wird.

auch nslookup zeigt für die externe server ip den selben hostname an wie für den in /etc/network/interfaces konfigurierten internet gateway.

Daher habe ich auf beiden servern einen hosts eintrag angelegt mit der externen IP des appservers und dem eigentlichen Hostname.

Auch habe ich die externe ip des appservers in den acls des proxy erlaubt.

Trotz alldem wird vom proxyserver nichts dergleichen geloggt.

Kann es sein dass ich die absender-ip in iptables "umschreiben" muss von der externen ip des appservers auf die interne ip des appservers? Wenn ja, wie würde ich das erzielen?

Ich habe die iptables regeln nun um folgendes eränzt:

iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.0.20

um die absenderadresse auf die interne adresse des appservers umzuschreiben.

Nun kann ich die externe ip von google curlen:

1

curl http://172.217.21.99/ 

Und es landet tatsächlich im proxy 😀

Leider schafft curl es nicht eine Seite anhand der domain aufzurufen:

1

curl http://www.linuxquestions.org

geht ins leere und wird auch nicht vom proxy geloggt.

Edit:

Habe die SNAT regel erweitert:

1

iptables -t nat -A POSTROUTING -p tcp --dport 80 -j SNAT --to-source 192.168.0.20

nun funktioniert der ping auf www.google.de wieder, allerdings läuft curl auf google.de sowie auf ip nun wieder ins leere

Edit2:

Nochmal ein update für die SNAT Regel:

1
2

iptables -t nat -A POSTROUTING -p tcp --dport 28888 -j SNAT --to-source 10.200.100.120

Nun wird auch curl google.de über den proxy aufgelöst! Den Feierabend hab ich mir nun verdient. Morgen noch die squid config etwas aufbereiten.

Danke für deine vielen Tipps und Denkansätze!

Ein guter Gedanke. An die Rückroute hab ich gar nicht gedacht. Allerdings brauchst du da kein SNAT (die Regel ist eh zu allgemein, was vrmtl. Auch deine probleme verursacht. Mach einfach das:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 

Entweder MASQUERADE oder MASQUERADING da bin ich nicht sicher, schreibe grade mit dem Smartphone.