Discussion:
VPN nur für eine IP-Adresse
(zu alt für eine Antwort)
Peter Dunkel
2015-07-29 12:41:24 UTC
Permalink
Hallo!
Seit vielen Jahren nutze ich ipsec, um mich von unterwegs mit meiner
FritzBox zu hause zu verbinden.
Seit OSX 10.10 lief das Tool leider nicht mehr und ich habe die VPN
Verbindung über die Systemeinstellung / Netzwerk aufgebaut.

Läuft auch ohne Probleme, nur leider immer der gesamte Traffic, damit
ist der Uplink meiner Fritzbox das Nadelöhr.

Ich suche also eine Lösung, dass der Traffic zu meiner Fritzbox (und
wenn möglich dem Online-Banking) über VPN, der restliche Traffic direkt
ohne VPN erfolgt.

Ich habe auch schon eine Datei /etc/ppp/ip-up erstellt und verschiedene
Einstallungen, z.B.

/sbin/route add -net 192.168.1.0/16 -interface ppp0

verwendete (natürlich habe ich 192.168.x.0/16 angepasst).

In einer Anleitung fand ich ' unchecked the Advanced VPN setting "Send
all traffic over VPN connection"', nur finde ich unter 10.10 die
Checkbox nicht.

Hat jemand ein Kochrezept?

Besten Dank
Peter
Marcus Jodorf
2015-07-30 19:18:32 UTC
Permalink
Post by Peter Dunkel
Seit OSX 10.10 lief das Tool leider nicht mehr und ich habe die VPN
Verbindung über die Systemeinstellung / Netzwerk aufgebaut.
Wenn Du da „Cisco IPSec“ nimmst, sollte das normal einfach tun.
Post by Peter Dunkel
Läuft auch ohne Probleme, nur leider immer der gesamte Traffic, damit
ist der Uplink meiner Fritzbox das Nadelöhr.
Normal ist split tunneling ohnehin default.
Post by Peter Dunkel
Ich suche also eine Lösung, dass der Traffic zu meiner Fritzbox (und
wenn möglich dem Online-Banking) über VPN, der restliche Traffic
direkt ohne VPN erfolgt.
Sollte wie gesagt default sein.
Post by Peter Dunkel
Ich habe auch schon eine Datei /etc/ppp/ip-up erstellt und
verschiedene Einstallungen, z.B.
/sbin/route add -net 192.168.1.0/16 -interface ppp0
verwendete (natürlich habe ich 192.168.x.0/16 angepasst).
Mir ist jetzt nicht klar, was Du damit erreichen willst. Das ist so
einfach Unsinn. Damit pumpt Du alles an 192.168.1.x über ppp0 raus, wo
es dann natürlich verpufft - weil da ist das „Internet“.

Du bist Dir schon bewußt, daß Du es bei der VPN Verbindung mit einem
point-to-point link über ein tunnel-Interface (i.d.R. utun0) zu tun
hast?
Da bist Du auf jeden Fall mit ppp0 auf dem falschen Dampfer. Das ist
zwar auch point-to-point, aber die unverschlüsselte normale
Internetverbindung.
Post by Peter Dunkel
In einer Anleitung fand ich ' unchecked the Advanced VPN setting "Send
all traffic over VPN connection"', nur finde ich unter 10.10 die
Checkbox nicht.
Gibt es auch nicht. Weil normal bleibt einfach die normale defaultroute
stehen (sollte bei Dir dann auf ppp0 liegen) und der Traffic läuft wie
gehabt und der Tunnel wird nachgelagert einsortiert. Da liegt dann
einfach eine Route in das Netz hinter dem VPN auf dem Tunnel interface.
Post by Peter Dunkel
Hat jemand ein Kochrezept?
Check Dein Routing mal genauer und nimm vorher das falsche Gebastel
wieder raus.

Das hier ist so eine VPN Vebindung. Zwar keine Horstbox aber spielt
fürs Prinzip auch keine Rolle:

$netstat -nr

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.9 UGSc 52 0 en0
default link#7 UCSI 0 0 utun0
81.XXX.XXX.XX 192.168.1.9 UGHS 0 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 458 lo0
169.254 link#4 UCS 0 0 en0
192.168.1 link#4 UCS 3 0 en0
192.168.1.1 0:25:22:9f:eb:7a UHLWIi 4 113266 en0 903
192.168.1.3/32 link#4 UCS 0 0 en0
192.168.1.9/32 link#4 UCS 1 0 en0
192.168.1.9 0:13:10:30:7:1e UHLWIir 54 187 en0 1188
192.168.1.142 84:8e:df:f3:38:f8 UHLWI 0 0 en0 1178
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 7 en0
192.168.10 192.168.10.244 UGSc 0 11 utun0
192.168.10.244 192.168.10.244 UH 1 0 utun0

Zeile eins ist die ganz normale Defaultroute. 192.168.1.9 ist mein Router.
Damit läuft alles wie gehabt. Die bleibt einfach wie sie ist.

Vorletzte Zeile ist die Route ins Netz auf der anderen Seite des VPN
Tunnels (192.168.10er Netz) und damit geht alles an 192.168.10.*
darüber. Gateway ist der Rechner bzw. sein utun0 interface selber, das
die 192.168.10.244 zugewiesen bekommen hat.

