~rumpelsepp/homepage

ref: 2a0829d7d5c82198e590e856efc864471be97a18 homepage/_posts/2016-07-14-vpn-leaks-ipv6.adoc -rw-r--r-- 6.7 KiB
2a0829d7Stefan Tatschner add degoogle | A huge list of alternatives to Google products. Privacy tips, tricks, and links. 5 months ago
                                                                                
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
= Android VPN leaks ipv6
:page-lang: de

Ich hab mir jetzt endlich nen VPN Server zugelegt um in offenen WLANs
sicher zu surven zu koennen (konkret: OpenVPN + FreeBSD bei digital
ocean). Mein VPN Server macht aktuell nur ipv4, weil die kleinste
digital ocean kiste (wie ich gelernt habe) aktuell kein /112 oder /64er
netz bekommt. Stoert mich soweit nicht, koennte laut Support aber noch
kommen.

ABER:
Wenn ein Geraet per VPN online ist und beide, ipv4 und ipv6 macht, dann
kann ipv6 traffic neben dem VPN vorbei leaken. Es ist mir aufgefallen,
dass trotz VPN google meine position anhand der IP wusste. eigentlich
sollte da jetzt ja immer Frankfurt drinstehen... Tja, das Linux Hotel
hat WLAN mit ipv6 Support und der Traffic leaked einfach an meinem VPN
vorbei.

Abhilfe: Wenn ich im VPN bin, ipv6 ausmachen. Alles gut.

Frage: Wie zur Hoelle mach ich das auf android? Ich hab jetzt ueber ne
Stunde gegoogled und nix vernuenftiges gefunden. IPV6 in ein leeres VPN
LAN routen ist doof, weil dann die meisten Webseiten einfach tod sind.
IPv6 irgendwie ueber Firewall wegblocken sollte den gleichen Effekt
bringen (glaub ich). Einfach ipv6 ausknipsen waere das sinnvollste, aber
bei Android (!= einfaches Linux) ..... Arrrgh.

Ich hatte dann den Vorschlag bekommen folgendes auszuprobieren und ggf.
zu scripten:

	echo 1 > /proc/sys/net/ipv6/conf/wlan0/disable_ipv6

Das waere natuerlich eine Moeglichkeit, ja. Ich hab nur irgendwie Bedenken,
dass es nicht wirklich gut funktioniert. Script gebotschte und Android...
klingt irgendwie nach einer sehr boesen Kombination.

Ich hab es jetzt anders geloest, einen Hurricane Electric Tunnel auf
meinem Server! Damit umgehe ich das zu kurze Prefix von Digital Ocean
ganz einfach.

Auf FreeBSD https://www.freebsd.org/doc/handbook/network-ipv6.html[brunzeinfach]
aufzusetzen:

[source, sh]
./etc/rc.conf:
----
# Hurricane Electric
gif_interfaces="gif0"
gifconfig_gif0="SERVERIP4 ENDPUNKTIP4"
ifconfig_gif0_ipv6="inet6 SERVERIP6 ENDPUNKTIP6 prefixlen 128"

# Gateway
ipv6_activate_all_interfaces="yes"
ipv6_defaultrouter="ENDPUNKTIP6"
ifconfig_vtnet0_ipv6="ENDPUNKTIP6 prefixlen 64"
rtadvd_enable="YES"
rtadvd_interfaces="vtnet0"
ipv6_gateway_enable="YES"
----

Als ENDPUNKTIP6 einfach `...:1` nehmen; als SERVERIP6 dann die `....:2`.
Die ifconfig (ohne loopback) schaut so aus. Das `gif0` macht den Hurricane
Electric Tunnel; das `vtnet0` ist mein netzwerkkarte, das `tun0` ist mein
`openvpn` device.

----
$ ifconfig
vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ptions=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 04:01:25:41:24:01
        inet6 fe80::601:25ff:fe41:2401%vtnet0 prefixlen 64 scopeid 0x1
        inet 188.166.164.127 netmask 0xfffff800 broadcast 188.166.167.255
        inet6 2001:470:1f0a:6cb::1 prefixlen 64
        inet 10.19.0.5 netmask 0xffff0000 broadcast 10.19.255.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet 10Gbase-T <full-duplex>
        status: active
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        options=80000<LINKSTATE>
        tunnel inet 188.166.164.127 --> 216.66.80.30
        inet6 2001:470:1f0a:6cb::2 --> 2001:470:1f0a:6cb::1 prefixlen 128
        inet6 fe80::601:25ff:fe41:2401%gif0 prefixlen 64 scopeid 0x4
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::601:25ff:fe41:2401%tun0 prefixlen 64 scopeid 0x5
        inet 10.8.0.1 --> 10.8.0.2 netmask 0xffffffff
        inet6 2001:470:1f0b:6cb::1 prefixlen 64
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 89727
----

Funktioniert jetzt alles gut. Ich bekomm am Handy jetzt ipv4 und ipv6 zugewiesen,
alles funktioniert. Der ping ueber den VPN Tunnel ist auch gar ned mal sooooo schlecht:

----
stefan@kronos ~> ping -4 google.de
PING google.de (216.58.198.131) 56(84) bytes of data.
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=1 ttl=58 time=24.7 ms
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=2 ttl=58 time=25.2 ms
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=3 ttl=58 time=24.8 ms
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=4 ttl=58 time=25.6 ms
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=5 ttl=58 time=25.8 ms
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=6 ttl=58 time=25.5 ms
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=7 ttl=58 time=25.4 ms
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=8 ttl=58 time=25.0 ms
64 bytes from fra02s17-in-f3.1e100.net (216.58.198.131): icmp_seq=9 ttl=58 time=24.9 ms
^C
--- google.de ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8013ms
rtt min/avg/max/mdev = 24.744/25.254/25.837/0.365 ms
----

----
stefan@kronos ~> ping -6 google.de
PING google.de(fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003)) 56 data bytes
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=1 ttl=58 time=25.4 ms
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=2 ttl=58 time=25.2 ms
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=3 ttl=58 time=26.0 ms
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=4 ttl=58 time=31.1 ms
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=5 ttl=58 time=25.6 ms
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=6 ttl=58 time=25.6 ms
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=7 ttl=58 time=26.1 ms
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=8 ttl=58 time=25.4 ms
64 bytes from fra02s17-in-x03.1e100.net (2a00:1450:4001:806::2003): icmp_seq=9 ttl=58 time=26.0 ms
^C
--- google.de ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8011ms
rtt min/avg/max/mdev = 25.282/26.313/31.147/1.736 ms
----

Als Vergleich dazu, mein native ipv4:

----
stefan@kronos ~> ping -4 google.de
PING google.de (172.217.19.195) 56(84) bytes of data.
64 bytes from fra02s21-in-f3.1e100.net (172.217.19.195): icmp_seq=1 ttl=57 time=23.9 ms
64 bytes from fra02s21-in-f3.1e100.net (172.217.19.195): icmp_seq=2 ttl=57 time=23.3 ms
64 bytes from fra02s21-in-f3.1e100.net (172.217.19.195): icmp_seq=3 ttl=57 time=23.9 ms
64 bytes from fra02s21-in-f3.1e100.net (172.217.19.195): icmp_seq=4 ttl=57 time=24.0 ms
^C
--- google.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 23.390/23.843/24.085/0.267 ms
----

Kann man so lassen glaub ich. :)