VPN-Router mit Raspberry

[RedSkall]

Hi Leute,

den Aufbau des Netzwerkes sehr ihr im Anhang.

Meine Absicht ist es des Verkehr aus dem Heimnetz über einen VPN laufen zu lassen. Dazu will ich ein Raspberry Pi B einsetzen. Das besondere ist dass ein PC im Heimnetz teilweise vom Internet aus erreichbar sein soll: z.B. dessen FTP-Server.

Dazu hatte ich bisher (Gleicher Netzwerkaufbau, nur ohne den Raspberry) ein Portforwarding in der Fritzbox eingerichtet.

So wie ich es sehe muss ich dazu folgendes konfigurieren:

• Fritzbox-Portweiterleitung auf Raspberry
• iptables-Eintrag im Raspberry zur Weiterleitung auf den entsprechenden PC (MASQUERADE ?)

Jetzt meine Fragen dazu:

• Wäre mein Vorgehen technisch korrekt?
• Oder gibt es einen besseren Lösungsansatz um das Vorhaben durchzusetzen?
  Hatte da schon dran gedacht den Raspberry direkt an den DSL-Anschluss und die Fritzbox raus schmeissen. Dann müsste ich nur ein Gerät konfigurieren. Wäre dafür die Hardware vom Raspberry überhaupt ausreichend?

Danke und Gruß,
Marco

 

[HominiLupus]

Die Fritzbox kann auch als VPN Server oder Client fungieren. Die FB durch den RPi zu ersetzen geht nicht.

Was für einen VPN Service ist es denn? Wie willst du die Verbindung zum RPi gestalten? SOCKS? Transparenter Zwangsproxy?

 

[Clcreative]

Ein Raspberry Pi hat doch nur ein RJ45 Modul 100Mbit oder? Schlechte Idee...

Ich hatte mal geschaut, es gibt dieses Banana-Pi R1, das hat 5x RJ45. Damit könntest du sowas machen, das hab ich mal für mich vor zum basteln

Da musst du genau wissen was du tust.

Aber theoretisch wäre es machbar.

 

[Cokocool]

Klingt nach einer guten Idee um sein Netzwerk/Internet richtig schön langsam zu machen.

Richte dir eine DMZ für den FTP Server ein

 

[CeleronD]

https://gist.github.com/superjamie/ac55b6d2c080582a3e64

 

[RedSkall]

So ähnlich wie auf Github beschrieben habe ich den Raspberry auch schon eingerichtet.
Das Routing des Netzwerks ins VPN läuft auch schon.

ich suche nur eine elegante Möglichkeit meinen FTP-Server über das öffentliche Netz erreichbar zu haben...

 

[thebackfisch]

Ja, kann man so machen. Ich würde noch zusätzlich zur oben geposteten Anleitung den DHCP-Server der Fritzbox deaktivieren und einen auf dem Pi installieren, damit die Clienten gleich die richtigen Einstellungen bekommen.

Wie soll denn der Rechner erreichbar sein? Von der öffentlichen Adresse der Fritzbox oder von einer Adresse aus dem VPN? Wenn Fritzbox, Pi und Clienten im gleichen Netzwerk sind und der PC über die öffentliche Adresse der Fritzbox erreichbar sein soll, dann genügt eine einfache Portweiterleitung in der Fritzbox.

 

[RedSkall]

Die Einstellungen lasse ich bereits per DHCP die die Clients verteilen.

Der Router hat einen DNS und der FTP-Server auf dem PC soll über diesen Router erreichbar sein.

Das mit der Portweiterleitung funktioniert noch nicht..
Hab es jetzt erstmal so versucht wie du beschrieben hast:


So habe ich nicht mal Internet zum Laufen bekommen - kommt mir auch komisch vor..!?

 

[Clcreative]

Ich nehme an dein FTP Server ist die 192.168.0.100? In dem Fall brauchst du nur eine Weiterleitung von Port 21 auf 21 an die 192.168.0.100 auf der Fritzbox (+ Highports für den Aktivmodus)

Btw. Deine Netzskizze ist falsch: dein Raspberry ist streng genommen kein Bindeglied zwischen Switch und Router sondern ein normaler Client am Switch. Vllt hilft dir das bei der Logik

 

[RedSkall]

Ja genau. Die Weiterleitung vom Router auf 192.168.0.100 ist auch eingerichtet. Aber die FTP Verbindung kann nicht aufgebaut werden..

Ich sehe im FTP-Server-Log dass die Anfragen rein kommen. Da der PC des FTP-Servers im Gateway den Pi stehen hat werden die Anfragen doch sicher falsch adressiert werden!? Fehlt da denn nicht noch ne Weiterleitung vom Pi zum Router?

Kommt mir auch so vor als ob ich da noch nen Logik-Problem habe

 

[Clcreative]

Was ist das Standartgateway des FTP Server
Edit: zu blöd zum lesen, hast du ja geschrieben xD

Die DNAT Rule schreibt nur die Destination um, nicht die Quelle. Das heißt das Paket kommt vom öffentlichen Client an die öffentliche IP der Fritz. Dann wird das Ziel auf die interne Adresse des FTP umgeschrieben. Der FTP Server antwortet der Quelle, da die Quelle eine öffentliche IP ist wird die Anfrage zu seinem Standartgateway geleitet.

Wenn das jetzt der Raspberry ist sollte er dieses Paket zu seinem Standartgateway senden sobald ihm keine weitere Route bekannt ist, hier wäre mal interessant ob im kernelmodul das Forwarding Flag gesetzt ist und hierfür iptables rules existieren. Achtung! FTP läuft nicht nur über Port 21 sondern die Datenkanäle laufen auch über highports, je nach aktiv/passiv Modus, hier wäre noch eine Regel für den nf_conntrack ftp helper sinnvoll

 