Schau Dir das Routing vor und nach Tunnelaufbau bei Dir an. Das sollte
alles weitgehend gleich bleiben nur analog oben taucht mit VPN dann der
Tunnel zusätzlich auf und es sollte auch eine entsprechende Route für
das Netz am anderen Tunnelende dazukommen (also quasi wie oben die
Zeilen mit utun0 interface und dem neuen Gateway in der vorletzten Zeile).


Gruß,

Marcus
⚂⚃


Gruß,

Marcus
⚂⚃
Başar Alabay
2015-07-31 07:04:02 UTC
Permalink
Post by Marcus Jodorf
Post by Peter Dunkel
Seit OSX 10.10 lief das Tool leider nicht mehr und ich habe die VPN
Verbindung über die Systemeinstellung / Netzwerk aufgebaut.
Wenn Du da „Cisco IPSec“ nimmst, sollte das normal einfach tun.
Post by Peter Dunkel
Läuft auch ohne Probleme, nur leider immer der gesamte Traffic, damit
ist der Uplink meiner Fritzbox das Nadelöhr.
Normal ist split tunneling ohnehin default.
Moment, da komme ich nicht ganz mit. Wieso wollte man, wenn man mit
einem mobilen Gerät via VPN zum heimischen Router will, daß irgend etwas
nicht via diesem VPN-Tunnel läuft? Wie soll denn dann gelenkt werden,
was via Router (VPN) und was direkt läuft? Wenn man Mails abholen, Sites
anschauen, was weiß ich was mit Paßworten machen will, ist VPN doch der
bessere Weg. Oder irre ich mich?

B. Alabay
--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
Marcus Jodorf
2015-08-01 02:08:08 UTC
Permalink
Post by Başar Alabay
Post by Marcus Jodorf
Normal ist split tunneling ohnehin default.
Moment, da komme ich nicht ganz mit. Wieso wollte man, wenn man mit
einem mobilen Gerät via VPN zum heimischen Router will, daß irgend
etwas nicht via diesem VPN-Tunnel läuft? Wie soll denn dann gelenkt
werden, was via Router (VPN) und was direkt läuft? Wenn man Mails
abholen, Sites anschauen, was weiß ich was mit Paßworten machen will,
ist VPN doch der bessere Weg. Oder irre ich mich?
Man kann alles durch den verschlüsselten Tunnel leiten oder eben nur den
Traffic, der an die Adressen am anderen Tunnelende gerichtet ist.
Letzteres nennt man split tunneling.

Manche bevorzugen Ersteres und führen oft Sicherheitsgründe an. Wird
z.B. bei Enterprisezugängen gerne gemacht, weil damit aller Traffic
durch die Filter und Firewallschichten des Unternehmens gelenkt werden
kann, die da oft entsprechend leistungsfähig sind, allen durchlaufenden
Traffic filtern und sieben und die Leitungskapazitäten sind da meist
auch entsprechend großzügig.

Wenn man sein Heimnetz ansteuert, dann liegen da oft nicht so dicke
Leitungen und da stehen auch keine hochgezüchteten Firewallkomponenten,
die einem da Sicherheitsvorteile bringen würden.

Dann kann es sehr sinnvoll sein, split tunneling zu machen - ganz
einfach aus Geschwindkeitsgründen. Dann muß nur der Traffic ins
VPN-Netz (heimische Netz) durchs Nadelöhr und der Rest läuft ganz
normal, statt es gleich zweimal durch dieselbe Leitung des
Heimanschlusses zu jagen.

Bei IPSec kann man nebenbei kein Nicht-Split-Tunneling erzwingen. Das
geht nur mit proprietären Setups. Etwas wenn man eine Cisco hinstellt
und den Nutzer dann auf einen Cisco Client festnagelt und Alternativen
sicher verhindert.
Kann man das Clientprogramm nicht erzwingen, kann man auch split
tunneling nicht verhindern, weil das im Protokoll schlicht nicht
vorgesehen ist.

Lenkung bei split tunneling ist vollkommen simpel. Das ist ganz normales
Standardrouting der einfachen Art.

Ich nutze normal meist split tunneling. Das Umrouten allen Traffics
durch den Tunnel bremst bei nicht supertollen Leitungskapazitäten halt
oft und mit der Sicherheit ist wie immer alles relativ.
Ohne entsprechende Infrastruktur hat man da normal keinen nennenswerten
Vorteil.

Oder anders:
Sagen wir mal Du hast 20 Jahre verschlafen und benutzt Passwörter mit
unverschlüsselter Übertragung zur Webseite X, die nicht im VPN Netz liegt.
Mit split tunneling geht das einfach unverschlüsselt zur Seite X, und
der Tunnel kommt da auch gar nicht ins Spiel.
Ganz schlecht.

Dann sagen wir mal, Du verwendest kein split tunneling und alles geht
grundsätzlich durch die VPN Verbindung erst mal den Umweg zu Deinem VPN
Router.
Dann ist der Weg zum Router verschlüsselt.
Und mehr auch nicht.
Der Router sendet es dann wieder ganz normal unverschlüsselt zu X, nimmt
von dort den Traffic wieder unverschlüsselt entgegen und sendet das
wieder auf dem letzten Stück zu Dir verschlüsselt zurück.
Da gewinnst Du durch den Tunnel ziemlich genau gar nichts, weil Du damit
nur ein verschlüsseltes Teilstück/Umweg einfügst.
Das schützt halt nicht vor Dummheit.

Was in beiden Fällen geschützt und sicher verschlüsselt wird, ist nur
der Traffic zwischen Dir und Deinem VPN Netz am anderen Ende. Da hast Du
dann End-to-End Verschlüsselung für solche Verbindungen.



