IPv6 bei IONOS-VPS klemmt

[Christoph Schneegans]

Hallo allerseits!

Ich betreibe mehrere VPS-Server bei IONOS unter Ubuntu 21.04 und 21.10.
Bei gefühlt der Hälfte der Starts dieser Server funktioniert IPv6 nicht
richtig; insbesondere tun ICMPv6-Pings weder aus- noch eingehend, und
Web- und SSH-Server sind nur per IPv4 erreichbar.

Ich weiß mir bislang nicht anders zu helfen als mit einem "systemctl
reboot" (oder ggf. mehreren), bis IPv6 funktioniert.

Wenn ich per

journalctl --boot=-0

das Journal eines Starts betrachte, bei dem IPv6 nicht funktioniert, so
gibt "cloud-init" folgendes aus:

cloud-init[...]: ci-info: +++++++++++++++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++++++++++++++
cloud-init[...]: ci-info: +--------+------+-----------------------------+-----------------+--------+-------------------+
cloud-init[...]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
cloud-init[...]: ci-info: +--------+------+-----------------------------+-----------------+--------+-------------------+
cloud-init[...]: ci-info: | ens192 | True | 87.106.192.96 | 255.255.255.255 | global | 00:50:56:0d:e9:d7 |
cloud-init[...]: ci-info: | ens192 | True | fe80::250:56ff:fe0d:e9d7/64 | . | link | 00:50:56:0d:e9:d7 |
cloud-init[...]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
cloud-init[...]: ci-info: | lo | True | ::1/128 | . | host | . |
cloud-init[...]: ci-info: +--------+------+-----------------------------+-----------------+--------+-------------------+

Bei einem Start mit funktionierendem IPv6 kommt jedoch diese Zeile
hinzu:

cloud-init[...]: ci-info: | ens192 | True | 2001:8d8:1801:2f7::1/128 | . | global | 00:50:56:0d:e9:d7 |

2001:8d8:1801:2f7::1 ist tatsächlich die IPv6-Adresse, die ich dem
Server über das "Cloud Panel" von IONOS zugewiesen habe.

Die Konfiguration von cloud-init habe ich nicht selber angefasst. Die
beiden Dateien

- /etc/cloud/cloud.cfg
- /etc/cloud/cloud.cfg.d/05_logging.cfg

entsprechen exakt denen des Maintainers (vgl.
<https://packages.ubuntu.com/impish/cloud-init>). Zusätzlich finde ich
auf allen IONOS-Servern eine Datei /etc/cloud/cloud.cfg.d/90_dpkg.cfg
mit dem Inhalt

# to update this file, run dpkg-reconfigure cloud-init
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, DigitalOcean, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma,
SmartOS, Bigstep, Scaleway, AliYun, Ec2, CloudStack, Hetzner, IBMCloud, Oracle, Exoscale, RbxCloud, UpCloud, Vultr, None ]

sowie eine Datei /etc/cloud/cloud.cfg.d/99_ui.cfg mit dem Inhalt

# datasource_list configuration

datasource_list: [ UI , None ]

datasource:
UI:
timeout: 10
retries: 5
sec_between: 10

network:
config: disabled

Ich nehme an, dass "UI" hier für "United Internet" steht und IONOS die
beiden Dateien zusätzlich ins Betriebssystem-Image gepackt hat. Auch
wenn ich diese Dateien versuchsweise lösche, verbessert sich die
IPv6-Stabilität allerdings nicht.

Irgendwelche Ideen?

(Bitte Followup-To-Header beachten.)

--
<https://schneegans.de/windows/no-8.3/> · Windows ohne PROGRA~1

[Marco Moock]

Am Mon, 25 Oct 2021 21:27:37 +0200
schrieb "Christoph Schneegans" <chri...@schneegans.de>:

> Ich nehme an, dass "UI" hier für "United Internet" steht und IONOS die
> beiden Dateien zusätzlich ins Betriebssystem-Image gepackt hat. Auch
> wenn ich diese Dateien versuchsweise lösche, verbessert sich die
> IPv6-Stabilität allerdings nicht.

Behält denn der Server dauerhaft diese IPv6-Adresse?
Ist eine Firewall bei dir aktiv (iptables, ufw usw.)?
Kommen denn eingehende ICMPv6-Pakete an?
Es gibt "tolle" Firewall-Admins, die ICMP als Teufelszeug ansehen und
gleich blockieren, samt den Folgen wie PathMTU-Blackhole.
Ggf. mal einen Sniffer da laufen lassen.

[Marc Haber]

"Christoph Schneegans" <chri...@schneegans.de> wrote:
>Ich betreibe mehrere VPS-Server bei IONOS unter Ubuntu 21.04 und 21.10.
>Bei gefühlt der Hälfte der Starts dieser Server funktioniert IPv6 nicht
>richtig; insbesondere tun ICMPv6-Pings weder aus- noch eingehend, und
>Web- und SSH-Server sind nur per IPv4 erreichbar.

Was sagen denn ip -6 addr und ip -6 route im gut- und im schlechtfall?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Christoph Schneegans]

Marc Haber schrieb:

> "Christoph Schneegans" <chri...@schneegans.de> wrote:
>>Ich betreibe mehrere VPS-Server bei IONOS unter Ubuntu 21.04 und 21.10.
>>Bei gefühlt der Hälfte der Starts dieser Server funktioniert IPv6 nicht
>>richtig; insbesondere tun ICMPv6-Pings weder aus- noch eingehend, und
>>Web- und SSH-Server sind nur per IPv4 erreichbar.
>
> Was sagen denn ip -6 addr und ip -6 route im gut- und im schlechtfall?

Ich habe den Server per Skript ca. 50-mal gestartet und die Ergebnisse
protokolliert. Die Auswertung ergab, dass das Vorhandensein der Zeile

cloud-init[...]: ci-info: | ens192 | True | 2001:8d8:1801:2f7::1/128

doch nicht mit der IPv6-Erreichbarkeit korreliert, d.h. es gibt wider
Erwarten Schlechtfälle mit und Gutfälle ohne diese Zeile.

Die Ausgabe von "ip -6 addr" ist sogar völlig konstant:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:8d8:1801:2f7::1/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe0d:e9d7/64 scope link
valid_lft forever preferred_lft forever

Anders jedoch "ip -6 route": Die Ausgabe

::1 dev lo proto kernel metric 256 pref medium
2001:8d8:1801:2f7::1 dev ens192 proto kernel metric 256 pref medium
fe80::/64 dev ens192 proto kernel metric 256 pref medium
default via fe80::250:56ff:fe8b:bf4d dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high
default via fe80::250:56ff:fe8b:9902 dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high

erscheint genau in allen Schlechtfällen und umgekehrt

::1 dev lo proto kernel metric 256 pref medium
2001:8d8:1801:2f7::1 dev ens192 proto kernel metric 256 pref medium
fe80::/64 dev ens192 proto kernel metric 256 pref medium
default via fe80::250:56ff:fe8b:9902 dev ens192 proto ra metric 1024 expires 2sec hoplimit 64 pref high
default via fe80::250:56ff:fe8b:bf4d dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high

in allen Gutfällen, d.h. es kommt offenbar auf die Reihenfolge der
Gateways

fe80::250:56ff:fe8b:bf4d
fe80::250:56ff:fe8b:9902

an?! Ich bin mir keiner Schuld bewusst, denn diese Gateways dürften doch
wohl per DHCPv6 bezogen werden und somit von IONOS vorgegeben sein.

[Marco Moock]

Am Wed, 27 Oct 2021 21:38:05 +0200
schrieb "Christoph Schneegans" <chri...@schneegans.de>:

> 2001:8d8:1801:2f7::1/128

