staging.inyokaproject.org

Hallo Forum,

bei mir läuft auf einem Intel NUC7i3 Ubuntu Server 18.04.2 LTS.

Hauptsächlich nutze ich den Server für Home Assistant https://www.home-assistant.io/ und kann leider ein python modul nicht nutzen da es versucht per IPv6 zu kommunizieren.

Anfragen (Beispielcode s.u.) terminieren immer mit einem timeout.

Grundsätzlich scheint IPv6 zu funktionieren aber ich konnte leider keine Informationen finden was ich wo noch ergänzen muss.

Kann mir jemand beim anpassen meiner netplan config helfen? Ich hänge den Python Code sowie die netplan cfg an.

Vielen Dank!

python code:

 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

Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> import socket
>>> import ssl
>>> from datetime import datetime, timedelta
>>> ctx = ssl.create_default_context()
>>> host_info = socket.getaddrinfo('0x711.de', 443)
>>> family = host_info[0][0]
>>> sock = ctx.wrap_socket(socket.socket(family=family), server_hostname='0x711.de')
>>> sock.settimeout(10.0)
>>> sock.connect(('0x711.de', 443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/ssl.py", line 1109, in connect
    self._real_connect(addr, False)
  File "/usr/lib/python3.6/ssl.py", line 1096, in _real_connect
    socket.connect(self, addr)
socket.timeout: timed out
>>> sock.getpeercert()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/ssl.py", line 900, in getpeercert
    self._check_connected()
  File "/usr/lib/python3.6/ssl.py", line 864, in _check_connected
    self.getpeername()
OSError: [Errno 107] Transport endpoint is not connected
>>>

netplan config:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

~ » cat /etc/netplan/01-eno1.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      dhcp6: no
      addresses: [192.168.0.27/24]
      gateway4: 192.168.0.1
      nameservers:
        addresses: [1.0.0.1, 1.1.1.1, "2606:4700:4700::1111", "2606:4700:4700::1001"]
 

Ausschnit aus systemd-resolve --status für die NIC:

Link 2 (eno1)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 1.0.0.1
                      1.1.1.1
                      2606:4700:4700::1111
                      2606:4700:4700::1001
                      2a02:908:2:a::1
                      2a02:908:2:b::1

chrisvoid schrieb:

[…] versucht per IPv6 zu kommunizieren. […] Anfragen (Beispielcode s.u.) terminieren immer mit einem timeout.

Du musst natürlich als erstes das Netzwerk konfigurieren bzw. konfigurieren lassen. In der Regel benötigt man mindestens – jeweils für IPv4 und für IPv6:

1. Eine IP-Adresse mit Scope global,

2. den Leitweg zum eigenen Router,

3. eine Default-Route für alles andere.

Die zweite Aufgabe ist dann die Verifizierung der erzielten Netzwerk-Konfiguration:

ip -br link
ip -4 route ; ip -4 addr
ip -6 route ; ip -6 addr

[…] Kann mir jemand beim anpassen meiner netplan config helfen?

Ich würde nicht indirekt über das proprietäre Netplan konfigurieren, sondern beim Server direkt systemd-networkd benutzen. Anleitungen findest Du im hiesigen Wiki.

Danke für deine Antwort.

Trotz des ausführlichen wiki Artikels bleibe ich leider erfolglos.

Ich habe in /etc/systemd/network/ folgende Datei angelegt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

root@metis systemd/network » cat 40-dhcpv6-staticV4.network 
[Match]
Name=eno1
[Network]
DHCP=ipv6
Address=192.168.0.27/24
Gateway=192.168.0.1
DNS=1.0.0.1
DNS=1.1.1.1
DNS=2606:4700:4700::1111
DNS=2606:4700:4700::1001

Danach meine Änderungen mit folgenden Befehlen neu geladen:

systemctl enable systemd-resolved; systemctl start systemd-resolved; rm /etc/resolv.conf; ln -s /var/run/systemd/resolve/resolv.conf /etc/resolv.conf

systemctl restart systemd-networkd

Im Unitymedia Plasterouter ist unter DHCPv6 Stateful angehakt mit einer nicht von mir veränderten Startadresse.

Leider terminiert das python Beispiel weiterhin mit einem timeout....

Im Anhang die von dir genannten ip Befehle. Ich hab die IPv6 Adresse gekürzt, auch wenn ich zugegebenermaßen nur ein hauchdünnes 1/3 Wissen zu v6 besitze, ist es nicht sonderlich klug hier die Adresse zu veröffentlichen.

 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

» ip -br link|grep eno1                                                                                                                       130 ↵
eno1             UP             94:...:fd <BROADCAST,MULTICAST,UP,LOWER_UP> 

» ip -4 route |grep eno1
default via 192.168.0.1 dev eno1 proto static 
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.27 

» ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.0.27/24 brd 192.168.0.255 scope global eno1
       valid_lft forever preferred_lft forever

» ip -6 route |grep eno1
2a02:...:/64 dev eno1 proto kernel metric 202 mtu 1500 pref medium
2a02:...:/64 via fe80::ae22:5ff:fefa:10ea dev eno1 proto ra metric 1024 pref medium
2a02:...:2f00::/64 dev eno1 proto ra metric 1024 pref medium
fe80::/64 dev eno1 proto kernel metric 256 pref medium
default via fe80:...:10ea dev eno1 metric 202 mtu 1500 pref medium
default via fe80:...:fefa:10ea dev eno1 proto ra metric 1024 mtu 1500 pref high

 » ip -6 addr      
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a02:...:f434/128 scope global dynamic noprefixroute 
       valid_lft 574753sec preferred_lft 272353sec
    inet6 fe80:...:4ffd/64 scope link 
       valid_lft forever preferred_lft forever

Danke für die Mühe aber letztendlich habe ich die Lösung gefunden....

Die remoteseitige Firewall sollte auch für ipv6 konfiguriert sein...

Eine letzte Frage habe ich noch, kann ich nachdem ich nun die systemd regeln angelegt habe einfach netplan mit apt-get purge entfernen?

Viele Grüße und nochmals Danke!

chrisvoid schrieb:

[…] einfach netplan mit apt-get purge entfernen?

Wäre radikal und konsequent, aber ich habe das noch nicht ausprobiert. Es wäre jedenfalls ein möglicherweise tiefer Eingriff in die Distribution und könnte unbekannte Nebeneffekte haben.

Ich würde aber alle Konfigurationsdateien *.yaml aus den Verzeichnissen /etc/netplan/ und /run/netplan/ entfernen bzw. reduzieren auf eine Datei mit:

network:
  version: 2

(Das gilt, wenn man über systemd-networkd konfigurieren möchte, wer NetworkManager benutzen will, muss diesen noch als renderer angeben.)