Gruß,

Marcus
⚂⚃
Günther Dietrich
2015-08-01 06:41:48 UTC
Permalink
Post by Marcus Jodorf
Sagen wir mal Du hast 20 Jahre verschlafen und benutzt Passwörter mit
unverschlüsselter Übertragung zur Webseite X, die nicht im VPN Netz liegt.
Mit split tunneling geht das einfach unverschlüsselt zur Seite X, und
der Tunnel kommt da auch gar nicht ins Spiel.
Ganz schlecht.
Man sollte hier nicht vom End-User ausgehen, der 20 Jahre verschlafen
hat, sondern vom Betreiber der Web-Site. Der End-User hat hier inden
allermeisten Fällen keinen direkten Einfluss darauf, ob der betreffende
Web-Server SSL/TLS verwendet.
Post by Marcus Jodorf
Dann sagen wir mal, Du verwendest kein split tunneling und alles geht
grundsätzlich durch die VPN Verbindung erst mal den Umweg zu Deinem VPN
Router.
Dann ist der Weg zum Router verschlüsselt.
Und genau das ist bei Mobilgeräten ausschlaggebend!
Post by Marcus Jodorf
Und mehr auch nicht.
Der kleine, aber wichtige Unterschied eben.
Post by Marcus Jodorf
Der Router sendet es dann wieder ganz normal unverschlüsselt zu X, nimmt
von dort den Traffic wieder unverschlüsselt entgegen und sendet das
wieder auf dem letzten Stück zu Dir verschlüsselt zurück.
Da gewinnst Du durch den Tunnel ziemlich genau gar nichts, weil Du damit
nur ein verschlüsseltes Teilstück/Umweg einfügst.
Es wird genau dort verschlüsselt übertragen, wo es besonders wichtig ist.
Post by Marcus Jodorf
Das schützt halt nicht vor Dummheit.
Es schützt zwar nicht vor Dummheit, aber es schützt davor, dass Hackern
Zugangsdaten frei Haus geliefert werden.
Post by Marcus Jodorf
Was in beiden Fällen geschützt und sicher verschlüsselt wird, ist nur
der Traffic zwischen Dir und Deinem VPN Netz am anderen Ende. Da hast Du
dann End-to-End Verschlüsselung für solche Verbindungen.
Das ist es, was man will und braucht.

Falls Du es vergessen haben solltest: Wenn man mit einem mobilen
Endgerät per _fremdem_ WLAN (Hot-Spot, etc.) im Internet unterwegs ist,
gehen die IP-Pakete entweder vollkommen unverschlüsselt per Funk in die
Luft, oder man teilt sich meist den selben Schlüssel mit vielen Anderen.
Es können dann entweder Alle, oder zumindest diejenigen, die im selben
WLAN hängen, diese IP-Pakete mitlesen, und damit z.B. auch Passworte
abgreifen.
Erst wenn man dieses Loch durch die Nutzung eines VPN _ohne_ so einen
Murks wie Split-Tunneling stopft, wird es einigermaßen sicher.

Und selbst wenn man ausschließlich mit Sites kommunizieren sollte, die
TLS verwenden, geht es all diejenigen, die den Funkkanal mit einem
teilen, nichts an, welche das sind. Auch dieses Wissen wird durch ein
_richtiges_ VPN geschützt.



Grüße,

Günther
Ralph Aichinger
2015-08-01 07:52:39 UTC
Permalink
Post by Günther Dietrich
Man sollte hier nicht vom End-User ausgehen, der 20 Jahre verschlafen
hat, sondern vom Betreiber der Web-Site. Der End-User hat hier inden
allermeisten Fällen keinen direkten Einfluss darauf, ob der betreffende
Web-Server SSL/TLS verwendet.
Eigentlich alle ernsthaften Websites nehmen heute TLS, zumindest dann
wenn es um Bezahlung oder anderswie wichtige Daten geht.