Ist das wirklich so gewollt?
Normalerweise gibt es da ein richtiges Netz (kann ja ggf. klein sein).

> Ich bin mir keiner Schuld bewusst, denn diese Gateways dürften doch
> wohl per DHCPv6 bezogen werden und somit von IONOS vorgegeben sein.

Sniffer nehmen und schauen.
Normalerweise kommen die durch die IPv6-Router-Advertisements.
Ggf. bietet DHCPv6 zusätzlich auch so ne Option, aber das
Router-Advertisement ist der normale Weg für die Routing-Einträge bei
IPv6.
Entferne doch mal jeweils eine Route (damit der nur eine nutzen kann)
und teste dann, ob die Pakete rausgehen und ankommen.

[Christoph Schneegans]

Marco Moock schrieb:

> Behält denn der Server dauerhaft diese IPv6-Adresse?

Ja. Das sind Webserver mit zugehöriger Domain.

> Ist eine Firewall bei dir aktiv (iptables, ufw usw.)?

ufw ist aktiv:

~# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To Action From
-- ------ ----
80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere
22/tcp ALLOW IN Anywhere
80/tcp (v6) ALLOW IN Anywhere (v6)
443/tcp (v6) ALLOW IN Anywhere (v6)
22/tcp (v6) ALLOW IN Anywhere (v6)

Ich glaube eher nicht, dass die Firewall das Problem ist.

--
<https://schneegans.de/windows/safer/> · SAFER mit Windows

[Marco Moock]

Am Wed, 27 Oct 2021 21:47:24 +0200
schrieb "Christoph Schneegans" <chri...@schneegans.de>:

> Ich glaube eher nicht, dass die Firewall das Problem ist.

abstellen und dann testen.
So kann man die schonmal ausschließen.

[Jakob Hirsch]

On 2021-10-27 21:38, Christoph Schneegans wrote:
> Anders jedoch "ip -6 route": Die Ausgabe

...

> default via fe80::250:56ff:fe8b:bf4d dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high
> default via fe80::250:56ff:fe8b:9902 dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high
> erscheint genau in allen Schlechtfällen und umgekehrt

...

> default via fe80::250:56ff:fe8b:9902 dev ens192 proto ra metric 1024 expires 2sec hoplimit 64 pref high
> default via fe80::250:56ff:fe8b:bf4d dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high

Hm, quasi das gleiche Problem hab ich auf meinem IONOS-VServer auch, nur
dass das "gute" GW fe80::1 ist:

# ip -6 route show default
default via fe80::1 dev ens192 proto ra metric 1024 expires 3sec
hoplimit 64 pref high
default via fe80::250:56ff:fe8b:fb17 dev ens192 proto ra metric 1024
expires 4sec hoplimit 64 pref high

Manchmal ist die Reihenfolge vertauscht, dann geht tatsächlich nichts
mehr raus. Wenn ich dann fe80::250:56ff:fe8b:fb17 manuell lösche, tut's
wieder, kurz darauf taucht das GW aber wieder auf (klar, RA).

mtr meldet entsprechend im Gutfall als ersten Hop fd8b::2, im
Schlechtfall fd8b::3.

Da das momentan nur ein Rumspiel-Server ist (die kleinste Variante für
1€/Monat), bin ich dem noch nicht weiter nachgegangen... wenn ich nicht
der einzige mit dem Problem bin, wäre das wohl ein Fall für den Support
(oder zumindest für das Forum).

Gemeinsam haben wir noch Ubuntu (bis vor kurzem 21.04, jetzt 21.10),
aber ich glaube eher weniger, daß es daran liegt. Ich wollte sowieso mal
Fedora drauf ziehen (wenn es geht, beim ersten Versuch ist der Kernel
schon beim Booten ausgestiegen), wäre evt. mal gut für einen
Kreuzvergleich...

[Christoph Schneegans]

Jakob Hirsch schrieb:

