VPN-Router mit Raspberry

[RedSkall]

Ich will dass mein kompletter Internetverkehr verschlüsselt wird - ausgenommen z.B. der FTP Server

 

[thebackfisch]

Also mir fallen drei Möglichkeiten ein:

1. Den PC mit dem FTP-Server aus dem VPN herausnehmen und allen Traffic dieses PCs über den Router leiten.
2. Dem PC eine zweite IP zuweisen. Den FTP-Server an diese IP binden und dann mittel policy routing (source based routing) nur die Pakete von dieser IP über den Router leiten. Alles andere läuft dann übers VPN.
3. Auf dem Router einen FTP-Proxy installieren (bzw. gleich den FTP-Server der FritzBox verwenden).

 

[RedSkall]

also ich würde gerne möglichkeit 2 einrichten.

aber ich bekomme das routing einfach nicht eingestellt

ich habs jetzt mittels 'iptables' und auch 'ip rule' versucht..
Ich habe ja in meinem Router das Port-Forwarding auf meinen PC geleitet. an der Stelle ist der Raspberry ja aussen vor. ich muss doch blos die Pakete, die mein PC an das Gateway (also den Raspberry) schickt umleiten auf den Router!?

Wie stelle ich das genau ein!?

 

[Clcreative]

Hi, damit dürftest du das hinbekommen: http://blog.scottlowe.org/2013/05/29/a-quick-introduction-to-linux-policy-routing/

 

[RedSkall]

OMG! Es lag an mir.. ich hab bei einem command unsinn getippt....

Danke allen hier für die Hilfe!!

 

[Raijin]

Eine kleine Anmerkung: Es ist keine besonders gute Idee, den kompletten Internetverkehr zu tunneln. Zum einen wirkt die Verschlüsselung sowieso nur von dir zum VPN-Server und ab dort geht's ganz normal weiter, im Zweifelsfalle unverschlüsselt. D.h. die einzigen, die du "aussperrst" sind der Provider und die Hops vom Provider zum VPN-Anbieter.

Darüberhinaus wirst du dann grundsätzlich bei jeder ausgehenden Verbindung im Internet mit der WAN-IP des VPN-Anbieters unterwegs sein. Klingt anonym, ist es zT auch, aber das hat auch gravierende Nachteile. Netflix und diverse andere Streaming-Anbieter, Online-Shops, etc. haben einschlägige VPNs auf einer Blacklist stehen bzw. haben solche angekündigt. Wenn nun ein Service im Internet deinen VPN-Anbieter auf der Blacklist stehen hat, wirst du geblockt oder deine Bestellung wird nicht akzeptiert, etc.. Von der Einschränkung der Übertragungsrate möchte ich gar nicht erst anfangen. Auch Spielkonsolen wie die Playstation oder die Xbox können Probleme machen. Moderne Konsolen arbeiten auch mit direkten Konsole-zu-Konsole-Verbindungen (zB für Teamchat, Spielesessions, etc.). Auch das funktioniert über eine komplette VPN-Verbindung nicht. Hier müsste man also ebenso differenzieren und die Konsolen aus dem VPN-Setup rausnehmen (physikalisch, durch Gateway=Router oder durch PolicyBasedRouting (s.u.)).

So wie ich dein Setup verstehe, ist der Raspberry zudem nur ein normaler Client in deinem Subnetz. Stelt man am PC zB das Gateway manuell auf die Fritzbox, ist man normal über den Provider unterwegs. Demnach musst du zusehen, dass der DHCP-Server auch den PI als Gateway ausgibt. Consumer-Router bieten so eine Option in der Regel nicht, das GW ist dabei immer der Router selbst, d.h. du müsstest den PI als DHCP nehmen, falls noch nicht geschehen.

Ich persönlich würde das so nicht machen. Entweder nur selektiv VPN nutzen/nicht nutzen (zB bei Bedarf manuell das Gateway von .1 auf .2 umstellen) oder aber mit PBR arbeiten. Im PI kannst du mittels Policy Based Routing Kriterien definieren, nach denen ganz bestimmte Verbindungen via VPN oder via Router gehen sollen. So könnte man zB auf Basis der Quelle (also Gerät im LAN) routen. Beispielsweise "TV via Router" und "PC via VPN".



