IPv6/on-openvpn-v6: Unterschied zwischen den Versionen
Leo (Diskussion | Beiträge) |
Leo (Diskussion | Beiträge) (Doku für IPv4 Workaround hinzugefügt) |
||
Zeile 13: | Zeile 13: | ||
===Installations-/Konfigurations-/Troubleshooting-Anleitung=== | ===Installations-/Konfigurations-/Troubleshooting-Anleitung=== | ||
− | + | '''1.''' Paket installieren mit | |
− | + | 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/ r2784]). 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 | root@AP-2-51:~# ping6 fd32:d8d3:87da::245 | ||
PING fd32:d8d3:87da::245 (fd32:d8d3:87da::245): 56 data bytes | 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=0 ttl=63 time=15.887 ms | ||
64 bytes from fd32:d8d3:87da::245: seq=1 ttl=63 time=16.456 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 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 | 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=openvpn | ||
Zeile 30: | Zeile 50: | ||
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' | 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 | 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=== | ===IPv6 only=== | ||
− | |||
* auf Opennet Knoten das on-openvpn Modul deaktivieren (nicht deinstallieren!) | * auf Opennet Knoten das on-openvpn Modul deaktivieren (nicht deinstallieren!) | ||
Zeile 69: | Zeile 117: | ||
* Gateway Server ist fest kodiert | * 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) | * 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. |
Version vom 7. April 2020, 21:21 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-oni install on-openvpn-v6
Wir benötigen hier eine sehr neue Firmware Version (>= r2784). 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 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.