Arch Linux

VPN Gateway einrichten

Josephus Miller

Hallo,

ich habe mir VPN eingerichtet, funktioniert auch soweit. Allerdings habe ich nicht die IP meiner FritzBox, über die die Verbindung läuft, sondern die des Routers bei dem ich moch einwähle. Ich vermute das liegt an den Einstellungen, allerdings weiß ich nicht wo ich da schrauben müsste:

cat /etc/NetworkManager/system-connections/FritzHome

[connection]
id=FritzHome
uuid=c832c5bd-d210-43fe-8fd0-529a5adcaa34
type=vpn
permissions=user:xxxx:;

[vpn]
service-type=org.freedesktop.NetworkManager.vpnc
NAT Traversal Mode=natt
IPSec secret-flags=1
Vendor=cisco
Xauth username=xxxx
IPSec gateway=xxxx.goip.de
Xauth password-flags=1
IPSec ID=xxxx
Perfect Forward Secrecy=server
IKE DH Group=dh2
Local Port=0

[ipv6]
method=auto

[ipv4]
method=auto

Ich denke das liegt in derEinstellung für ipv4, kann mir jemand sagen was ich da eingeben muss um die IP der FritzBox zu nutzen?

maltem

Ist der Sinn eines VPN nicht, daß man eine andere IP hat? Wie die Pakete im einzelnen umgeleitet werden, hängt allerdings vom Verhalten des jeweiligen Gateways ab.

Josephus Miller

maltem schriebIst der Sinn eines VPN nicht, daß man eine andere IP hat? Wie die Pakete im einzelnen umgeleitet werden, hängt allerdings vom Verhalten des jeweiligen Gateways ab.

Nicht unbedingt, der Hauptgrund ist denke ich dass in nicht vertrauenswürdigen/unverschlüsselten Netzwerken die Pakete nicht gelesen werden können.

Das kann nicht am Gateway liegen, da ich beim Handy mit Android über VPN die IP meiner FritzBox bekomme, mit dem Notebook und Arch eben nicht. Das muss schon an den lokalen Einstellungen liegen.

Creshal

Nicht unbedingt, der Hauptgrund ist denke ich dass in nicht vertrauenswürdigen/unverschlüsselten Netzwerken die Pakete nicht gelesen werden können.

…und das geht nur, wenn der Traffic über das VPN läuft. Wenn Traffic die ausgehende IP deiner Fritzbox hat, läuft er nicht übers VPN und ist unverschlüsselt.

Josephus Miller

Creshal schrieb
Nicht unbedingt, der Hauptgrund ist denke ich dass in nicht vertrauenswürdigen/unverschlüsselten Netzwerken die Pakete nicht gelesen werden können.
…und das geht nur, wenn der Traffic über das VPN läuft. Wenn Traffic die ausgehende IP deiner Fritzbox hat, läuft er nicht übers VPN und ist unverschlüsselt.

Das verstehe ich nicht wirklich. Wenn Ich mich zB vom offenen Wlan am Flughafen mit meiner FritzBox verbinde, ist diese Verbindung verschlüsselt und dementsprechend sicher, auch wohin ich mich verbinde ist nicht einsehbar. Die Verbindung von meiner FritzBox ist natürlich nur über https verschlüsselt, aber ich sehe meine FritzBox ja als vertrauenswürdigen Einwahlpunkt an.

Aber die Frage ist ja, warum ich vom Handy die IP der FritzBox bekomme und unter Arch nicht. Was zB für das anschauen diveser Seiten und Streams einen Unterschied macht.

stigmayta

Hallo Icecube,

NetworkManager wird wohl die Standard-Route falsch oder gar nicht setzen. Du kannst das wie in diesem Wiki-Eintrag beschrieben manuell überprüfen und einstellen. Als Gateway musst du die interne Adresse deiner Fritzbox nehmen. Ab da sollte alles durch das VPN laufen. Das musst du dann auch im NetworkManager so konfigurieren, wie die Befehle da heißen kann ich dir leider nicht sagen. Ich nutze NetzworkManager so nicht und hab auf die schnelle keine Beispiele gefunden...

Was Creshal meint verstehe ich auch nicht ganz. Wenn Server im Internet die öffentliche IP deiner FritzBox sehen, dann funktioniert auch dein VPN so wie es soll! Wenn die öffentliche IP deines lokalen Netzwerkes (z.B. Hotel) angezeigt wird, dann klappts mit dem VPN nicht so wie gewollt.

LG

Josephus Miller

Der Link hilft leider nicht weiter, denn

$ ip route show dev tun0
default  proto static  scope link  metric 1024 
192.168.178.0/24  proto kernel  scope link  src 192.168.178.201

zeigt mir schon das richtige Gateway.

Ich vermuet wie gesagt dass die Einstellung unter /etc/NetworkManager/system-connections/FritzHome bei

[ipv6]
method=auto

[ipv4]
method=auto

gemacht werden muss, aber wie gesagt weiß ich nicht wie.