Im übrigen kann ich auch vom FTP-Server nur abraten. FTP arbeitet unverschlüsselt. Das geht soweit, dass sogar Logins in Klartext übertragen werden. Hängst du an einem öffentlichen Hotspot (Hotel, Flughafen, etc.) kann jeder Hans und Franz dein Passwort im WLAN mitschneiden. Schlechte Idee. Du solltest daher über SFTP bzw. FTPS nachdenken. Das sind verschlüsselte Varianten von FTP. Oder gar den Zugang ins heimische LAN komplett über einen VPN-Server im Router oder im PI einrichten. Dann baust du von außen eine VPN-Verbindung in dein Heimnetz auf - nicht zu verwechseln mit der Client-Verbindung des PI zum VPN-Anbieter! - und kannst nach Belieben auch unverschlüsseltes FTP verwenden, weil das von außen alles über den separaten VPN-Tunnel verschlüsselt wird.

 

[RedSkall]

Hi Raijin,

ich will den grundsätzlichen Internetverkehr über das VPN routen, aber es gibt ein par Ausnahmen (z.B. der FTP).

Hab das Script ja mittlerweile soweit dass ich beliebige Clients im Netzwerk über den normalen, unverschlüsselten Anschluss routen kann. Wenn ich z.B. Netflix gucken würde könnte ich das ja so machen.

Ich will darüber hinaus auch die Möglichkeit haben bestimmte Ports immer über die unverschlüsselte Verbindung (für alle Clients) zu routen - da sitze ich jetzt gerade dran: Siehe unten.

Ich habe den DHCP Server auch schon genau so eingestellt wie du sagtest: er verteilt die Konfiguration mit Gateway auf den Pi und bestimmten DNS Servern an alle Clients. Wenn jemand im lokalen Netz nicht die verschlüsselte Verbindung benutzen will kann er sich nen statisches Setup einstellen und sein Gateway auf den Router legen - das ist beabsichtigt.

Ich möchte alles über PBR machen, sodass ich so viel Einstellungen wie Möglich über den Pi laufen lassen kann.

Der FTP ist ein FTPS-Server genau gesagt.

----------------------------------

@bestimmte Ports immer über die unverschlüsselte Verbindung (für alle Clients):

Das versuche ich gerade mit:

echo 200 OpenTbl >> /etc/iproute2/rt_tables
ip route add default via 192.168.0.1 dev eth0 table OpenTbl

AddPort()
{
	iptables -A PREROUTING -t mangle -i eth0 -p tcp -m multiport --dports $1 -j MARK --set-mark 2  
	iptables -A OUTPUT -t mangle -p tcp -m multiport --dports $1 -j MARK --set-mark 2  
	iptables -A POSTROUTING -t nat -o eth0 -j SNAT --to-source 192.168.0.1

	ip rule add from all fwmark 2 table OpenTbl
}

'$1' sind die entsprechenden ports.

Ich glaube das klappt aber nicht. Wie kann ich jetzt prüfen ob wirklich Port 80 über die offene Verbindung geleitet wird?

Danke und Gruß

 

[Raijin]

Naja, wenn du es für sinnvoll hälst, alles zu tunneln und nur bestimmte Ausnahmen via Provider laufen zu lassen, ist das natürlich deine Sache. Ich halte das für absolut sinnfrei, weil die Nachteile in Summe überwiegen (zB reduzierte Bandbreite).

Meiner Meinung nach sollte man genau andersherum arbeiten. Genau die Anwendungen/Ports/Geräte via VPB tunneln, die man auch aus bestimmten Gründen tunneln möchte. Der Rest geht normal via Provider. Ansonsten schießt du mit Kanonen auf Spatzen und tunnelst jeden Sch*** obwohl das überhaupt nicht notwendig wäre bzw. sogar langsamer läuft.. zB ein Linux Image runterladen und dann schön vom VPN-Anbieter ausgebremst werden... Zudem wirkt das VPN wie gesagt sowieso nur bis zum VPN-Server und dahinter ist alles wie gehabt. Via VPN zu surfen, etc ist also keineswegs das ultimative Sicherheitsfeature


Mit tcpdump kannst du mitloggen welche Pakete durch das System laufen. So kannst du zB checken welche Pakete auf dem tun0 Interface bzw dem eth0 Interface den PI verlassen. Damit müsstest du das sehen können ob korrekt geroutet wird. Alternativ kannst bei iptables auch '-j LOG' einbauen, um Pakete zu loggen. Mach das aber nur temporär, weil das Log sonst sehr schnell sehr groß werden kann...

 

[RedSkall]