Und wenn man sich durchs VPN auf einen unverschlüsselten Server
raus verbindet, dann kann noch immer auf der Strecke vom VPN-
Endpunkt zum Server hin was schiefgehen. Das eine ist IMHO kein
Fix für das andere, sondern man braucht je nach Situation u.U. beides.
Post by Günther Dietrich
Und genau das ist bei Mobilgeräten ausschlaggebend!
Jein. Ich denke es gibt Szenarien wo das zentral ist (Client greift
aus WLAN in obskurem Internet-Cafe zu), es gibt aber andere wo das
überhaupt keine Hilfe ist (Client greift aus mobilem LTE-Internet
zu (das providerseitig nicht unsicherer ist als ein verkabelter
Provider), weil die Strecke vom VPN-Endpunkt durch dubiose
Kanäle geht.
Post by Günther Dietrich
Post by Marcus Jodorf
Der Router sendet es dann wieder ganz normal unverschlüsselt zu X, nimmt
von dort den Traffic wieder unverschlüsselt entgegen und sendet das
wieder auf dem letzten Stück zu Dir verschlüsselt zurück.
Da gewinnst Du durch den Tunnel ziemlich genau gar nichts, weil Du damit
nur ein verschlüsseltes Teilstück/Umweg einfügst.
Es wird genau dort verschlüsselt übertragen, wo es besonders wichtig ist.
Das kann manchmal der Fall sein. Oder eben auch nicht. Das ist so
wie wenn man sagen würde: Nur das Schloß an der Vordertür muß robust
sein, bei der Hintertür kann man das ignorieren.
Post by Günther Dietrich
Es schützt zwar nicht vor Dummheit, aber es schützt davor, dass Hackern
Zugangsdaten frei Haus geliefert werden.
Nicht notwendigerweise. Am "anderen Ende" (zwischen VPN-Endpunkt
und Zielserver) kann noch genug schiefgehen. Wenn z.B. der überezeugte
VPN-Nuter ins VPN reingeht, von dort wieder ins Internet, und dann
um sich ein Video runterzualaden in den beliebten russischen
Videosite mit Kreditkarteneingabe und Mafiakontakten, dann hilft
das schönste VPN nichts.
Post by Günther Dietrich
Falls Du es vergessen haben solltest: Wenn man mit einem mobilen
Endgerät per _fremdem_ WLAN (Hot-Spot, etc.) im Internet unterwegs ist,
gehen die IP-Pakete entweder vollkommen unverschlüsselt per Funk in die
Luft, oder man teilt sich meist den selben Schlüssel mit vielen Anderen.
Es können dann entweder Alle, oder zumindest diejenigen, die im selben
WLAN hängen, diese IP-Pakete mitlesen, und damit z.B. auch Passworte
abgreifen.
Das kann man auch lösen indem man halt kein fremdes WLAN verwendet,
sondern einfach LTE oder sowas aufdreht.
Post by Günther Dietrich
Erst wenn man dieses Loch durch die Nutzung eines VPN _ohne_ so einen
Murks wie Split-Tunneling stopft, wird es einigermaßen sicher.
Split-Tunneling ist kein Murks sondern eine Sache die u.U. sehr
sinnvoll ist. Wozu den gesamten YouTube-Traffic durch den VPN-Tunnel
stopfen, wenn es nicht mehr Sicherheit bringt, sondern nur den
Tunnel zustopft.
Post by Günther Dietrich
Und selbst wenn man ausschließlich mit Sites kommunizieren sollte, die
TLS verwenden, geht es all diejenigen, die den Funkkanal mit einem
teilen, nichts an, welche das sind. Auch dieses Wissen wird durch ein
_richtiges_ VPN geschützt.
Ich sehe es eher umgekehrt: Es bringt nichts unverschlüsselten
Verkehr (Linux-Downloads, Windows-Updates, Youtube ...) durch
den VPN-Tunnel zu jagen, und dadurch langsamer zu machen. Sowas
kann man ruhig direkt abwickeln.

Es bringt aber auch nichts, wenn man irgendwelche Phishing-Sites
durch den VPN-Tunnel ansteuert, dadurch wird auch nichts sicherer.

/ralph
Günther Dietrich
2015-08-01 08:37:15 UTC
Permalink
Post by Ralph Aichinger
Post by Günther Dietrich
Man sollte hier nicht vom End-User ausgehen, der 20 Jahre verschlafen
hat, sondern vom Betreiber der Web-Site. Der End-User hat hier inden
allermeisten Fällen keinen direkten Einfluss darauf, ob der betreffende
Web-Server SSL/TLS verwendet.
Eigentlich alle ernsthaften Websites nehmen heute TLS, zumindest dann
wenn es um Bezahlung oder anderswie wichtige Daten geht.
Waren da nicht neulich einige Vorfälle bezüglich der Sicherheit von TLS?
Post by Ralph Aichinger
Und wenn man sich durchs VPN auf einen unverschlüsselten Server
raus verbindet, dann kann noch immer auf der Strecke vom VPN-
Endpunkt zum Server hin was schiefgehen.
Es ist ein sehr großer Unterschied, ob man seine Daten unverschlüsselt
in die Luft bläst, wo jeder sie abgreifen kann, oder ob man sie einer
Leitung übergibt, andie heranzukommen schon einiges an krimineller
Energie bedarf.
Der gemeine Cracker wird es sich nicht antun, Leitungen anzuzapfen,
solange ihm einträgliche Daten frei Haus über die Luft geliefert werden.

Welches Ende der Übertragungsstrecke es vorrangig gilt, abzusichern,
ergibt sich daraus von selbst.

Du und Marcus dagegen sagt, dass man das leicht angreifbare Ende nicht
zu schützen braucht (oder vielleicht sogar nicht schützen soll), weil
man auf den Schutz des schlecht angreifbaren Endes keinen Einfluss hat.
Das ist, als ob ihr propagieren würdet, man solle seine Wohnungstüre in
der 8. Etage nicht abschließen, weil die Feuerwehr mit dem Leiterwagen
ja trotzdem über den Balkon in die Wohnung könnte.
Post by Ralph Aichinger
Post by Günther Dietrich
Und genau das ist bei Mobilgeräten ausschlaggebend!
Jein. Ich denke es gibt Szenarien wo das zentral ist (Client greift
aus WLAN in obskurem Internet-Cafe zu), es gibt aber andere wo das
überhaupt keine Hilfe ist (Client greift aus mobilem LTE-Internet
zu (das providerseitig nicht unsicherer ist als ein verkabelter
Provider), weil die Strecke vom VPN-Endpunkt durch dubiose
Kanäle geht.
Wie oben schon geschrieben: Man muss berücksichtigen, wie groß das
Risiko eines Angriffes ist. Und das ist nunmal bei annähernd 1, wenn die
Daten unverschlüsselt über ein Medium gehen, auf das Alle direkten
Zugriff haben.
Post by Ralph Aichinger
Post by Günther Dietrich
Post by Marcus Jodorf
Der Router sendet es dann wieder ganz normal unverschlüsselt zu X, nimmt
von dort den Traffic wieder unverschlüsselt entgegen und sendet das
wieder auf dem letzten Stück zu Dir verschlüsselt zurück.
Da gewinnst Du durch den Tunnel ziemlich genau gar nichts, weil Du damit
nur ein verschlüsseltes Teilstück/Umweg einfügst.
Es wird genau dort verschlüsselt übertragen, wo es besonders wichtig ist.
Das kann manchmal der Fall sein. Oder eben auch nicht. Das ist so
wie wenn man sagen würde: Nur das Schloß an der Vordertür muß robust
sein, bei der Hintertür kann man das ignorieren.
Siehe oben: Wo besteht ein nennensweres Risiko, und wo ist das Risiko
nicht so hoch?
Post by Ralph Aichinger
Post by Günther Dietrich
Es schützt zwar nicht vor Dummheit, aber es schützt davor, dass Hackern
Zugangsdaten frei Haus geliefert werden.
Nicht notwendigerweise. Am "anderen Ende" (zwischen VPN-Endpunkt
und Zielserver) kann noch genug schiefgehen. Wenn z.B. der überezeugte
VPN-Nuter ins VPN reingeht, von dort wieder ins Internet, und dann
um sich ein Video runterzualaden in den beliebten russischen
Videosite mit Kreditkarteneingabe und Mafiakontakten, dann hilft
das schönste VPN nichts.
Biedermann und die Brandstifter. Dagegen kommt man mit keinem
technischen Mittel an.
Für alle diejenigen, die sich die Brandstifter nicht ins Haus einladen
gibt es aber Mittel, um es den nicht Eingeladenen zu erschweren, ins
Haus zu kommen.
Ich halte es für eine sehr seltsame Mentalität, diese Mittel nicht
einzusezten, nur weil man die Möglichkeit hat, den dummen Fehler zu
machen, sich die Brandstifter in Haus einzuladen.

Man könnte fast glauben, Du und Marcus hättet ein Interesse daran, dass
die Daten Anderer frei über die Luft zugänglich bleiben.
Post by Ralph Aichinger
Post by Günther Dietrich
Falls Du es vergessen haben solltest: Wenn man mit einem mobilen
Endgerät per _fremdem_ WLAN (Hot-Spot, etc.) im Internet unterwegs ist,
gehen die IP-Pakete entweder vollkommen unverschlüsselt per Funk in die
Luft, oder man teilt sich meist den selben Schlüssel mit vielen Anderen.
Es können dann entweder Alle, oder zumindest diejenigen, die im selben
WLAN hängen, diese IP-Pakete mitlesen, und damit z.B. auch Passworte
abgreifen.
Das kann man auch lösen indem man halt kein fremdes WLAN verwendet,
sondern einfach LTE oder sowas aufdreht.
Selbst in diesem Fall würde ich meine Daten nur äußerst ungern
unverschlüsselt in die Luft blasen. Auch hier würde ich ein VPN
bevorzugen. Denn: In der Luft kann jeder an die Daten heran. Und man
weiß nicht, ob der Provider sie verschlüsselt, und wie gut. Hat man ja
schon bei GSM gesehen, wie gut das funktioniert hat.
Post by Ralph Aichinger
Post by Günther Dietrich
Erst wenn man dieses Loch durch die Nutzung eines VPN _ohne_ so einen
Murks wie Split-Tunneling stopft, wird es einigermaßen sicher.
Split-Tunneling ist kein Murks sondern eine Sache die u.U. sehr
sinnvoll ist. Wozu den gesamten YouTube-Traffic durch den VPN-Tunnel
stopfen, wenn es nicht mehr Sicherheit bringt, sondern nur den
Tunnel zustopft.
Wenn es kein Murks sein sollte, dannmüsste es aber konfigurierbar sein.
So wie ich Marcus verstehe, ist es das aber eben nicht. Also Murks.
Post by Ralph Aichinger
Post by Günther Dietrich
Und selbst wenn man ausschließlich mit Sites kommunizieren sollte, die
TLS verwenden, geht es all diejenigen, die den Funkkanal mit einem
teilen, nichts an, welche das sind. Auch dieses Wissen wird durch ein
_richtiges_ VPN geschützt.
Ich sehe es eher umgekehrt: Es bringt nichts unverschlüsselten
Verkehr (Linux-Downloads, Windows-Updates, Youtube ...) durch
den VPN-Tunnel zu jagen, und dadurch langsamer zu machen. Sowas
kann man ruhig direkt abwickeln.
Siehe oben: Dann muss es konfigurierbar sein, so dass man selbst
bestimmen kann, was durch den Tunnel soll, und was nicht. Dabei muss der
Default sein, dass die Daten durch den Tunnel gehen. Nur explizit
ausgewählte Ziele dürfen als Ausnahme direkt angesprochen werden.
Ansonsten reißt man wieder ein großes Sicherheitsloch. Und bei den
Ausnahmen muss man sehr genau abwägen, ob da nich doch auch vertrauliche
Daten involviert sind.

Ja, Sicherheit ist mit Bequemlichkeit nicht so einfach zu vereinen!
Post by Ralph Aichinger
Es bringt aber auch nichts, wenn man irgendwelche Phishing-Sites
durch den VPN-Tunnel ansteuert, dadurch wird auch nichts sicherer.
Wie oben schon geschrieben: Nur weil man sich Brandstifer ins Haus
einladen _könnte_, das Schloss an der Wohnungstüre wegzulassen, wäre
schon ziemlich dämlich. Und wenn jemand Anderen das ernsthaft empfiehlt,
weiß ich nicht so recht, was ich von ihm halten soll.



Grüße,

Günther
Başar Alabay
2015-08-01 10:08:41 UTC
Permalink
Post by Ralph Aichinger
Post by Günther Dietrich
Falls Du es vergessen haben solltest: Wenn man mit einem mobilen
Endgerät per _fremdem_ WLAN (Hot-Spot, etc.) im Internet unterwegs ist,
gehen die IP-Pakete entweder vollkommen unverschlüsselt per Funk in die
Luft, oder man teilt sich meist den selben Schlüssel mit vielen Anderen.
Es können dann entweder Alle, oder zumindest diejenigen, die im selben
WLAN hängen, diese IP-Pakete mitlesen, und damit z.B. auch Passworte
abgreifen.
Das kann man auch lösen indem man halt kein fremdes WLAN verwendet,
sondern einfach LTE oder sowas aufdreht.
Wenn man das aber eben nicht hat, nutzt man öffentliches WLAN.
Post by Ralph Aichinger
Post by Günther Dietrich
Erst wenn man dieses Loch durch die Nutzung eines VPN _ohne_ so einen
Murks wie Split-Tunneling stopft, wird es einigermaßen sicher.
Split-Tunneling ist kein Murks sondern eine Sache die u.U. sehr
sinnvoll ist. Wozu den gesamten YouTube-Traffic durch den VPN-Tunnel
stopfen, wenn es nicht mehr Sicherheit bringt, sondern nur den
Tunnel zustopft.
Öhm, weil Youtube z. B. zensiert/verboten oder sonstwas ist? Nicht
überall ist eitel Sonnenschein?

B. Alabay
--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
Başar Alabay
2015-08-01 10:06:29 UTC
Permalink
Post by Günther Dietrich
Post by Marcus Jodorf
Was in beiden Fällen geschützt und sicher verschlüsselt wird, ist nur
der Traffic zwischen Dir und Deinem VPN Netz am anderen Ende. Da hast Du
dann End-to-End Verschlüsselung für solche Verbindungen.
Das ist es, was man will und braucht.
Falls Du es vergessen haben solltest: Wenn man mit einem mobilen
Endgerät per _fremdem_ WLAN (Hot-Spot, etc.) im Internet unterwegs ist,
gehen die IP-Pakete entweder vollkommen unverschlüsselt per Funk in die
Luft, oder man teilt sich meist den selben Schlüssel mit vielen Anderen.
Es können dann entweder Alle, oder zumindest diejenigen, die im selben
WLAN hängen, diese IP-Pakete mitlesen, und damit z.B. auch Passworte
abgreifen.
Erst wenn man dieses Loch durch die Nutzung eines VPN _ohne_ so einen
Murks wie Split-Tunneling stopft, wird es einigermaßen sicher.
Exakt mein Gedanke.
Post by Günther Dietrich
Und selbst wenn man ausschließlich mit Sites kommunizieren sollte, die
TLS verwenden, geht es all diejenigen, die den Funkkanal mit einem
teilen, nichts an, welche das sind. Auch dieses Wissen wird durch ein
_richtiges_ VPN geschützt.
Genau. Es ging mir eben um die öffentlich unkontrollierbaren Zugänge
»draußen«. Und abgesehen davon, wie bereits angemerkt, frage ich mich,
wie nun eigentlich Uni-Cisco (!) VPN genau funktionierte, aber das ist
jetzt eigentlich auch egal.

Hier geht es in erster Linie um das Mitlesen von Verbindungen eines klar
zuordenbaren Mobilteils.

B. Alabay
--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
Marcus Jodorf
2015-08-01 20:58:30 UTC
Permalink
Post by Günther Dietrich
Man sollte hier nicht vom End-User ausgehen, der 20 Jahre verschlafen
hat, sondern vom Betreiber der Web-Site.
Nein, das meint einen Enduser, der immer noch auf unverschlüsselte
Webseiten in unsicherer Umgebung geht.
Post by Günther Dietrich
Der End-User hat hier inden
allermeisten Fällen keinen direkten Einfluss darauf, ob der betreffende
Web-Server SSL/TLS verwendet.
Was ziemlich egal ist. Man benutzt keine unverschlüsselten Server in
unsicherer Umgebung. So einfach ist das.
Post by Günther Dietrich
Es wird genau dort verschlüsselt übertragen, wo es besonders wichtig ist.
Wieso soll es da besonders wichtig sein? Wo man Dir die Daten abgreift,
macht nicht wirklich einen Unterschied.
Post by Günther Dietrich
Es schützt zwar nicht vor Dummheit, aber es schützt davor, dass Hackern
Zugangsdaten frei Haus geliefert werden.
Ach ja. Die pösen Hacker mal wieder. Die sind doch nun heute wirklich
das kleinste Problem.
Post by Günther Dietrich
Post by Marcus Jodorf
Was in beiden Fällen geschützt und sicher verschlüsselt wird, ist nur
der Traffic zwischen Dir und Deinem VPN Netz am anderen Ende. Da hast
Du dann End-to-End Verschlüsselung für solche Verbindungen.
Das ist es, was man will und braucht.
Wozu? Entweder verwendet man sichere Kommunikation oder nicht. Hat man
die nicht, versendet man nichts wichtiges/schützenswertes.
Aber das doch zu tun, wenn ein kleiner Teil der Übertragungsstrecke
abgesichert ist - das ist schlicht dumm.


Gruß,

Marcus
⚂⚃
Başar Alabay
2015-08-01 10:03:40 UTC
Permalink
Post by Marcus Jodorf
Post by Başar Alabay
Moment, da komme ich nicht ganz mit. Wieso wollte man, wenn man mit
einem mobilen Gerät via VPN zum heimischen Router will, daß irgend
etwas nicht via diesem VPN-Tunnel läuft? Wie soll denn dann gelenkt
werden, was via Router (VPN) und was direkt läuft? Wenn man Mails
abholen, Sites anschauen, was weiß ich was mit Paßworten machen will,
ist VPN doch der bessere Weg. Oder irre ich mich?
Man kann alles durch den verschlüsselten Tunnel leiten oder eben nur den
Traffic, der an die Adressen am anderen Tunnelende gerichtet ist.
Letzteres nennt man split tunneling.
Manche bevorzugen Ersteres und führen oft Sicherheitsgründe an. Wird
z.B. bei Enterprisezugängen gerne gemacht, weil damit aller Traffic
durch die Filter und Firewallschichten des Unternehmens gelenkt werden
kann, die da oft entsprechend leistungsfähig sind, allen durchlaufenden
Traffic filtern und sieben und die Leitungskapazitäten sind da meist
auch entsprechend großzügig.
Wenn man sein Heimnetz ansteuert, dann liegen da oft nicht so dicke
Leitungen und da stehen auch keine hochgezüchteten Firewallkomponenten,
die einem da Sicherheitsvorteile bringen würden.
Ja, das ist mir klar. Aber wenn ich mit einem Mobilteil aus einem Café,
Hotel oder einer Tankstelle, sagen wir mal im Ausland, eine Verbindung
ins Netz herstelle, will ich – sinnvoll oder nicht – daß da nix
mitgeschnüffelt werden kann. Ich baue ja keine Verbindung »nach Hause«
auf, um von einem NAS ein mp3-Liedchen abzuhören. Vielleicht machen das
andere, ich jedenfalls will, wenn, browsen, News lesen und ähnliches.
Fast alles ist verschlüsselt, aber News z. B. sind es oftmals nicht. Wir
hatten auch schon mal die Diskussion mit stunnel, tin, slrn und Co. –
keiner (!) hat das wirklich laufend präsentieren können. Ob das nun vom
Router in die Welt geblasen wird oder in einem Router einer öffentlichen
Hotsport-Stelle hängenbleibt – das ist für mich durchaus ein
Unterschied.
Post by Marcus Jodorf
Dann kann es sehr sinnvoll sein, split tunneling zu machen - ganz
einfach aus Geschwindkeitsgründen. Dann muß nur der Traffic ins
VPN-Netz (heimische Netz) durchs Nadelöhr und der Rest läuft ganz
normal, statt es gleich zweimal durch dieselbe Leitung des
Heimanschlusses zu jagen.
Wobei ich tatsächlich noch keine Probleme erlebt habe, wenn man einfach
browsen will. Wer weiß, was für minimale MBit-Flaschenhälse da schon
unterwegs sind, nach Huase und zurück ist da eher das kleinere Problem.
Solange man nicht im Tal lebt und KBit statt MBit zur Verfügung hat.
Post by Marcus Jodorf
Bei IPSec kann man nebenbei kein Nicht-Split-Tunneling erzwingen. Das
geht nur mit proprietären Setups. Etwas wenn man eine Cisco hinstellt
und den Nutzer dann auf einen Cisco Client festnagelt und Alternativen
sicher verhindert.
Hm, also ich kenne nur die AVM–iOS Bindungen, und die sind IPSec, dachte
ich. Und da soll es angeblich beide Modi geben? Laut AVM jedenfalls,
alles oder Teile.
Post by Marcus Jodorf
Kann man das Clientprogramm nicht erzwingen, kann man auch split
tunneling nicht verhindern, weil das im Protokoll schlicht nicht
vorgesehen ist.
Und ich erinnere mich an Unizeiten, das war ja noch richtige Cisco und
IPSec … ich glaube, da konnte man auch so ziemlich alles via Uni laufen
lassen. Wie sonst erkannten die Gegenschnittstellen, ob man z. B.
authorisiert ist, eine Datenbank zu lesen oder nicht? Man mußte ja »aus
dem Netz der Uni« drauf zugreifen. Auch wenn man Landkreise weiter weg
war.

B. Alabay
--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
Marcus Jodorf
2015-08-01 21:21:59 UTC
Permalink
Post by Başar Alabay
Post by Marcus Jodorf
Bei IPSec kann man nebenbei kein Nicht-Split-Tunneling erzwingen. Das
geht nur mit proprietären Setups. Etwas wenn man eine Cisco hinstellt
und den Nutzer dann auf einen Cisco Client festnagelt und Alternativen
sicher verhindert.
Hm, also ich kenne nur die AVM–iOS Bindungen, und die sind IPSec,
dachte ich. Und da soll es angeblich beide Modi geben? Laut AVM
jedenfalls, alles oder Teile.
Das hängt einfach vom Client ab bzw. seiner Konfiguration. Bei Kisten
wie der Ciso ASA kann man z.B. auch anknipsen, ob der Client split
tunneling machen darf oder nicht. Ist dann am anderen Ende ein Cisco
client, bekommt er die Info nebenher proprietär übertragen und stellt es
entsprechend ein und versagt gegebenenfalls dem Benutzer auch, die
Einstellung im Client zu ändern.
Das funktioniert aber nur sicher, wenn der Rechner des Benutzers
verrammelt ist.
Denn kann der Benutzer aber den Client auf seinem Rechner ändern, dann
ist das alles wurscht und was die Cisco und deren Admin will, ist nur
noch allein deren Problem.

Nochmal: Ob mit oder ohne split tunneling hat mit IPSec nichts zu
tun. IPSec baut nur eine verschlüsselte Verbindung auf und mehr
nicht. Alles andere ist ganz herkömmliches Routing.
Post by Başar Alabay
Man mußte ja »aus dem Netz der Uni« drauf zugreifen. Auch wenn man
Landkreise weiter weg war.
Ja und? Bei IPSec hast Du ja auch eine Verbindung bei der das
Endinterface eine IP des angebunden Netzes bekommt. Damit bist Du „im
Netz der Uni“.
Das hat rein gar nichts damit zu tun, wo Du welch Daten vielleicht sonst
noch über welche anderen Verbindungen in welche anderen Netze zur selben
Zeit schickst.


Gruß,

Marcus
⚂⚃
Peter Dunkel
2015-08-03 14:10:13 UTC
Permalink
Post by Marcus Jodorf
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.9 UGSc 52 0 en0
default link#7 UCSI 0 0 utun0
Hallo Marcus,

Besten Dank für Deine Antwort, sie hat mich ein gutes Stück weiter gebracht.

Bei mir sind die beiden ersten Zeilen vertauscht:

Destination Gateway Flags Refs Use Netif
Expire
default link#11 UCS 7 0 utun0
default 192.168.43.1 UGScI 11 0 en1


192.168.43.1 ist mein Android Phone, das ich als Verbindung zum UMTS
Netz nutze. Angebunden via WLAN.

8.8.8.8 link#11 UHWIi 34 88 utun0
17.253.54.125 link#11 UHW3I 0 0 utun0
8
74.125.136.188 link#11 UHWIi 2 3 utun0
92.xx.82.28 192.168.43.1 UGHS 3 1 en1
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 1230 lo0
157.56.195.250 link#11 UHWIi 1 3 utun0
169.254 link#5 UCS 0 0 en1
173.194.39.24 link#11 UHWIi 2 4 utun0
192.168.43 link#5 UCS 2 0 en1
192.168.43.1/32 link#5 UCS 1 0 en1
192.168.43.1 4:18:f:c:79:59 UHLWIir 14 2631 en1
1199
192.168.43.81 c0:63:94:92:5:d6 UHLWI 0 174 en1
94
192.168.43.113/32 link#5 UCS 0 0 en1
192.168.43.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3 en1
192.168.100.1 link#11 UHW3I 0 0 utun0
7
192.168.100.209 192.168.176.209 UH 0 11 utun0
216.58.213.10 link#11 UHWIi 2 4 utun0

192.168.100.1 ist meine FritzBox zuhause via VPN,
92.xx.82.28 ist die heutige IP Adresse der FritzBox,
woher die 74, 157, ... IP Adfressen stammen???
Sie scheinen aber was mit dem VPN Tunnel zu tun zu haben, beim netstat
ohne VPN tauchen sie nicht auf.

Wie bekomme ich die beiden ersten Zeilen vertauscht, also:
default 192.168.43.1 UGScI 11 0 en1
default link#11 UCS 7 0 utun0

Dann müsste ja alles, auch das nach 192.168.100.x, direkt laufen.

Besten Dank
Peter
Marcus Jodorf
2015-08-04 20:59:42 UTC
Permalink
Post by Peter Dunkel
Destination Gateway Flags Refs Use Netif Expire default 192.168.1.9
UGSc 52 0 en0 default link#7 UCSI 0 0 utun0
Hallo Marcus,
Besten Dank für Deine Antwort, sie hat mich ein gutes Stück weiter gebracht.
Destination Gateway Flags Refs Use Netif Expire
default link#11 UCS 7 0 utun0
default 192.168.43.1 UGScI 11 0 en1
route delete default -interface utun0
route add default 192.168.43.1

oder es sollte eigentlich auch (untested)

route change default 192.168.43.1

funktionieren.


Normal sollte sich das auch alles an die Reihenfolge der Dienste in den
Netzwerk System Preferences halten (falls das nicht gerade wieder broken
ist).

Siehe auch:
networksetup -listnetworkserviceorder
networksetup -ordernetworkservices ...
Post by Peter Dunkel
192.168.43.1 ist mein Android Phone, das ich als Verbindung zum UMTS
Netz nutze. Angebunden via WLAN.
default 192.168.43.1 UGScI 11 0 en1
default link#11 UCS 7 0 utun0
s.o.


Gruß,

Marcus
⚂⚃
Marcus Jodorf
2015-08-04 21:07:29 UTC
Permalink
Post by Peter Dunkel
192.168.100.1 ist meine FritzBox zuhause via VPN,
Da wirst Du auch wahrscheinlich noch eine Netzroute für 192.168.100.1/24
mit dem Tunnel als Gateway legen müssen, nachdem die defaultroute umgebogen ist.
Siehe analog meine routingtable ganz am Ende.

Gruß,

Marcus
⚂⚃

Lesen Sie weiter auf narkive:
Loading...