> Da das momentan nur ein Rumspiel-Server ist (die kleinste Variante für
> 1€/Monat), bin ich dem noch nicht weiter nachgegangen... wenn ich nicht
> der einzige mit dem Problem bin, wäre das wohl ein Fall für den Support
> (oder zumindest für das Forum).

Hat IONOS ein Forum? Ich kenne https://forum.1und1.de/ zwar, aber da
geht es um DSL und Mobilfunk.

Ich habe nun eine E-Mail an sup...@ionos.de geschrieben. Diese Adresse
wird zwar nicht groß beworben, aber in der Vergangenheit habe ich so
Antworten erhalten. Ich habe jedenfalls keine Lust, dieses nicht ganz
triviale Problem per Telefon oder Chat zu beschreiben.

[Christoph Schneegans]

Christoph "Ingrid" Schneegans schrieb:

> Ich habe nun eine E-Mail an sup...@ionos.de geschrieben. Diese Adresse
> wird zwar nicht groß beworben, aber in der Vergangenheit habe ich so
> Antworten erhalten.

Mit dem Support ging es per E-Mail erst einige Male hin und her.
Schließlich habe ich einem IONOS-Techniker den root-Zugang auf meinen
Server ermöglicht, und dieser hat das Problem offenbar behoben. Bei
knapp 100 weiteren Neustarts hat der Server seitdem jedenfalls stets
IPv6-Konnektivität.

Ich habe aber leider nicht erfahren, was der Techniker nun konkret
geändert hat. Die Ausgaben von "ip -6 addr" und "ip6tables --list" sind
dieselben wie vorher. "ip -6 route" gibt nun (nicht ganz überraschend)
stabil

::1 dev lo proto kernel metric 256 pref medium
2001:8d8:1801:2f7::1 dev ens192 proto kernel metric 256 pref medium
fe80::/64 dev ens192 proto kernel metric 256 pref medium

default via fe80::250:56ff:fe8b:9902 dev ens192 proto ra metric 1024 expires 3sec hoplimit 64 pref high

aus, nachdem ja zuvor im Gutfall am Ende eine zusätzliche Route

default via fe80::250:56ff:fe8b:bf4d dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high

erschienen war und im Schlechtfall deren Reihenfolge zu

default via fe80::250:56ff:fe8b:bf4d ...
default via fe80::250:56ff:fe8b:9902 ...

vertauscht war. Aus der Bash-Historie des Techniker-Eingriffs werde ich
nicht schlau:

root@localhost:~# history
...
9 ip -6 a
10 cat /etc/network/interfaces
11 cat /etc/issue
12 cat /etc/resolv.conf
13 ip -6 a
14 ip6tables -L
15 ip -6 r
16 ::1 dev lo proto kernel metric 256 pref medium
17 2001:8d8:1801:2f7::1 dev ens192 proto kernel metric 256 pref medium
18 fe80::/64 dev ens192 proto kernel metric 256 pref medium
19 default via fe80::250:56ff:fe8b:bf4d dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high
20 ip -6 link set dev ens192 up
21 cd /etc/network/interfaces.d/
22 ls -ahl
23 nc -vz 212.227.31.168 8443
24 exit

Wieso stehen dort in den Einträgen 16–19 Routen im Klartext? Klar, kann
natürlich auch sein, dass der relevante Eingriff nicht in meiner VM,
sondern auf dem VMware-Host stattgefunden hat.

[Paul Muster]

On 09.11.21 03:10, Christoph Schneegans wrote:

> Aus der Bash-Historie des Techniker-Eingriffs werde ich
> nicht schlau:
>
> root@localhost:~# history
> ...
> 9 ip -6 a
> 10 cat /etc/network/interfaces
> 11 cat /etc/issue
> 12 cat /etc/resolv.conf
> 13 ip -6 a
> 14 ip6tables -L
> 15 ip -6 r
> 16 ::1 dev lo proto kernel metric 256 pref medium
> 17 2001:8d8:1801:2f7::1 dev ens192 proto kernel metric 256 pref medium
> 18 fe80::/64 dev ens192 proto kernel metric 256 pref medium
> 19 default via fe80::250:56ff:fe8b:bf4d dev ens192 proto ra metric 1024 expires 1sec hoplimit 64 pref high
> 20 ip -6 link set dev ens192 up
> 21 cd /etc/network/interfaces.d/
> 22 ls -ahl
> 23 nc -vz 212.227.31.168 8443
> 24 exit
>
> Wieso stehen dort in den Einträgen 16–19 Routen im Klartext?

Mausgerutscht im Putty-Fenster. Versehentlicher Rechtsklick (einfügen),
nachdem man die Ausgabe des vorigen Befehls markiert (und damit kopiert)
hatte.

> Klar, kann
> natürlich auch sein, dass der relevante Eingriff nicht in meiner VM,
> sondern auf dem VMware-Host stattgefunden hat.

Mit Sicherheit (auf dem Host oder auf einem Router), denn die o.g.
Befehle verändern nichts.


mfG Paul

[Jakob Hirsch]

On 2021-10-28 17:50, Christoph Schneegans wrote:
> Hat IONOS ein Forum? Ich kenne https://forum.1und1.de/ zwar, aber da
> geht es um DSL und Mobilfunk.

Hoppla, sorry, stimmt, hatte ich falsch in Erinnerung...

[Jakob Hirsch]

On 2021-11-09 03:10, Christoph Schneegans wrote:
> Wieso stehen dort in den Einträgen 16–19 Routen im Klartext? Klar, kann
> natürlich auch sein, dass der relevante Eingriff nicht in meiner VM,
> sondern auf dem VMware-Host stattgefunden hat.

Würde ich auch vermuten, in der shell hatte er ja offenbar nichts
verändert...

Und netterweise gibt es das Problem auf meinem vserver auch nicht mehr,
gibt nur noch eine, gute default route:

default via fe80::1 dev ens192 proto ra metric 1024 expires 3sec ...

Vielleicht ein weitläufigeres Problem im Setup dort, aber kaum zu
glauben, daß das bisher keinen Kunden genug gestört hat, um den Support
zu kontaktieren.

[Marco Moock]

Am Tue, 9 Nov 2021 03:10:30 +0100
schrieb "Christoph Schneegans" <chri...@schneegans.de>:

> 16 ::1 dev lo proto kernel metric 256 pref medium #für Localhost (interface-local), damit der Localhost-Traffic auf dem Rechner bleibt
> 17 2001:8d8:1801:2f7::1 dev ens192 proto kernel metric 256 pref medium #keine Ahnung für was die ist, da ist auch keine Präfixlänge dabei, eigentlich wäre die durch die Defaultroute abgedeckt
> 18 fe80::/64 dev ens192 proto kernel metric 256 pref medium #Route für das Link-Local-Netz auf dem aktiven Ethernet-Interface
> 19 default via fe80::250:56ff:fe8b:bf4d dev ens192 proto ra metric #Standardroute (Default-Gateway) für Internet bzw. andere lokale Netzwerke (site-local und ULA)
> 1024 expires 1sec hoplimit

> Wieso stehen dort in den Einträgen 16–19 Routen im Klartext? Klar,
> kann natürlich auch sein, dass der relevante Eingriff nicht in meiner
> VM, sondern auf dem VMware-Host stattgefunden hat.

Diese Route sind normal und notwendig. Ich habe sie mal kommentiert (mit überlangen Zeilen)

[Paul Muster]

Das war nicht die Frage. Die Frage war, wie diese Routen funktionieren
sollen, wenn man sie - ohne 'ip -6 route add' oder ähnlichem davor - auf
die Shell wirft.

Meine Vermutung, was es mit diesen Shell-History-Einträgen auf sich hat,
habe ich ja bereits geäußert.


mfG Paul

[Marco Moock]