Also, ohne ne politische Diskussion starten zu wollen..
Ich will einfach nur vermeiden dass mein Internetanschluss ohne Probleme abgefangen werden kann. Daher will ich alles, bis auf Ausnahmen, über das VPN laufen lassen. Wenn ich dafür eine bessere Lösung finde dann überdenke ich die Sache und mache es vielleicht anders
Ich hatte bei mir noch nie schnelles Internet aber ich brauche es auch nicht. Für mich fallen Geschwindigkeitseinbußen nicht so sehr ins Gewicht.

Thanks wegen tcpdump und dem log - probiere ich aus..

 

[Clcreative]

Es gibt bessere Lösungen dafür: https z.B. ist ja nicht so als hätte niemand an sowas gedacht. Klar du kannst dir natürlich auch n Hut aus Alufolie basteln (Sry nicht böse nehmen) aber ich sehe das genau wie Raijin, es ist absolut sinnfrei.

Man muss sich ja auch mal vor Augen halten was da technisch passiert: Du tunnelst deinen Verkehr durch eine VPN, schön und gut. Aber wo geht der Traffic schlussendlich hin? Wo werden diese Daten verarbeitet? Und wie verarbeitet das Gegenüber die Daten?
Das sind alles Sachen die du nicht kontrollieren kannst.

Das ist ähnlich wie mit IMAP/POP3/SMTP Verschlüsselung, schön der Traffic zum Provider ist verschlüsselt, aber woher weißt du was der Provider anschließend damit treibt?

Dass du durch die VPN mehr "Sicherheit" bekommst ist eine Illusion. Sicher die Kommunikationen ab die kritisch sind und gehe sorgsam mit Technologien um, das ist alles was du tun musst m.E.

 

[Raijin]

Entscheidend ist ob man dem VPN Anbieter vertraut. Immer wieder liest man hier im Forum nämlich vom 'anonymen Surfen' damit 'der Provider nicht schnüffeln kann'. Letztendlich verlagert man aber das Schnüffelproblem nur vom Provider zum VPN-Anbieter.

Beispiel:

Provider = Telekom, 1&1, Vodafone, O2, etc
Firmensitz = Deutschland
Datenschutz = Deutschland

VPN-Anbieter = xy
Firmensitz = USA, Rumänien, Finnland, Russland, etc
Datenschutz = unbekannt

Der VPN-Anbieter kann nämlich exakt dasselbe sehen wie der Provider, weil die Verschlüsselung beim VPN-Server endet. Im worst case liest also die NSA direkt mit, weil die Firma in den USA sitzt


Wie dem auch sei, das muss jeder selbst wissen. Wenn du das so willst, ist das deine Sache. Ich wollte nur aufzeigen, dass es eben auch eine Kehrseite der Medaille gibt. Mein VPN (Cyberghost) starte ich nur bei Bedarf. Einmal hatte ich es vergessen und wollte bei einem Shop ein Spiel kaufen - ich glaube das war Steam. Daraufhin wurde meine Bestellung storniert und ich bekam eine Mail. Ein VPN wurde erkannt und ich solle doch bitte ohne VPN bestellen, um Mißbrauch vorzubeugen.

Keine Ahnung wieviele Seiten solche Blacklists pflegen und wie vollständig sie sind, aber eine Seite reicht ja schon, wenn es zu Problemen führt.

 

[RedSkall]

Jetzt ist die politische Diskussion doch da ^^

Ich habe ja extra die wörter "sicher" und "anonym" bewusst nicht benutzt - weil es das halt nicht ist.
Das einzige was ich erreichen will ist das nicht sichtbar ist was an Traffic (eMail, eBay, ...) an meiner Leitung (= mein Name) raus geht.
Ist schon ganz klar dass das kein Einfluss darauf hat wie Amazon meine Daten verarbeitet oder mein ISP usw.

 

[Clcreative]

War doch klar dass so ein Post zu dieser Diskussion führt

Aber im Prinzip ist eigentlich alles geklärt, technisch ist dir klar was läuft und über Sinn oder Unsinn kann man sich streiten. Ich persönlich hab da halt meine Sicht der Dinge, du eine andere. Das ist für mich vollkommen okay, Hauptsache man hat dir etwas helfen können.

 

[RedSkall]

So ist es ^^

Aber zu meinem Problem:
Ich kriege es einfach nicht richtig eingestellt.. Die Netzwerktopologie habe ich ja geschildert.