[RedSkall]

Wenn das jetzt der Raspberry ist sollte er dieses Paket zu seinem Standartgateway senden sobald ihm keine weitere Route bekannt ist

Da der Raspberry das VPN geöffnet hat wird er die Antwort über den VPN-Tunnel schicken!?

Es sind folgende Einträge definiert:

iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
iptables -A FORWARD -o tun1 -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -o eth0 -i tun1 -j ACCEPT

Gruß

 

[Clcreative]

Eins müssen wir ganz klar auseinander halten: DNAT macht nur Sinn wenn du KEIN VPN verwendest um auf den FTP zuzugreifen. Wenn du über die VPN Leitung gehst dann kannst du den FTP direkt über die private IP Adresse ansprechen und brauchst auf der Fritzbox kein Port Forwarding (DNAT).

Benutzt du den FTP über die VPN?

Schick mal noch den Output von:

ip r s

Und

ip ru s

Und

iptables -L

 

[RedSkall]

Der FTP Server soll nicht nicht über das VPN laufen, sondern direkt über meinen öffentlichen Internetanschluss.

Hier die Logs:

root@raspberrypi:~# ip r s
0.0.0.0/1 via 10.9.0.193 dev tun1 
default via 192.168.0.1 dev eth0 
default via 192.168.100.1 dev eth0  metric 202 
10.9.0.1 via 10.9.0.193 dev tun1 
10.9.0.193 dev tun1  proto kernel  scope link  src 10.9.0.194 
128.0.0.0/1 via 10.9.0.193 dev tun1 
176.126.237.217 via 192.168.0.1 dev eth0 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.2 
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.74  metric 202

Die 192.168.100.1 ist im Moment noch ein anderes VPN-Gateway im lokalen Netz was ich aber in der aktuellen (Test-) Konfiguration nicht benutze..

root@raspberrypi:~# ip ru s
0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default

root@raspberrypi:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

 

[Clcreative]

Entfern mal bitte testweise die 0.0.0.0/1 und 128.0.0.0/1 Regeln und schau mal obs dann geht.

Mach auch mal n tcpdump auf das interface tun1 und guck ob die Pakete zum ftp Client tatsächlich dort landen

 

[RedSkall]

Das hat geholfen

also den 0.0.0.0-Eintrag habe ich rusgeschmissen und es hat geklappt. Der tcpdump-log auf tun1 hat davor auch das "verlorene" paket enthalten..

der 0.0.0.0-Eintrag wird bei Aufbau der VPN-Verbindung immer wieder eingerichtet. Das bekomme ich als Client wahrscheinlich vom VPN-Server mit, oder?

Wie gehe ich jetzt am besten vor:
Den Eintrag bei jedem Verbindungsaufbau löschen?

 

[Clcreative]

Normalerweise werden die Routing Tabellen durch die Konfig gepusht, sprich der SSL VPN Server hat dir eine Konfgdatei erstellt, wo das eingestellt ist. Da musst du es entfernen und dann die Konfig neu einspielen.

Der Eintrag bewirkt, dass jeglicher Clienttraffic über die VPN geknödelt wird. Normalerweise ist das eine Option (Gateway umschreiben oder so ähnlich)

 

[thebackfisch]

Der Eintrag bewirkt, dass jeglicher Clienttraffic über die VPN geknödelt wird. Normalerweise ist das eine Option (Gateway umschreiben oder so ähnlich)

Aber genau das wollte er doch? Was wird denn noch ohne die beiden Einträge übers VPN geroutet? Eigentlich doch gar nichts mehr.

Warum der Verbindungsaufbau zum FTP-Server scheitert ist folgender:
Der TCP-Aufbau klappt nicht. TCP-Verbindungen sind eindeutig durch das Paar iport gekennzeichnet. Der Client sendet nun ein SYN an den Server im LAN, genauer gesagt zum Router, der die Ziel-IP dann passend zur internen Adresse umschreibt. Der Server antwortet mit einem SYN-ACK, das jedoch nicht über den Router läuft sondern durchs VPN geroutet wird und somit ganz andere NAT-Stationen durchläuft. Schließlich kommt es am Clienten an, jedoch mit falscher Quell-IP und/oder Port (nämlich der IP und Port der letzen NAT-Station). Der Client kann es nicht zuordnen, verwirft es und wartet vergeblich auf die Antwort vom Server.

Eigentlich ist dies ein ganz gutes Beispiel, warum NATs so böse sind

 

[RedSkall]

Glaube mit deiner Schlussfolgerung liegst du ganz richtig.

Das Entfernen der 0.0.0.0-Route kommt mir auch ein bischen "derbe" vor.

Ist es nicht besser ein Routing / Forwarding anzulegen dass bestimmte Anfragen aus dem lokalen Netz zum router und nicht durch den tunnel geleitet werden?
In diesem Fall würden z.B. Pakete der Quelle 192.168.0.100:900 direkt zum Router geschickt werden.

 

[Clcreative]

Willst du dass jeder Traffic über die VPN geroutet wird? Warum?

Es macht doch Sinn dass nur der Traffic durch die VPN geht, der auch für das entfernte Netz bestimmt ist.

(Eigentlich ist das der 'normale' Fall und nicht umgekehrt)

By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN. General web browsing, for example, will be accomplished with direct connections that bypass the VPN.

Ergänzend hierzu Vllt:


https://openvpn.net/index.php/open-source/documentation/howto.html

Routing all client traffic (including web-traffic) through the VPN