drcux

Wo zeigt denn dein Defaultgateway hin? Ich sehe bei dir nur die Route in 178.X Netz...

Josephus Miller

drcux schriebWo zeigt denn dein Defaultgateway hin? Ich sehe bei dir nur die Route in 178.X Netz...

Welches meinst du?

Inzwischen habe ich die Einstellung auf manuell gestellt, allerdings habe ich immer noch nicht die IP der FritzBox:

[ipv4]
method=manual
dns=213.73.91.35;85.214.73.63;
address1=192.168.178.201/24,192.168.178.1

drcux

Icecube63 schrieb Welches meinst du?

Wieso welches?
Wenn du möchtest, das sämtlicher Traffic über die FritzBox geht, muss diese als Defaultgateway fungieren.

Josephus Miller

drcux schrieb
Icecube63 schrieb Welches meinst du?
Wieso welches?
Wenn du möchtest, das sämtlicher Traffic über die FritzBox geht, muss diese als Defaultgateway fungieren.

Weil es sowohl das IPSec gateway als auch die fritz.box/192.168.178.1 gibt. Ersteres muss ja eingerichtet sein, sonst komm ich nicht bis zur FritzBox, zweiteres habe ich wie geschrieben manuell im Networkmanager eingerichtet, was aber auch nichts hilft.

drcux

Icecube63 schrieb Weil es sowohl das IPSec gateway als auch die fritz.box/192.168.178.1 gibt. Ersteres muss ja eingerichtet sein, sonst komm ich nicht bis zur FritzBox, zweiteres habe ich wie geschrieben manuell im Networkmanager eingerichtet, was aber auch nichts hilft.

Nein, in dem Moment, wo der Tunnel aufgebaut ist, darf es nur noch die FritzBox als Defaultgateway geben, wenn der gesamte Traffic darüber gehen soll. DNS ist dann auch die FritzBox.

Stelle mal alles wieder auf automatisch (DHCP) und poste dann die Ausgabe von "ip a s", "ip r s" und "cat /etc/resolv.conf" jeweils vor und nachdem du das VPN aufgebaut hast.

Josephus Miller

Ok, so sind die Ausgaben wenn ich wieder alles auf method=auto stelle:

Ohne VPN:

$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:88:e3:3f:cc:81 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e8:03:9a:cb:01:24 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.4/24 brd 192.168.1.255 scope global dynamic wlan0
       valid_lft 258778sec preferred_lft 258778sec
    inet6 fe80::ea03:9aff:fecb:124/64 scope link 
       valid_lft forever preferred_lft forever

$ ip r s
default via 192.168.1.1 dev wlan0  metric 303 
default via 192.168.1.1 dev wlan0  proto static  metric 1024 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.4 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.4  metric 303

Mit VPN:

$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:88:e3:3f:cc:81 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e8:03:9a:cb:01:24 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.4/24 brd 192.168.1.255 scope global dynamic wlan0
       valid_lft 258521sec preferred_lft 258521sec
    inet6 fe80::ea03:9aff:fecb:124/64 scope link 
       valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 192.168.178.201/24 brd 192.168.178.255 scope global tun0
       valid_lft forever preferred_lft forever

$ ip r s
default via 192.168.1.1 dev wlan0  metric 303 
default dev tun0  proto static  scope link  metric 1024 
77.2.251.246 via 192.168.1.1 dev wlan0  proto static  metric 10 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.4 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.4  metric 303 
192.168.178.0/24 dev tun0  proto kernel  scope link  src 192.168.178.201

Erstaunlicherweise wird die IP meiner FritzBox 77.2.251.246 angezeigt. Aber wenn ich auf wieistmeineip nachschaue steht dort die vom derzeitigen Router.

Die resolv.conf habe ich schreibgeschützt, die ändert sich nicht:

$ sudo cat /etc/resolv.conf
[sudo] password for klaus: 
# Generated by Klaus

# CCC Berlin

nameserver 213.73.91.35

# Digitalcourage  FoeBud e.V.

nameserver 85.214.73.63

Josephus Miller

Ich hatte beim Schreiben die Idee, die FritzBox in der resolv.conf als DNS anzugeben, ändert aber auch nichts. Danei fiel mir auf, dass der IP-Bereich für DHCP ja nur bis xxx.200 geht, hier habe ich aber 201, womit ja DHCP nicht über die FritzbBox laufen dürfte.

stigmayta

Icecube63 schrieb Mit VPN:

$ ip a s
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e8:03:9a:cb:01:24 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.4/24 brd 192.168.1.255 scope global dynamic wlan0
valid_lft 258521sec preferred_lft 258521sec
inet6 fe80::ea03:9aff:fecb:124/64 scope link
valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 192.168.178.201/24 brd 192.168.178.255 scope global tun0
valid_lft forever preferred_lft forever

$ ip r s
default via 192.168.1.1 dev wlan0 metric 303

