IPv6/on-openvpn-v6: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(Bugs)
(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/ r2784]). Ansonsten findet er das Paket nicht zum Installieren.
+
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, 18:45 Uhr


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

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.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge