ubuntuusers.de

Hey Leute, Ich hab zu dem Thema schon viel gegoogelt und einige Hinweise gefunden, aber ich weiß nicht, wie ich alles korrekt "zusammen setzen", daher jetzt ein thread dazu.

Mein Anliegen: ich möchte meinen Server so konfigurieren, dass er wie ein Proxy im LAN funktioniert (wahrscheinlich mit squid), den Traffic aber durch ein VPN routet, was durch OpenVPN aufgebaut wird (iptables?). Wichtig ist, dass nicht die Verbindungen, die der Server selbst aufbaut, also lokaler Samba, apt get usw, durch das VPN laufen. Es könnte vielleicht einfacher sein, den Server komplett als Router zu konfigurieren und nur einen bestimmten IP Bereich (den ich am Client dann statisch oder per Mac Zuordnung dynamisch per DHCP vergeben würde) durch das VPN zu schicken. Ziel ist es, Geräte wie iPhone und Fernseher, die nicht ohne weiteres ein VPN unterstützen, trotzdem durch zu schicken.

Falls niemand eine Antwort weiß, kann mir vielleicht jemand zumindest ein Stichwort nennen?

Vielen Dank und viele Grüße Max

max.federbett schrieb:

Mein Anliegen: ich möchte meinen Server so konfigurieren, dass er wie ein Proxy im LAN funktioniert (wahrscheinlich mit squid), den Traffic aber durch ein VPN routet, was durch OpenVPN aufgebaut wird (iptables?). Wichtig ist, dass nicht die Verbindungen, die der Server selbst aufbaut, also lokaler Samba, apt get usw, durch das VPN laufen.

Das geht. Du kannst mit Squid eine tcp_outgoing_address definieren. Diese ausgehende Adresse ist dann dein Kriterium um das Routing durchs VPN zu konfigurieren. Im Umkehrschluss kannst du damit auch bestimmten Traffic der über den Squid geht nicht durchs VPN schicken, beispielsweise wenn Bandbreite ein Thema ist.

Es könnte vielleicht einfacher sein, den Server komplett als Router zu konfigurieren und nur einen bestimmten IP Bereich (den ich am Client dann statisch oder per Mac Zuordnung dynamisch per DHCP vergeben würde) durch das VPN zu schicken.

IMHO ist es nicht möglich, die ausgehenden Verbindungen von Squid anhängig von der tatsächlichen Client-IP zu routen, zumindest nicht mit iptables, denn dort ist die Client-IP ja nicht bekannt.

Also wenn ich das richtig verstanden habe, möchtest Du Clientverbindungen aus Deinem lokalen Netz per VPN weiterleiten? Wenn ja ist die Frage wohin bzw. von wo nach wo besteht die VPN Verbindung?

hoerianer schrieb:

Also wenn ich das richtig verstanden habe, möchtest Du Clientverbindungen aus Deinem lokalen Netz per VPN weiterleiten? Wenn ja ist die Frage wohin bzw. von wo nach wo besteht die VPN Verbindung?

Ja, genau. Mein iPhone zb soll eine Verbindung über ein VPN (CyberGhost ovpn) aufbauen, ohne dass es etwas dafür tun muss. Also abgesehen davon einen lokalen Proxy zu definieren.

Hab ich das also richtig so verstanden, dass ich in der server.conf des ovpn Servers einstelle, dass nur bestimmte Verbindungen geroutet werden und dann squid genau darauf verweisen lasse? Wie genau soll das funktionieren? Muss ich die TCP outgoing Adresse bei squid sozusagen auf eine fiktive IP legen, die ovpn dann wieder aufgreift?

Max

max.federbett schrieb:

Hab ich das also richtig so verstanden, dass ich in der server.conf des ovpn Servers einstelle, dass nur bestimmte Verbindungen geroutet werden und dann squid genau darauf verweisen lasse?

Wie sieht denn deine Server-Konfiguration aus? Falls du verschiedene zusätzliche Routen pushst, würde ich das wegkonfigurieren. Im Endeffekt brauchst du nur das funktionierende Tunnel-Interface auf dem Client. Dann kannst du Squid sagen, dass er standardmäßig als tcp_outgoing_adress eine IP aus dem VPN-Netz nehmen soll. Dann sollte der Traffic automatisch über den VPN-Server geroutet werden.

Wie genau soll das funktionieren? Muss ich die TCP outgoing Adresse bei squid sozusagen auf eine fiktive IP legen, die ovpn dann wieder aufgreift?

Keine fiktive IP. Vielleicht eine virtuelle, sofern du die IP die der Client sowieso kriegt nicht verwenden willst.

Angenommen dein Proxy-Server hat die IP 10.0.0.10 auf dem Tunnel-Interface (also 10.0.0.0/24 wäre das VPN-Netz), dann kannst du dem Squid entweder sagen, er soll mit dieser Adresse raus gehen (dann sollte alles automatisch durchs VPN gehen), oder du sagst einfach, dass du eine weitere IP-Adresse auf nem virtuellen Tunnel-Interface hast:

1

ifconfig tun0:0 10.0.0.11/24 up

Dann kannst die ausgehenden Squid-Verbindungen an diese Adresse hängen und hast damit eine IP nur für Squid (könnte für Accounting-Belange relevant sein). Eine Route, dass das VPN-Netz auch über das tun-Interface geroutet wird, sollte ja schon existieren. Wenn du letzteres verwendest, solltest du die IP natürlich bootfest konfigurieren.

Danke für die Antworten.

Ich habe nun einen funktionierenden VPN Client, der allerdings mit "nopull-routes", alle Routes ignoriert. Damit steht die Verbindung zu tun0 zwar und ich habe die IP aus dem VPN, allerdings werden die Verbindungen nicht darüber gesendet (mit traceroute überprüft). Anschließend habe ich squid3 konfiguriert, dass er alle eingehenden Verbindungen an die IP des tun0 Adapters senden soll:

http_port 192.168.0.xxx:3128 name=vpn1

acl conn_vpn1 myportname vpn1 src 192.168.0.0/24
http_access allow conn_vpn1
tcp_outgoing_address 10.8.1.6 conn_vpn1

Leider meldet Squid mir nur ein 110 Connection timeout, wenn ich mich nun über den entsprechenden Proxyport verbinde. Es gibt also immer noch ein Problem mit dem Routing... Weißt du weiter?

Viele Grüße Max

max.federbett schrieb:

Es gibt also immer noch ein Problem mit dem Routing... Weißt du weiter?

Was sagt

1
2
3

iptables -nL
route -n
ping 10.8.1.x # (IP des VPN-Servers)

Die iptables sind leer

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

#route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.1.5        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
10.8.1.1        10.8.1.5        255.255.255.255 UGH   0      0        0 tun0
10.8.1.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
77.21.xxx.xx    192.168.0.1     255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       10.8.1.5        128.0.0.0       UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.35.0    10.8.1.5        255.255.255.0   UG    0      0        0 tun0

Ping funktioniert.

Bei diesen Ausgaben ist das Routing von OVPN allerdings wieder aktiviert, gepushte Routen werden also übernommen. Leider funktioniert Squid selbst jetzt nicht. Ich dachte die ausgehenden Squid-Verbindungen sollten in diesem Fall auch geroutet werden... Sobald ich OVPN beende, leitet Squid alles durch.

max.federbett schrieb:

Ping funktioniert.

Dann funktioniert der Tunnel und das Routing.

Bei diesen Ausgaben ist das Routing von OVPN allerdings wieder aktiviert, gepushte Routen werden also übernommen.

Ja, so tragisch ist das nicht. Es ist für den Squid-Anwendungsfall nur nicht nötig.

Leider funktioniert Squid selbst jetzt nicht. Ich dachte die ausgehenden Squid-Verbindungen sollten in diesem Fall auch geroutet werden...

Ist auf dem VPN-Server IP-Routing aktiviert?

1

sudo sysctl -w net.ipv4.ip_forward=1

Sobald ich OVPN beende, leitet Squid alles durch.

Durch was?

Also der Server funktioniert normal, wenn ich mich einfach mit einem Client auf dem PC verbinde. Routing läuft also. Momentan benutze ich auch meinen eigenen ovpn Server, aber am Ende soll diese Aufgabe ja cyber ghost übernehmen. Ich kann also davon ausgehen, dass bei denen alles korrekt funktioniert. Sobald ich den VPN Client auf dem squid Server (ungleich VPN Server) beende, bekomme ich keinen timeout mehr und squid arbeitet normal, ein Client kann also eine Verbindung ins Internet aufbauen. Squid kann also aus irgendeinem Grund die Client Verbindungen nicht durch das VPN weiterleiten, selbst wenn das vollständige Routing aktiviert ist und die traceroute auf dem squid Server mit bestätigt, dass die Verbindungen durchs VPN laufen

max.federbett schrieb:

Sobald ich den VPN Client auf dem squid Server (ungleich VPN Server) beende, bekomme ich keinen timeout mehr und squid arbeitet normal, ein Client kann also eine Verbindung ins Internet aufbauen.

Also das kommt mir komisch vor. Squid sollte genau dann eigentlich nicht funktionieren, weil er für ausgehende Adressen ja die VPN-IP nimmt. Wenn der Tunnel dann nicht existiert, sollte es daher gerade nicht funktionieren.

Squid kann also aus irgendeinem Grund die Client Verbindungen nicht durch das VPN weiterleiten, selbst wenn das vollständige Routing aktiviert ist und die traceroute auf dem squid Server mit bestätigt, dass die Verbindungen durchs VPN laufen

Bist du dir sicher, dass der Proxy-Server durchs VPN ins Internet kommt (und nicht nur ins VPN-Netz)?