Der PC (192.168.0.100) baut eine Verbindung zu einem FTP im Internet auf. Der Traffic wird zu seinem Gateway geleitet (192.168.0.2 - der Raspberry). Der soll FTP-Traffic (Destination Port 21) aber nicht ins VPN leiten, sondern direkt zum Router (192.168.0.1).

Die Antwort vom FTP aus dem Internet kommt zum Router zurück, der sie dann direkt weiter zum PC leitet.

Ich kriege diese Routing einfach nicht ans Laufen!?

 

[Raijin]

Aso, der FTP Server läuft nicht bei dir? Dann hab ich das falsch verstanden. Was ist das für ein FTP-Server im www? Hat er eine feste IP Adresse? Wenn ja, kannst du am Client-PC selbst oder aber am PI eine ganz normale Route zu dieser IP via Internetrouter einrichten. PBR bräuchte man dann nicht.

Hat der FTP-Server eine dynamische WAN-IP, ist das nicht ganz so einfach. Bekommt man portbasiertes PBR nicht hin, könnte man theoretisch ein Script schreiben, das per cron ausgeführt wird und zB eine DDNS Adresse prüft und anhand dessen eine Route zum FTP aktualisiert.


Zur Analyse kannst du wie gesagt am PI zB mit tcpdump den Traffic loggen. Am Client PC mit WireShark. Im Idealfall könnte man noch am Internetrouter loggen, um zu sehen ob der Traffic über den PI auch dort ankommt.

 

[RedSkall]

Das ist jetzt ein weiterer Anwendungsfall (Siehe Grafik), hätte ich deutlicher sagen können..

Im Ausnahmefall soll der Pi den Traffik einfach nur an den Router weiterleiten. Im normalfall leitet der Pi alles über den VPN-Server.

Routen anlegen geht aber nur für Hosts, nicht für Ports, richtig?


Zur Diskussion nochmal:
Anbieter werben doch damit den kompletten Internetverkehr über VPN laufen zu lassen - das ist doch keine exotische Ausnahme!?

 

[Clcreative]

Kurze Frage: Ist dir klar wie der FTP Verbindungssaufbau ist und was ein aktiv/passiv Modus ist?

 

[Raijin]

Normales Routing ist ausschließlich Ziel-IP-basiert. Ich hatte das nur erwähnt falls der FTP-Server eine feste IP hat - zB in der Firma. Dann könntest du alles per default gateway via VPN routen und eine extra Route nach 11.22.33.44 (die FTP-IP) via Fritzbox routen. PBR bräuchtest du dann nicht, weil einfach alle Verbindungen zu dieser IP unabhängig vom Port geroutet werden.

PBR braucht man nur, wenn man nach anderen Kriterien als der Ziel-IP routen will. Das kann zB der Ziel-Port sein (zB 21) und dann wird jeder FTP-Server so geroutet, weil Port 21 der Trigger ist (wobei man noch active/passive bedenken muss, also ggfs noch Port 20 bzw den Data Port des FTP-Servers routen). Man kann mit PBR aber zB auch nach der Quell-IP routen, d.h. PC1 via VPN und PC2 via Fritzbox. Oder beliebige andere Kriterien.


Alles via VPN: Klar werben sie damit. Das Ding ist aber wie man das einsetzt. Gemeint ist damit in der Regel nicht, das im Router für 24/7 das ganze Jahr über zu nutzen, sondern nur für die Dauer der Verbindung. "Alles" ist in dem Fall also eher definiert als "Alles was du jetzt gerade tust" und nicht "alles was du für den Rest deines Lebens irgendwo in deinem Netzwerk tust"

Versteh mich nicht falsch, ich habe auch eine ständige Verbondung zu Cyberghost VPN über meinen Linux Server, aber ich selektiere am PC per Batch das Default Gateway, wenn ich explizit über das VPN surfen will.


Übrigens: Im Idealfall würdest du statt dem PI einen richtigen Router einsetzen, zB einen EdgeRouter-X von Ubiquiti (50€). Der wäre dann das Bindeglied zwischen Fritzbox und Netzwerk und die Fritze wäre dann nicht direkt erreichbar, sondern nur über den ER-X. Weiche Setups wie deins neigen dazu, schlecht wartbar zu sein. Wenn zB der PC direkt die Fritzbox als GW wählt (zB wegen einer Route in der Routingtabelle), ist dein PI komplett ausgehebelt und du merkst das unter Umständen überhaupt nicht.
Ferner solltest du dir Gedanken darüber machen was passiert, wenn die VPN-Verbindung am PI weg ist. Entweder wird deine Internetverbindung dann vollständig geblockt, weil der PI routen will, aber das VPN-Gateway nicht erreichbar ist, oder aber der PI geht dazu über, dann alles ungefiltert an die Fritzbox zu leiten. Das kommt auf die Konfiguration an und was du am Ende willst. Quasi ein Failover Szenario.

 

