IPv6/on-openvpn-v6: Unterschied zwischen den Versionen
Leo (Diskussion | Beiträge) (→Bugs) |
Leo (Diskussion | Beiträge) (→Installations-/Konfigurations-/Troubleshooting-Anleitung) |
||
Zeile 16: | Zeile 16: | ||
opkg update | opkg update | ||
opkg-oni install on-openvpn-v6 | opkg-oni install on-openvpn-v6 | ||
− | Wir benötigen hier eine sehr neue Firmware Version (>= [https://downloads.opennet-initiative.de/openwrt/testing/0.5.6-unstable-2784-243aa37e/packages/i386_pentium4/opennet/ | + | Wir benötigen hier eine sehr neue Firmware Version (>= [https://downloads.opennet-initiative.de/openwrt/testing/0.5.6-unstable-2784-243aa37e/packages/i386_pentium4/opennet/ r2798]). Ansonsten findet er das Paket nicht zum Installieren. |
'''2.''' Es muss nun geprüft werden, ob eine IPv6 Verbindung zum Server gai besteht oder ob hier IPv4 genutzt werden muss. | '''2.''' Es muss nun geprüft werden, ob eine IPv6 Verbindung zum Server gai besteht oder ob hier IPv4 genutzt werden muss. |
Version vom 13. April 2020, 19:45 Uhr
Hinweis: Derzeit befindet sich das on-openvpnv6 Paket im Alpha-Teststadium. |
Das Opennet Paket on-openvpn-v6 soll Opennet Nutzern IPv6 Konnektivität ermöglichen.
Inhaltsverzeichnis |
Funktionsweise
- Voraussetzungen: das Modul on-openvpn muss installiert sein und die Zertifikate für ein User-VPN Tunnel müssen vorhanden sein
- der Opennet Knoten baut eine OpenVPN Verbindung zum Server gai auf (IP: fd32:d8d3:87da::245 , Port: 1700)
- auf gai läuft ein OpenVPN Dienst, welcher Layer2-Verbindungen zur Verfügung stellt (interface: tap-users-v6)
- nach Aufbau des VPN Tunnels, holt sich der Opennet Knoten per DHCPv6 Prefix Delegation einen IPv6 Adressbereich (/60). Adressen aus diesem Bereich werden automatisch per SLAAC an alle Geräte (per radvd Dienst) im LAN (br-lan) verteilt.
- jetzt habe alle Endgeräte eine IPv6 Adressen und kommen ins Internet. DNS geht auch über IPv6.
Installations-/Konfigurations-/Troubleshooting-Anleitung
1. Paket installieren mit
opkg update opkg-oni install on-openvpn-v6
Wir benötigen hier eine sehr neue Firmware Version (>= r2798). Ansonsten findet er das Paket nicht zum Installieren.
2. Es muss nun geprüft werden, ob eine IPv6 Verbindung zum Server gai besteht oder ob hier IPv4 genutzt werden muss.
2.1. IPv6: Testen, ob der Knoten den Server gai per IPv6 erreichen kann mit "ping6 fd32:d8d3:87da::245"
root@AP-2-51:~# ping6 fd32:d8d3:87da::245 PING fd32:d8d3:87da::245 (fd32:d8d3:87da::245): 56 data bytes 64 bytes from fd32:d8d3:87da::245: seq=0 ttl=63 time=15.887 ms 64 bytes from fd32:d8d3:87da::245: seq=1 ttl=63 time=16.456 ms
Wenn der Ping erfolgreich ist, weiter bei Punkt 3 lesen. Wenn der Ping nicht erfolgreich ist, dann könntest du entweder
- auf dem UGW AP, welches dir Internet zur Verfügung stellt den Server gai.on-i.de zusätzlich hinzufügen als UGW Server
- oder dann kann ein Workaround aktiviert werden, welche über IPv4 eine Verbindung zum VPN Server herstellt (Punkt 2.2.)
2.2. IPv4: Testen, ob der Knoten den Server gai per IPv4 erreichen kann mit "ping 192.168.0.245"
root@AP-2-51:~# ping 192.168.0.245 PING 192.168.0.245 (192.168.0.245): 56 data bytes 64 bytes from 192.168.0.245: seq=0 ttl=61 time=44.751 ms 64 bytes from 192.168.0.245: seq=1 ttl=61 time=41.677 ms ^C --- 192.168.0.245 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 41.677/43.214/44.751 ms
Wenn ledigliche eine Verbindung per IPv4 möglich ist, dann muss folgender Befehl ausgeführt werden, damit die Konfigurationsdatei angepasst wird:
root@AP-2-51:~# on-function connect_vpn_v6_server_via_v4 root@AP-2-51:~# /etc/init.d/openvpn restart
3. Warten, bis sich der VPN Tunnel aufgebaut hat (Interface tap-on-user-v6 vorhanden).
Wurde der Tunnel nicht aufgebaut, dann bitte folgende Dinge prüfen:
- ist in uci der VPN Tunnel notiert:
root@AP-2-51:~# uci show | grep openvpn_v6 openvpn.gw_openvpn_v6_fd32_d8d3_87da__245_1700_udp=openvpn openvpn.gw_openvpn_v6_fd32_d8d3_87da__245_1700_udp.enabled='1' openvpn.gw_openvpn_v6_fd32_d8d3_87da__245_1700_udp.config='/var/etc/openvpn-v6//gw_openvpn_v6_fd32_d8d3_87da__245_1700_udp.conf'
- gibt es "verdächtige" Syslog Meldungen
logread
4. Testen der IPv6 Verbindung
Da es derzeit noch einen speziellen Bug/Fehlfunktion gibt (siehe Abschnitt 'Bugs' ganzen unten) müssen wir auf dem Mesh Knoten erstmal folgendes Kommando ausführen:
ip link set br-lan down && ip link set br-lan up
Im Anschluss können wir das externe Interface des Servers gai pingen:
root@AP-2-51:~# ping6 2001:67c:1400:2430::1 PING 2001:67c:1400:2430::1 (2001:67c:1400:2430::1): 56 data bytes 64 bytes from 2001:67c:1400:2430::1: seq=0 ttl=64 time=79.567 ms 64 bytes from 2001:67c:1400:2430::1: seq=1 ttl=64 time=56.208 ms ^C --- 2001:67c:1400:2430::1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 56.208/67.887/79.567 ms
Und ein Test mit Namensauflösung sollte auch funktionieren:
root@AP-2-51:~# ping6 ct.de PING ct.de (2a02:2e0:3fe:1001:302::): 56 data bytes 64 bytes from 2a02:2e0:3fe:1001:302::: seq=0 ttl=57 time=54.822 ms 64 bytes from 2a02:2e0:3fe:1001:302::: seq=1 ttl=57 time=57.331 ms ^C --- ct.de ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 54.822/56.076/57.331 ms
IPv6 only
- auf Opennet Knoten das on-openvpn Modul deaktivieren (nicht deinstallieren!)
- der IPv6 Tunnel sollte natürlich funktionieren
- auf den Endgeräten (Laptop, Handy, ...) IPv4 deaktivieren und IPv6 aktiviert lassen
- auf dem Endgerät folgendes Testen:
root@oni06:~# ping ct.de PING ct.de(redirector.heise.de (2a02:2e0:3fe:1001:302::)) 56 data bytes 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=56 time=49.3 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=2 ttl=56 time=114 ms
root@oni06:~# telnet relay.heise.de 25 Trying 2a00:e68:14:800::19:19... Connected to relay.heise.de. Escape character is '^]'. 220 relay.heise.de ESMTP. EHLO 250-relay.heise.de Hello p200300c4671ec90071d10b583d6c8c71.dip0.t-ipconnect.de [2003:c4:671e:c900:71d1:b58:3d6c:8c71] 250-SIZE 52428800 250-8BITMIME 250-PIPELINING 250-STARTTLS 250 HELP
Status des Pakets
Stand 4.4.2020: Dieses Paket stellt einen ersten Versuch da, einigen Opennet Nutzern Zugriff per IPv6 zu ermöglichen. Abhängig von den Tests wird sich herausstellen, in welche Richtung weiter entwickelt wird.
Einschränkungen
- Opennet Knoten muss eine IPv6 Verbindung zu gai haben
- Gateway Server ist fest kodiert
- gai: 256x /60 Prefixe (siehe https://dev.opennet-initiative.de/browser/on_ansible/roles/ugw-server-ipv6/files/dhcpd6.conf)
Bugs
Wahl des falschen Absenderadresse
Nachdem der oben beschriebene Tunnel erfolgreich aufgebaut werden konnte, schlägt ein Ping6 ins Internet vom Mesh Knoten fehl. Ursache ist hier, dass als Absenderadresse die IPv6 Adresse des br-lan Interfaces gewählt wird. Dies darf nicht sein. Denn anschließend versucht der Server gai diese Adresse per NDP aufzulösen über das VPN Interface und dies schlägt fehlt, weil unser Knoten nicht antwortet. Anscheinend ignoriert unser Knoten NDP Anfragen auf Sub-Interfaces. Als Workaround reicht ein einfache down/up des br-lan Interfaces. Dies korrigiert das Verhalten unseres Knotens. Ab jetzt schickt der AP Anfragen mit der IPv6 Adresse des tap Interfaces. Hier funktioniert auch das NDP.
Übrigens: Dieses Fehlverhalten gilt nur für den Opennte Knoten. Alle Geräte, welche bspw. im LAN angeschlossen sind, funktionieren tadellos, auch ohne den Workaround.
Details
Es folgt eine detailierte Beschreibung des Fehlerverhaltens.
Ausgangslage:
#IPv6 Tunnel ist aufgebaut und Interface ist vorhanden root@AP-1-xx:~# ip -6 addr show tap-on-user-v6 11: tap-on-user-v6: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 inet6 2a0a:4580:1010:2:401b:81ff:fea9:7f9f/64 scope global dynamic noprefixroute valid_lft 86067sec preferred_lft 14067sec inet6 fe80::401b:81ff:fea9:7f9f/64 scope link valid_lft forever preferred_lft forever
#Ping6 geht bis zu gai (tap Interace) root@AP-1-xx:~# ping6 2a0a:4580:1010:2::1 PING 2a0a:4580:1010:2::1 (2a0a:4580:1010:2::1): 56 data bytes 64 bytes from 2a0a:4580:1010:2::1: seq=0 ttl=64 time=12.708 ms 64 bytes from 2a0a:4580:1010:2::1: seq=1 ttl=64 time=12.181 ms
Wenn man jetzt aber eine public IP anpingt, dann kommt keine Rückantwort. root@AP-1-xx:~# ping6 ct.de PING ct.de (2a02:2e0:3fe:1001:302::): 56 data bytes ^C 41 packets transmitted, 0 packets received, 100% packet loss
Wenn man gleichzeitig auf gai den Verkehr mitschneidet, sieht man folgendes:
root@gai:~# tcpdump -i tap-users-v6 ... 21:08:19.506904 IP6 2a0a:4580:1010:1ec0::1 > redirector.heise.de: ICMP6, echo request, seq 0, length 64 21:08:19.522095 IP6 fe80::9c27:fdff:fe2e:c761 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a0a:4580:1010:1ec0::1, length 32 21:08:20.508725 IP6 2a0a:4580:1010:1ec0::1 > redirector.heise.de: ICMP6, echo request, seq 1, length 64 21:08:20.522282 IP6 fe80::9c27:fdff:fe2e:c761 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a0a:4580:1010:1ec0::1, length 32 21:08:21.507367 IP6 2a0a:4580:1010:1ec0::1 > redirector.heise.de: ICMP6, echo request, seq 2, length 64 21:08:21.546270 IP6 fe80::9c27:fdff:fe2e:c761 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a0a:4580:1010:1ec0::1, length 32 21:08:22.507473 IP6 2a0a:4580:1010:1ec0::1 > redirector.heise.de: ICMP6, echo request, seq 3, length 64
Der AP sendet mit der Absender-IP ...1ec0::1. Diese IP gehört zum br-lan Interface (siehe unten). Es fehlt aber eine Antwort auf das Neighbor Solicitation durch den AP.
root@AP-1-xx:~# ip -6 addr show br-lan 5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 inet6 2a0a:4580:1010:1ec0::1/60 scope global dynamic noprefixroute valid_lft 2590646sec preferred_lft 603446sec inet6 fe80::16cc:20ff:feed:2641/64 scope link valid_lft forever preferred_lft forever root@AP-1-xx:~# ip -6 addr show tap-on-user-v6 11: tap-on-user-v6: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 inet6 2a0a:4580:1010:2:401b:81ff:fea9:7f9f/64 scope global dynamic noprefixroute valid_lft 86067sec preferred_lft 14067sec inet6 fe80::401b:81ff:fea9:7f9f/64 scope link valid_lft forever preferred_lft forever
In der Regel hilft dann das br-lan Interface neuzustarten:
root@AP-1-xx:~# ip link set br-lan down && ip link set br-lan up root@AP-1-xx:~# root@AP-1-xx:~# ping6 ct.de PING ct.de (2a02:2e0:3fe:1001:302::): 56 data bytes 64 bytes from 2a02:2e0:3fe:1001:302::: seq=0 ttl=57 time=27.136 ms 64 bytes from 2a02:2e0:3fe:1001:302::: seq=1 ttl=57 time=27.969 ms
Wenn man jetzt einen tcpdump auf gai macht, sieht das folgendermaßen aus:
21:09:xx.430295 IP6 2a0a:4580:1010:2:401b:81ff:fea9:7f9f > redirector.heise.de: ICMP6, echo request, seq 0, length 64 21:09:xx.530294 IP6 fe80::9c27:fdff:fe2e:c761 > 2a0a:4580:1010:2:401b:81ff:fea9:7f9f: ICMP6, neighbor solicitation, who has 2a0a:4580:1010:2:401b:81ff:fea9:7f9f, length 32 21:09:xx.542442 IP6 2a0a:4580:1010:2:401b:81ff:fea9:7f9f > fe80::9c27:fdff:fe2e:c761: ICMP6, neighbor advertisement, tgt is 2a0a:4580:1010:2:401b:81ff:fea9:7f9f, length 24 21:09:xx.445336 IP6 redirector.heise.de > 2a0a:4580:1010:2:401b:81ff:fea9:7f9f: ICMP6, echo reply, seq 0, length 64 21:09:xx.431197 IP6 2a0a:4580:1010:2:401b:81ff:fea9:7f9f > redirector.heise.de: ICMP6, echo request, seq 1, length 64 21:09:xx.446277 IP6 redirector.heise.de > 2a0a:4580:1010:2:401b:81ff:fea9:7f9f: ICMP6, echo reply, seq 1, length 64 21:09:xx.431430 IP6 2a0a:4580:1010:2:401b:81ff:fea9:7f9f > redirector.heise.de: ICMP6, echo request, seq 2, length 64 21:09:xx.446739 IP6 redirector.heise.de > 2a0a:4580:1010:2:401b:81ff:fea9:7f9f: ICMP6, echo reply, seq 2, length 64
Jetzt sendet der AP mit Absender-IP des tap-on-user-v6 Interfaces. Und hier beantwortet der AP auch die neighbor soliciation Nachrichten.
Unklar ist, warum dieses Verhalten auftritt.