Am Tue, 9 Nov 2021 14:30:26 +0100
schrieb Paul Muster <exp-3...@news.muster.net>:

> Das war nicht die Frage. Die Frage war, wie diese Routen
> funktionieren sollen, wenn man sie - ohne 'ip -6 route add' oder
> ähnlichem davor - auf die Shell wirft.

Gar nicht. Es wäre aber auch irgendwie komisch, diese Routen
einzutragen, speziell link-local und interface-local, denn diese werden
eigentlich vom System da eingetragen. Die Default-Route kommt bei IPv6
eigentlich über das Router-Advertisement, ich kann mir aber auch gut
vorstellen, dass die das nicht aktiv haben und diese daher manuell
eintragen (z.B. per Skript beim Booten).
Was aber die /128er-Route da soll kann ich nicht genau sagen. Das
müsste der TO erfragen.

[Paul Muster]

On 09.11.21 15:01, Marco Moock wrote:
> Am Tue, 9 Nov 2021 14:30:26 +0100
> schrieb Paul Muster <exp-3...@news.muster.net>:

>> Das war nicht die Frage. Die Frage war, wie diese Routen
>> funktionieren sollen, wenn man sie - ohne 'ip -6 route add' oder
>> ähnlichem davor - auf die Shell wirft.

> Gar nicht.

Genau.


mfG Paul

[Marc Haber]

Paul Muster <exp-3...@news.muster.net> wrote:
>Meine Vermutung, was es mit diesen Shell-History-Einträgen auf sich hat,
>habe ich ja bereits geäußert.

Ich stimme Dir da zu, so wird es gewesen sein.

[Christoph Schneegans]

Jakob Hirsch schrieb:

> On 2021-11-09 03:10, Christoph Schneegans wrote:
>> Wieso stehen dort in den Einträgen 16–19 Routen im Klartext? Klar, kann
>> natürlich auch sein, dass der relevante Eingriff nicht in meiner VM,
>> sondern auf dem VMware-Host stattgefunden hat.
>
> Würde ich auch vermuten, in der shell hatte er ja offenbar nichts
> verändert...

Der Support hat mir nun auf Nachfrage bestätigt, dass auf meinem Server
gar nichts geändert wurde.

> Und netterweise gibt es das Problem auf meinem vserver auch nicht mehr,
> gibt nur noch eine, gute default route:
>
> default via fe80::1 dev ens192 proto ra metric 1024 expires 3sec ...

Ja. Ich habe auch noch weitere Server, bei denen IPv6 jetzt
augenscheinlich stabil läuft.

> Vielleicht ein weitläufigeres Problem im Setup dort, aber kaum zu
> glauben, daß das bisher keinen Kunden genug gestört hat, um den Support
> zu kontaktieren.

Tja, sie machen es einem ja auch nicht gerade leicht. Vielleicht wäre
ohne Marcs "Nachtreten" (danke dafür!) meine ursprüngliche Mail gar
nicht erst bearbeitet worden.

[Christoph Schneegans]

Paul Muster schrieb:

> Mausgerutscht im Putty-Fenster.
^^^^^^^^^^^^^

YMMD. :-)

[Paul Muster]

On 11.11.21 03:14, Christoph Schneegans wrote:
> Paul Muster schrieb:

>> Mausgerutscht im Putty-Fenster.
> ^^^^^^^^^^^^^
>
> YMMD. :-)

Das hab' nicht ich mir ausgedacht.

<https://www.spiegel.de/politik/deutschland/afd-beatrix-von-storch-wird-im-netz-verspottet-a-1076209.html>


mfG Paul

[Marc Haber]

"Christoph Schneegans" <chri...@schneegans.de> wrote:
>Vielleicht wäre
>ohne Marcs "Nachtreten" (danke dafür!) meine ursprüngliche Mail gar
>nicht erst bearbeitet worden.

Ich glaube, das hat es nur ein wenig beschleunigt.