[RedSkall]

Der FTP, hier als Beispiel, ist nicht ganz gut gewählt. Es geht mir vorrangig um Anwendungen die schnell sein müssen - z.B. würde ich das dann für irgendwelche Spiele so einstellen, die hier so gespielt werden.

PBR braucht man nur, wenn man nach anderen Kriterien als der Ziel-IP routen will. Das kann zB der Ziel-Port sein

Genau so solls sein. Wie gesagt - vergesst FTP als Beispiel, mir gehts nur ums Prinzip.

ich habe auch eine ständige Verbondung zu Cyberghost VPN über meinen Linux Server, aber ich selektiere am PC per Batch das Default Gateway, wenn ich explizit über das VPN surfen will

Genau so habe ich es bisher auch gemacht. Aber ich bin der einzige hier am Internetanschluss der sich Gedanken über sein Surf-Verhalten macht. Und da denke ich dass nicht jeder mitkriegen muss was hier so über unsere Leitung läuft - das ist der ganze Hintergrund.
Und desswegen habe ich mir gesagt: Der Standard-Weg soll über VPN sein, und wer es gerade nicht braucht (werde eigentlich nur ich sein) legt sein Gateway weiterhin auf den Router und nicht aufs VPN/Raspberry.

 

[Raijin]

Naja, PBR setzt aber entsprechende Kenntnis der Netzwerkkommunikation voraus. Heißt im Klartext: Du kannst zB Spiele nicht so ohne weiteres mit PBR abfrühstücken, weil Server-IPs sich auch mal ändern können und die Ports nur bedingt dokumentiert sind. Wenn ein Spiel aus welchen Gründen auch immer zB auch eine Verbindung auf TCP 443 herstellt, ist das der https-Port. Wenn du den per PBR anders routest, würdest du zB auch Online-Banking, Internetshops und zB auch computerbase.de so routen, weil dort eben https verwendet wird. Werden gar dynamische Ports verwendet, also der Server gibt dir jedes Mal einen anderen Port, auf den du verbinden musst, dann wirds richtig haarig.

Das ist ja genau das Problem an der Sache. Willst du nicht nach Ziel-IP, sondern nach anderen Kriterien routen, musst du die Parameter der jeweiligen Verbindungen ganz genau kennen. Fehlen dir diese Informationen, kannst du mit PBR nicht ausreichend selektieren bzw. verpasst eben die Hälfte. Am Ende baut ein Spiel dann mehrere Verbindungen parallel her, die eine Hälfte über VPN, die andere über die Fritzbox. Wenn der Server nicht gut drauf ist, blockt er dann, weil deine Quell-IP nicht eindeutig ist.


Eine weitere Alternative wäre evtl. eine Software-Lösung mit ForceBindIP. Selbst habe ich das Tool noch nicht genutzt, aber es verspricht, Anwendungen speziell an ein Netzwerkinterface zu binden. D.h. man könnte zB Call of Duty sagen, dass es über LAN1 und der Rest über LAN2 gehen soll. An LAN1 hängt dann das Kabel zur Fritzbox, an LAN2 das Kabel zum PI - 2 LAN-Schnittstellen und/oder ein WLAN-Adapter vorausgesetzt. Einen Versuch ist es wert. Wenn das so klappt, würden nämlich alle Verbindungen, die von der game.exe gestartet werden, über das entsprechende Interface laufen und an das jeweilige Default Gateway geschickt werden.
Ob das auch auf einem LAN-Interface mit mehreren IP-Adressen funktioniert, weiß ich nicht. Dazu kenne ich das Tool nicht gut genug. Ich vermute aber, dass man 2 Interfaces braucht, zB 2x LAN oder 1x LAN + 1x WLAN.


Wie du siehst, ist das alles andere als trivial. Wenn du dir zB ein neues Game bzw. eine beliebige Anwendung kaufst, die du ebenfalls anders routen willst, musst du erstmal die Ports, etc. rausfinden und am PI frickeln. Die Wartbarkeit ist also bestenfalls befriedigend..