Ja, du hast Recht, das ist unlogisch. Ich habe einen Schritt gedanklich übersprungen. Was ich meinte ist, dass ich Squid wieder so konfiguriert habe, dass er "normal" ins Internet geht, also ohne outgoing ip. Anschließend habe ich eine VPN Verbindung aufgebaut und mittles Traceroute im Terminal überprüft, dass der Traffic tatsächlich durch das VPN läuft. Meine Überlegung war, dass Squid in der Standardkonfiguration nun auch durch das VPN laufen sollte, was er aber nicht tut: 110 Connection timeout. Dieser Fehler tritt auch auf, wenn ich das automatische Routing des VPNs unterbinde (nopull_route) und Squid per tcp_outgoing_ip auf das VPN verweise. Hier scheint also der Fehler zu sein.

misterunknown schrieb:

Bist du dir sicher, dass der Proxy-Server durchs VPN ins Internet kommt (und nicht nur ins VPN-Netz)?

Genau das ist ja das Problem. Ich verweise auf die IP des VPN Adapters, aber es funktioniert nicht.

Also ich habe mir das Setup mal nachgebaut und tatsächlich ist es nicht so trivial, wie es auf den ersten Blick aussieht. Ich hatte ehrlich gesagt noch nie ein OpenVPN konfiguriert aber dafür wars recht einfach, der Squid wollte aber trotzdem nicht... War bissl knifflig aber schlussendlich lags wie vermutet am Routing.

Routing unter Linux wird in der Regel zielbasiert gemacht. Man fügt eine Route für einen Zielhost oder ein Zielnetz hinzu, und der Kernel routet alle Pakete entsprechend. Daran ändert auch – und hier lag mein Denkfehler – die Quell-IP nichts. Das heißt Squid funktioniert nicht, weil er zwar mit der IP 10.8.1.6 sendet, die Pakete werden aber standardmäßig einfach ins Internet geroutet, so wie es das gewünschte Verhalten auf dem Server generell ist. Das Problem ist, dass ein privater Netzbereich im Internet nicht geroutet wird und die Pakete damit irgendwann irgendwo verworfen werden. Was wir nun brauchen ist also eine Regel, die das Routing abhängig von der Quell-IP festlegt.

Da der Kernel das natürlich schon kann ist klar, dass es dazu schon Regeln gibt. Daher ist es erstmal hilfreich zu sehen, welche Regeln aktuell greifen:

1
2
3
4

$ ip rule ls
0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 

Die Zahl am Anfang ist die Priorität in der die Regeln angewandt werden (first-match). Danach folgt die Bedinung ("from all"), und dann der Verweis auf die entsprechende Routing-Tabelle. Den Inhalt dieser Tabellen können wir uns so ansehen:

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

$ ip route list table local
broadcast 5.9.121.32 dev eth0  proto kernel  scope link  src 5.9.121.40 
local 5.9.121.40 dev eth0  proto kernel  scope host  src 5.9.121.40 
broadcast 5.9.121.63 dev eth0  proto kernel  scope link  src 5.9.121.40 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
$ ip route list table main
default via 5.9.121.33 dev eth0 
5.9.121.32/27 via 5.9.121.33 dev eth0 
5.9.121.32/27 dev eth0  proto kernel  scope link  src 5.9.121.40

Dort sind die entsprechenden Einträge fürs Routing drin. Wenn beispielsweise mit "route add" eine Route setzt, wird sie der Main-Tabelle hinzugefügt. Die Tabellen sind in der Datei /etc/iproute2/rt_tables hinterlegt. Was wir brauchen ist eine zusätzliche Routing-Tabelle:

1
2

# Routing-Tabelle mit ID 200 und dem Name "vpn_traffic" anlegen
echo "200 vpn_traffic" >> /etc/iproute2/rt_tables

Danach legen wir fest, dass diese Routing-Tabelle abhängig von einer bestimmten Absende-IP zum Einsatz kommt...

1

ip rule add from 10.8.1.6 table vpn_traffic

Und dann brauchen wir noch die eigentliche Route...

1

ip route add default dev tun0 table vpn_traffic

Kurz den Cache leeren...

1

ip route flush cache

Und fertig. Wenn Squid jetzt mit der IP 10.8.1.6 sendet, wird der Traffic durchs VPN geroutet. Auf der Gegenstelle muss natürlich korrektes NAT konfiguriert sein, aber das dürfte bei dir ja der Fall sein. Sag Bescheid obs funktioniert hat.

Wow! Vielen Dank für die ausführliche Erklärung und deinen Aufwand. Ich werde es gleich heute Abend ausprobieren und berichten!

Vielen vielen Dank! Das funktioniert super! Einzig das Problem, dass ich bei CyberGhost keine feste IP bekomme, muss ich noch in den Griff bekommen, aber das sollte sich mit einem kleinen Script machen lassen. Sind die Änderungen an den Routing Tabellen persistent oder muss ich sie noch beim reboot "manuell" hinzufügen?

Viele Grüße Max

EDIT: Hab es ausprobiert. Die Änderungen sind nicht persistent. Das ist gut, dann kann ich, sobald das VPN gestartet wurde per Script die Interface IP auslesen und damit die Routen setzen. So sollte alles mehr oder weniger automatisch funktionieren. Vielen, vielen Dank noch einmal für deine Mühe!