Hervorhebung durch mich.
Wie vermutet ist im VPN-Betrieb dein Default Gateway falsch gesetzt. Dein Default-Gateway darf nicht der lokale Router sein der dir die Einstellungen per DHCP gibt! Beim Aufbau des VPNs muss das Default Gateway mit der internen IP der Fritzbox überschrieben werden. Wie lautet die IP? Wenn ich raten müsste ist das sicherlich die 192.168.178.1? Wenn das stimmt probier bitte folgendes, wenn der VPN-Tunnel aufgebaut ist:

$ ip route del 0/0 via 192.168.1.1
$ ip route add 0/0 via 192.168.178.1

Funktioniert es jetzt?
DNS ist für die Funktion an sich im Übrigen erstmal sekundär. Trotzdem wäre es schöner bzw. sicherer du würdest auch die Fritzbox als DNS verwenden! Ansonsten weiß das Hotel (oder wo du auch immer bist) immernoch welche Seiten du aufrust, weil die deine DNS-Anfragen bekommen (die auch gesondert geblockt/gefälscht werden könnten).

LG

Josephus Miller

stigmayta schrieb Funktioniert es jetzt?

~~Ja! 🙂~~

Zu früh gefreut. Es funktioniert, aber nur temporär. Sobald die VPN-Verbindung getrennt wird entsteht beim Neuaufbau in der Liste der Verbindungen beim Networkmanager eine neue tun0 mit dem "Standardgateway" 0.0.0.0, was dann das Gateway 192.168.1.1 nutzt.

drcux

Greifst du ausser bei der resolv.conf noch irgendwo ein, wenn du eine WLan-Verbindugn aufbaust? Auch das Schreibschützen der resolv.conf kann den Netzworkmanager aus dem Tritt bringen...

Josephus Miller

Nein. Und wenn ich den Schreibschutz entferne habe ich den gleichen Effekt, sprich daran kanns nicht liegen.

drcux

Merkwürdig, bei mir macht der Networkmanager das richtig, auch eine FritzBox als VPN-Server...

Steht im Journal irgendetwas auffälliges?

Josephus Miller

Zumindest sehe ich nichts:

Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> Starting VPN service 'vpnc'...
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 1076
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> VPN service 'vpnc' appeared; activating connections
Okt 29 17:00:43 arch-laptop kernel: tun: Universal TUN/TAP device driver, 1.6
Okt 29 17:00:43 arch-laptop kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> VPN plugin state changed: init (1)
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> VPN plugin state changed: starting (3)
Okt 29 17:00:43 arch-laptop NetworkManager[402]: ** Message: vpnc started with pid 1083
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> VPN connection 'FritzHome' (Connect) reply received.
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> (tun0): carrier is OFF
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 4)
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/4
Okt 29 17:00:43 arch-laptop NetworkManager[402]: <info> (tun0): link connected
Okt 29 17:00:43 arch-laptop dhcpcd[405]: tun0: waiting for carrier
Okt 29 17:00:43 arch-laptop dhcpcd[405]: tun0: carrier acquired
Okt 29 17:00:43 arch-laptop dhcpcd[405]: tun0: IAID 00:00:00:00
Okt 29 17:00:43 arch-laptop dhcpcd[405]: tun0: waiting for 3rd party to configure IP address
Okt 29 17:00:43 arch-laptop dhcpcd[405]: tun0: soliciting an IPv6 router
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> VPN connection 'FritzHome' (IP4 Config Get) reply received from old-style plugin.
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> VPN Gateway: 95.113.191.41
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Tunnel Device: tun0
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> IPv4 configuration:
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info>   Internal Address: 192.168.178.201
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info>   Internal Prefix: 24
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info>   Internal Point-to-Point Address: 192.168.178.201
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info>   Maximum Segment Size (MSS): 0
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info>   Forbid Default Route: no
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info>   Internal DNS: 192.168.178.1
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info>   DNS Domain: '(none)'
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> No IPv6 configuration
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> VPN connection 'FritzHome' (IP Config Get) complete.
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> VPN plugin state changed: started (4)
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) starting connection 'tun0'
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) scheduled...
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) started...
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) scheduled...
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) complete.
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) starting...
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) successful.
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) scheduled.
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) complete.
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) started...
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
Okt 29 17:00:44 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
Okt 29 17:00:45 arch-laptop NetworkManager[402]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Okt 29 17:00:45 arch-laptop NetworkManager[402]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
Okt 29 17:00:45 arch-laptop NetworkManager[402]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Okt 29 17:00:45 arch-laptop NetworkManager[402]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Okt 29 17:00:45 arch-laptop NetworkManager[402]: <info> Activation (tun0) successful, device activated.
Okt 29 17:00:46 arch-laptop ntpd[541]: Listen normally on 8 tun0 192.168.178.201:123
Okt 29 17:00:46 arch-laptop ntpd[541]: new interface(s) found: waking up resolver

Außer dass er ein neues Tun device anlegt, was eben die Standareinstellung 00.00.00.00 hat.

Nächste Seite »