search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.84k stars 495 forks source link

General | Preferring IPv4 over IPv6 for apt-get #472

Closed k-plan closed 6 years ago

k-plan commented 8 years ago

@Fourdee

Modern GNU/Linux systems prefer IPv6 addresses over IPv4 when being presented with a choice. As an example, Debian’s apt-get update over IPv4 and IPv6.

Problem:

If your local network has dual-stack and using for example a IPv6 tunnel broker to get full IPv6 support, apt source mirrordirector.raspbian.org can/will redirect to a slow or far away IPv6 update server, depends on tunnel broker IPv6 prefix delegation.

When installing software, updates or switching features (e.g. WiFi >netplug) in DietPi, it can be very slow.

If you have a ISP without native IPv4 access, which is using DS-lite or Carrier-grade NAT it can be the opposite way around.

So what can we do? Since apt-get version 0.9.7.9~exp1 where is the options to force IPv4 or IPv6 using.

Testing:

apt-get --version

apt-get -o Acquire::ForceIPv4=true update

apt-get -o Acquire::ForceIPv6=true update

Solution:

You can make this persistent for all apt-get in the future (so you don't have to provide the arguments to make this work) by doing the following. This will make a configuration file for apt and apt-get to parse, which will then include the ForceIPv4 true options going forward for all apt-get runs.

echo 'Acquire::ForceIPv4 "true";' | tee /etc/apt/apt.conf.d/99force-ipv4

Or for IPv6 force:

echo 'Acquire::ForceIPv6 "true";' | tee /etc/apt/apt.conf.d/99force-ipv6

Like to see this apt option in dietpi-config or dietpi-software as well as parameter in /boot/dietpi.txt

Thanks for your help and attention.

cu k-plan

usefull Links:

https://www.vultr.com/docs/force-apt-get-to-ipv4-or-ipv6-on-ubuntu-or-debian

http://askubuntu.com/questions/759524/problem-with-ipv6-sudo-apt-get-update-upgrade

Fourdee commented 8 years ago

@k-plan

Considering an option called:

This way, we can apply to apt-get now, then we can add other programs/network configs (if we find any) at a later date?

Fourdee commented 8 years ago

@k-plan

Seems to work (I dont have a IPv6 network). Will add to dietpi-config. image

Fourdee commented 8 years ago

@k-plan

Think I may leave this option out of dietpi-config. Its very "custom/advanced" and most users don't need this option. It will most likely confuse the user, especially considering we already have a IPv6 toggle option in there. Whats your thoughts?

For now, you can set this via:

#/DietPi/dietpi/func/dietpi-set_hardware        preferipversion none/ipv4/ipv6
#eg
/DietPi/dietpi/func/dietpi-set_hardware preferipversion ipv6

To have this applied on a fresh image automatically, in dietpi.txt, set https://github.com/Fourdee/DietPi/blob/439dabd9f3f1eb394c418e85f9c4c1b56a9fd851/dietpi.txt#L162:

#eg: 
prefer_ipversion=ipv6

Maybe if we have more programs/settings that can use this "preference" we can add it to the menu?

k-plan commented 8 years ago

@Fourdee

Think I may leave this option out of dietpi-config . Its very "custom/advanced" and most users don't need this option.

It is okay for me. Yes, very special feature, only for people who have or use a dual stack network . But IPv6 is the future - IPv4 is dead. :smile:

/DietPi/dietpi/func/dietpi-set_hardware preferipversion ipv4

puh, very long for typing in, but anyway. I have a look into your code and dietpi.txt

#Prefer IPversion (eg: apt-get) | none / ipv4 / ipv6
prefer_ipversion=none

precise/clearly/better it will be at the moment to say "all" or "both":

#Prefer IP version (for: apt-get) | all / ipv4 / ipv6
prefer_ipversion=all

It will most likely confuse the user, especially considering we already have a IPv6 toggle option in there.

This will work too, but it is not a good idea, like you tell the user: ipv6

Maybe if we have more programs/settings that can use this "preference" we can add it to the menu?

Hoping not. If more ISP and users have more and more real dual stack with native ipv4 and ipv6 access, it will become better. And more server (debian update) will grow up in your country with more bandwidth. Only to prefer ipv6 over ipv4 in software (apt-get, dns, browser, etc) is not the solution to grow up ipv6 faster. :wink:

Fourdee commented 8 years ago

@k-plan

precise/clearly/better it will be at the moment to say "all" or "both":

:+1:

Maybe auto? As in "Let the system decide"?

k-plan commented 8 years ago

@Fourdee

Maybe auto? As in "Let the system decide"?

:+1: Yes, or maybe any? Still better then all or both.

:smile:

Fourdee commented 8 years ago

@k-plan Went for auto, but your right, none wasn't good :+1:

Fourdee commented 8 years ago

Marking this as completed. Please reopen if required.

MichaIng commented 6 years ago

@Fourdee @k-plan Okay, we need to rethink this:

To me it looked like IPv6 gets preferred by default, thus instead of forcing IPv6, just removing the prefer IPv4 would also work? And does "force" IPv6 break access to only-ipv4 servers? If not we could add all these settings to dietpi-config IPv6 toggle and maybe find a better default set for this/a way to reliably check if IPv6 is really available/IPv4 at least not native?

k-plan commented 6 years ago

@MichaIng

Puh, so eine schwierige Netzwerk Frage, sorry @Fourdee , no english.

it is impossible to access an IPv6 configured server from most mobile devices.

Ja und nein. Du vermischt hier etwas.

Per WLAN, über deinen kabelgebundenen ISP, können die mobile devices sehr wohl auf "IPv6 only" zugreifen, wenn du native dual stack hast und z.B via RA IPv6 Adressen den Geräten zuteilen lässt.

Über deinen UMTS/LTE/GSM ISP hast du für Deutschland sicher Recht, da deinem mobile devices keine IPv6 Adresse vom ISP zugewiesen wird. Viele hier arbeiten noch mit NAT und weisen ihren Kunden eine private IPv4 Adresse zu. Da liegen die Probleme. Nativer Dual Stack kostet halt Geld und Man-Power, senkt die Gewinne der Aktionäre und man kann Kunden nicht mehr so einfach einbremsen ... (Stichwort: end-to-end connectivity)

I have dual stack internet connection (IPv4+IPv6 addresses)

Darf ich fragen, ein native dual Stack oder so einen DS-lite oder Carrier-grade NAT Mist? Kannst mir auch deinen Provider nennen, dann bekomme ich das auch selbst raus.

but completely disabled IPv6/DHCPv6 for internal network

Schlechte Idee, aus Sicht eines Netzwerkers .. 😃

By default, many APT and wget requests still try to access via IPv6, even if the kernel module got disabled,

Ja, daher würde ich es auch nicht abschalten. Das machen übrigens auch alle moderne Browser so. Wie schon gesagt. IPv4 ist Tod, da finden auch seit über 10 Jahren keine Entwicklungen der RFC mehr statt.

leading to unbelievable long access timeouts or even unlimited tries. This is totally annoying, even on installing fresh Debian images via their mini.iso.

Korrekt. Ja, daher würde ich IPv6 auch nicht abschalten. Daher auch mein Vorschlag hier vor Jahren, für IPv4 prefer, da es damals kaum vernünftig angebundene Server mit IPv6 gab.

this could lead to the same issue, if someone has no native IPv4 address?

Da dürfte das umgekehrte passieren. Bei denen sollte der IPv4 Zugriff langsamer sein als der IPv6 Zugriff, wenn die so einen DS-Lite oder Carrier-grade NAT haben. Ein "reiner" IPv6 Kunden-Surf-ISP ist mir nicht bekannt. Damit dürftest du im Moment so ungefähr mehr als die Hälfte des Internets unerreichbar machen.

Edit:

6eed6d655871b9676e1d69a4f5405c46

799e0579c0f7146d5a903a2d2c1ddd8c

e44769a71398dab39be9795ca2f0da50

Du siehst, es kommt aber auch immer darauf an, was die Gegenstelle selbst bevorzugt oder wie das Peering zwischen den ISP selber geregelt wird.

180107-0009

MichaIng commented 6 years ago

@k-plan Vielen Dank für deine ausführliche Antwort. Bestens jemanden zu haben, der sich mit Netzwerken auskennt 😃!

Also ich habe tatsächlich natives dual stack von meinem Provider: http://www.willytel.de/ Das ist ein für Hamburg localer Partner von https://www.wilhelm-tel.de/

Aber wenn ich dich jetzt richtig verstehe, dann dürfte ein forcieren von IPv4 als Standard für APT und wget für alle user funktionieren, einzig für welche mit nativem IPv6 und Zugriffsversuch auf IPv6-affinen Server etwas lahm sein? Klingt dann aber tatsächlich nach der besten lösen, eine die wenigstens für alle überhaupt funktioniert. Wenn jemand dann in der dietpi-config (oder vorher via dietpi.txt) IPv6 wählt, sollte man diese Präferenzen natürlich wieder entfernen.

Noch mal zur Bestätigung des Problems:

So finally:

k-plan commented 6 years ago

@MichaIng

Puh, wo fange ich jetzt am besten an? Versuche es am Anfang etwas allgemeiner zu halte.

Generell gilt: ( https://de.wikipedia.org/wiki/IPv6#IPv6_und_DNS )

Ein IPv6-fähiger Rechner sucht in der Regel mittels DNS zu einem Namen zunächst nach dem RR-Typ AAAA, dann nach dem RR-Typ A. Laut der Default Policy Table in RFC 3484 wird die Kommunikation über IPv6 gegenüber IPv4 bevorzugt, falls festgestellt wird, dass für eine Verbindung beide Protokolle zur Verfügung stehen. Die Anwendungsreihenfolge der Protokolle ist meistens aber auch im Betriebssystem und auf der Anwendungsebene, also z. B. im Browser, einstellbar.

DNS selber ist zuerst einmal unabhängig von IPv4 oder IPv6. Die gelieferte Antwort ist immer die gleiche. Lass uns damit einmal ein wenig herum spielen.

https://toolbox.googleapps.com/apps/dig/#ANY/dietpi.com

Ah, dietpi.com hat nur einen A Record also nur IPv4 Konnektivität und liefert nur einen einzigen Host (Node) zurück: 185.101.92.145 Und damit ist direkt völlig klar, wer genutzt wird.

https://toolbox.googleapps.com/apps/dig/#ANY/security.debian.org

security.debian.org hat A Record und AAAA Record also IPv4 und IPv6 Konnektivität und liefert mehrere Möglichkeiten (multiple host). Hier würde ohne Eingriff apt die IPv6 Hosts bevorzugen. Welchen davon regelt das OS oder kann auch die Anwendung regeln je nach Implementierung (Round Robin oder most prefix bits)

https://toolbox.googleapps.com/apps/dig/#ANY/cdn-aws.deb.debian.org

Das ist also eigentlich nur eine Weiterleitung: https://toolbox.googleapps.com/apps/dig/#A/cdn-aws.deb.debian.org https://toolbox.googleapps.com/apps/dig/#AAAA/cdn-aws.deb.debian.org

Zu IPv6 allgemein:

Zwei lesenswerte Links: https://kompendium.infotip.de/ipv6.html https://de.wikipedia.org/wiki/IPv6

Besonderheiten:

Was ist das Fazit?

Zu deinen persönlichen netzspezifischen Fragen, kann ich von hier aus nur wenig belastbare Aussagen treffen. Da fehlen mir einfach zu viele Konfigurationsdetails. Sorry. Andererseits ist das auch gut so, sonst wäre ja jeder Gast in deinem LAN. 😃

  • On toggle IPv6 I would:
    • disable IPv6: disable kernel module + ForceIPv4 for APT+wget
    • enable IPv6: enable kernel module + remove IPv4 forcing (instead of forcing IPv6)

Da könnte ich fast so unterschreiben, wobei das disable IPv6 eigentlich keine gute Idee ist. Eine Anwendungen benötigen/wollen wohl einen laufenden IPv6 Stack (Web Server? - aber wirklich wissen tut ich das nicht) und die Link-Local-Adresse tut erst einmal nicht weh. Internet Konnektivität lässt sich mit dieser allein so nicht herstellen. Ich glaube, das weiss auch das Betriebssystem.

  • Forcing IPv6 seems to completely break access to any IPv4 source, which can't be wanted by any user, and if, (s)he would need to apply this exotic settings manually outside of DietPi.

Puh, da müsste ich noch mal dran basteln, aber ja, der Nachsatz stimmt auf alle Fälle!

  • Of course most elegant would be to test own IPv6 connectivity and auto apply the correct settings on first run

Ja. Aber in Europa/USA würde ich im Moment trotzdem IPv4 noch bevorzugen. In Asien sieht die Sache sicher anders aus.

k-plan commented 6 years ago

Quick check with last testing image: http://dietpi.com/downloads/testing/v6.0/DietPi_RPi-ARMv6-Stretch.7z

Notice:

root@RPi-Zero-W-v6:~# cat /etc/apt/apt.conf.d/99-dietpi-force-ipv4
Acquire::ForceIPv4 "true";

root@RPi-Zero-W-v6:~# cat /etc/apt/apt.conf.d/99force-ipv
Acquire::ForceIPv4 "true";

Do we realy need two entries?

IPv6 check:

root@RPi-Zero-W-v6:~# rm  /etc/apt/apt.conf.d/99*

root@RPi-Zero-W-v6:~# ls -lah /etc/apt/apt.conf.d/
total 24K
drwxr-xr-x 2 root root 4.0K Jan  9 19:59 .
drwxr-xr-x 6 root root 4.0K Jan  7 14:10 ..
-rw-r--r-- 1 root root  769 Sep 13 16:47 01autoremove
-r--r--r-- 1 root root 1.3K Nov 29 01:21 01autoremove-kernels
-rw-r--r-- 1 root root  161 Nov 29 01:37 50raspi
-rw-r--r-- 1 root root  182 May 21  2017 70debconf

root@RPi-Zero-W-v6:~# apt-get clean

root@RPi-Zero-W-v6:~# apt-get -o Acquire::ForceIPv6=true update
Hit:1 https://www.mirrorservice.org/sites/archive.raspbian.org/raspbian stretch InRelease
Ign:2 https://archive.raspberrypi.org/debian stretch InRelease
Err:3 https://archive.raspberrypi.org/debian stretch Release
  500  Internal Server Error
Reading package lists... Done
E: The repository 'https://archive.raspberrypi.org/debian stretch Release' does no longer have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

... and in a second terminal windows at once (to check, if apt-get works via IPv6)

tcpdump -i eth0 -vv ip6

😒

MichaIng commented 6 years ago

@k-plan

Ein IPv6-fähiger Rechner sucht in der Regel mittels DNS zu einem Namen zunächst nach dem RR-Typ AAAA, dann nach dem RR-Typ A. Laut der Default Policy Table in RFC 3484 wird die Kommunikation über IPv6 gegenüber IPv4 bevorzugt, falls festgestellt wird, dass für eine Verbindung beide Protokolle zur Verfügung stehen. Die Anwendungsreihenfolge der Protokolle ist meistens aber auch im Betriebssystem und auf der Anwendungsebene, also z. B. im Browser, einstellbar.

Verstehe ich es richtig, dass in dem Fall tatsächlich das Problem sein könnte, dass der Router, als IPv6 fähiges Endgerät (vom Netz aus gesehen), sich in meinem Fall für IPv6 entscheidet? Sonst verstünde ich nicht, wieso es ohne native IPv6 Anbindung nie Probleme gab.

Man könnte versuchen IPv6 auf den Linux Kisten komplett zu deaktivieren.

Ich dachte, das wäre mit Deaktivieren des Kernelmoduls der Fall, da alle weiteren, in einschlägigen Foren zu findenden Settings diesbezüglich sogar Fehlermeldungen geben, wenn das Kernelmodul gar nicht geladen ist. Habe jedenfalls schon länger geforscht, und nichts weiter gefunden, wie man Debian/Raspbian davon überzeugen könnte, dass IPv6 wirklich nicht geht. Wenn der Router selbst da die Entscheidung trifft, wäre die Sache klar, wenn auch etwas ungünstig gelöst (Fritz!Box).

Ich habe gerade noch mal die Einstellung meiner Fritte überprüft:

€: Kurzer Nachtest: Mein Desktop kann problemlos per Browser auf https://[2001:4f8:1:c::15] (deb.debian.org, also jedenfalls der Mirror, auf den ich weitergeleitet werde) zugreifen. Meine frisch aufgesetzte DietPi VM kann dies trotz aktivierem IPv6 kernel modul nicht, weder per APT (ohne ForceIPv4) noch per wget. Ist also immer wahrscheinlicher ein VM/Bridged Problem in meinem Netzwerk.

Naja lange Rede kurzer Sinn Long story short:

About generally offer to disable IPv6: After all I think you are right, the setting does not make too much sense. But still it could reduce some overhead, if anyway no IPv6 is available from ISP side. As said, the connection issues I face with my VMs is independent from kernel module state.

About double files:

k-plan commented 6 years ago

@MichaIng

Verstehe ich es richtig, dass in dem Fall tatsächlich das Problem sein könnte, dass der Router, als IPv6 fähiges Endgerät (vom Netz aus gesehen), sich in meinem Fall für IPv6 entscheidet?

Ja. Das ist ein Router (der verbindet Netz-Segmente) und kein Client. Hat der IPv6 an einer Schnittstelle (nach außen, zum ISP) aktiv, macht er SLAAC auf der anderen automatisch (nach innen, zum LAN) . Oder halt DHCPv6 (nach innen, zum LAN), wenn man es denn konfiguriert.

in einschlägigen Foren zu findenden Settings diesbezüglich sogar Fehlermeldungen geben, wenn das Kernelmodul gar nicht geladen ist.

Das ist das, was ich meinte. Wenn man die Kernelmodule für IPv6 deaktiviert, hagelt es in den Logs Fehlermeldungen, weil der ipv6 network stack nicht läuft. Schlechte Idee, wenn Anwendung darauf zugreifen wollen.

Fritte - das ist Home-User-Staff. Das muss einfach immer laufen, sonst wird der Support Aufwand für den ISP zu groß.

.. wobei im Falle von keinem anderen DHCPv6 Server im Netz dann SLAAC ausgewählt bleibt.

Und damit bekommen deine IPv6 fähigen Geräte auch eine Global Local Unicast vom Router via SLAAC zugewiesen. Das muss so, sonst wäre es auch kein IPv6 Router, der Netz Segmente verbindet.

Wenn ich bei den Portfreigaben auf IPv6 gehe, kann ich sogar Weiterleitungen für einige Geräte einrichten, die bereits mit zugehörigen IPv6 Adressen/Suffixen gelistet sind.

Eigentlich Unfug, wenn da nicht mittels iptables6 vorher auf dem Router etwas weggefiltert worden ist. Der Router sollte normalerweise deinen gesamten vom ISP zugeteilte ipv6 Prefix (/64 ) forwarden (nach innen) und ICMPv6 regelt den Rest. Aber da wird die Fritz!Box aus "Sicherheitsgründen" sicherlich wieder was dran herum drehen und sich nicht in die Karten schauen lassen. Daher stehe ich nicht auf so ein Zeug. Aber durch den "Routerzwang" deines ISP hast du sicher nicht viele andere Chancen.

Ich nehme an, dass es jedenfalls per SLAAC schwierig ist einem per Netzwerkbrücke angeschlossenen VM eine separate IPv6 Adresse zuzuweisen/es sich diese holt, und sie deshalb da ausgenommen sind.

Hmm ... nö, in meiner VM geht das. Solange die VM Netzwerkbrücke ihre eigne MAC Adresse hat. Allerdings ist der Host auch kein Windows und ich habe einen "richtigen" Router, den ich voll konfigurieren kann. So sieht das bei mir aus mit IPv6 SLAAC auf dem Router: 180109-0004-c

k-plan commented 6 years ago

@k-plan Also your tests show, that forcing IPv6 can lead to problems, even that it is generally working on the machine. Did you try to set prefer-family = IPv6 within /etc/wgetrc and then access an only-ipv4 server via wget? So we would know, if we can toggle this setting together with enabling/disabling IPv6.

@MichaIng 

root@RPi-Zero-W-v6:~# cat /etc/wgetrc | grep prefer-family
prefer-family = IPv4

root@RPi-Zero-W-v6:~# wget http://dietpi.com/downloads/binaries/rpi/dietpi_rpi_kernel_4.9.zip
--2018-01-09 22:36:02--  http://dietpi.com/downloads/binaries/rpi/dietpi_rpi_kernel_4.9.zip
Resolving dietpi.com (dietpi.com)... 185.101.92.145
Connecting to dietpi.com (dietpi.com)|185.101.92.145|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80596670 (77M) [application/zip]
Saving to: ‘dietpi_rpi_kernel_4.9.zip’

dietpi_rpi_kernel_4.9.zip            100%[====================================================================>]  76.86M  2.78MB/s    in 18s

2018-01-09 22:36:20 (4.19 MB/s) - ‘dietpi_rpi_kernel_4.9.zip’ saved [80596670/80596670]
root@RPi-Zero-W-v6:~# nano /etc/wgetrc

root@RPi-Zero-W-v6:~# cat /etc/wgetrc | grep prefer-family
prefer-family = IPv6

root@RPi-Zero-W-v6:~# wget http://dietpi.com/downloads/binaries/rpi/dietpi_rpi_kernel_4.9.zip
--2018-01-09 22:37:55--  http://dietpi.com/downloads/binaries/rpi/dietpi_rpi_kernel_4.9.zip
Resolving dietpi.com (dietpi.com)... 185.101.92.145
Connecting to dietpi.com (dietpi.com)|185.101.92.145|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80596670 (77M) [application/zip]
Saving to: ‘dietpi_rpi_kernel_4.9.zip.1’

dietpi_rpi_kernel_4.9.zip.1          100%[====================================================================>]  76.86M  7.61MB/s    in 8.6s

2018-01-09 22:38:04 (8.98 MB/s) - ‘dietpi_rpi_kernel_4.9.zip.1’ saved [80596670/80596670]

Like so? Or something else to do?

MichaIng commented 6 years ago

@k-plan @Fourdee

So how we handle it in DietPi:

On firstrun/for images:

On disabling IPv6 within dietpi-config:

On enabling IPv6 within dietpi-config:

IPv4 settings within dietpi-set_core_environment can be removed, as this is already done within preparation script?

Everybody agree? Then I will make PR.

@k-plan

Das ist das, was ich meinte. Wenn man die Kernelmodule für IPv6 deaktiviert, hagelt es in den Logs Fehlermeldungen

Nee, also bei mir gibts keine Fehlermeldungen, nur wenn man dann weitere Settings zum deaktivieren von IPv6 vornimmt, hauptsächlich net.ipv6.conf.all.disable_ipv6 = 1 (entsprechend für alle interfaces) im sysctl, denn diese sind ja überhaupt nur verfügbar, wenn das Kernelmodul nicht geladen ist. Wir hatten in DietPi halt beides gemacht und dann sagt sysctl, dass es die Option net.ipv6... gar nicht gibt: https://github.com/Fourdee/DietPi/issues/1119

Komische Option. Keine Ahnung was die damit genau meinen könnten.

Achso, wenn keine IPv6 Internetverbindung aktiv ist, dann weist der Router den Clients selbst "Unique Local Addresses" zu, damit die wenigstens untereinander kommunizieren können.

Eigentlich Unfug, wenn da nicht mittels iptables6 vorher auf dem Router etwas weggefiltert worden ist.

Ja, also ich persönlich finde es so eigentlich ganz gut. Heißt ja, dass die Geräte hinterm Router ähnlich wie beim klassischem IPv4 NAT zunächst nicht direkt erreichbar sind, sondern halt nur über die Ports, die explizit zugelassen sind, auch wenn es im Falle von IPv6 dann vom Router aktiv geblockt werden muss, anstatt nur ein Forwarding sein zu lassen. So jedenfalls verstehe ich das, wo die Clients ja prinzipiell direkt erreichbar sind/vom Netz aus eine eindeutige IP(v6) haben. Das beantwortet somit meine frühere Frage, dass mein lokales Netzwerk trotz IPv6 ohne aktive Einstellungen geschützt bleibt.

Hmm ... nö, in meiner VM geht das. Solange die VM Netzwerkbrücke ihre eigne MAC Adresse hat.

Also eigene MAC Adressen haben die VMs und werden auch vom Router als "eigenständige" Clients erkannt, sodass ich da fixe IPv4 Adressen zuweisen kann. Aber der Router erkennt auch, dass sie vom Desktop (Laptop mit angeschlossener Peripherie 😉) aus zugreifen (blaue Pfeile rechts): vm Irgendwie damit muss es in Kombination mit Windows Host+Fritzbox zusammenhängen, dass IPv6 auch bei frischen/unkonfigurieren Debian VMs überhaupt nicht geht.

Meine VM Adaptereinstellungen sehen identisch aus, außer, dass ich den virtio Adaptertyp gewählt habe. Für den wird überhaupt keine Firmware benötigt und er scheint generell etwas performanter zu sein, als wenn tatsächliche Hardware simuliert wird. Habe gerade noch mal gecheckt: IPv6 kann der grundsätzlich auch 😉.

Ist aber im Endeffekt auch egal nun, wie wir es bei DietPi handhaben, ändert sich ja nicht.

Ahh, danke für den wget test, also wenn jemand aktiv IPv6 aktiviert, dann können wir diese Option gleich mit ändern, zum fördern neuer Technologien oder so, kann jedenfalls dann ja nicht schaden.

Nun warte ich nur noch darauf, dass Fourdee bestätigt, dass wir diese doppelte 99dietpi-ipv in dietpi-set_core_environment nicht setzen brauchen, dann erstelle ich einen PR.

k-plan commented 6 years ago

@MichaIng @Fourdee

So how we handle it in DietPi: .... Everybody agree?

I will vote approval for now.

But please keep in mind, the hole ipv6 story is not really completely implement into DietPi at the moment.

MichaIng commented 6 years ago

@k-plan Yeah that's true. But if I understand right, than using DHCP automates in case IPv6 configuration, SLAAC does anyway in background?

Anyway the only thing that really changes with my suggestions for now is, that we remove the APT ForceIPv6 in any case.

But we could keep in mind, to add some optional/additional ipv6 interface configuration, when we find time. Of course this would need your knowledge as well as testing 😃. Okay maybe I will play around by times to get IPv6 for my VMs running, then I can also do tests.

k-plan commented 6 years ago

@MichaIng

Nee, also bei mir gibts keine Fehlermeldungen, nur wenn man dann weitere Settings zum deaktivieren von IPv6 vornimmt, hauptsächlich net.ipv6.conf.all.disable_ipv6 = 1 (entsprechend für alle interfaces) im sysctl, denn diese sind ja überhaupt nur verfügbar, wenn das Kernelmodul nicht geladen ist. Wir hatten in DietPi halt beides gemacht und dann sagt sysctl, dass es die Option net.ipv6... gar nicht gibt: #1119

Ups, Danke für den Hinweis. War mir entgangen, dass Ihr das schon gefixed habt. Als ich das zur Einführung getestet war es halt Mist. Da es für mich aber kein Thema war, blieb IPv6 halt immer an. Ab jetzt schalte ich es wieder ab. 😄 ... mal schauen ...

VM ... vom Desktop (Laptop mit angeschlossener Peripherie 😉) ...

Hmm ... laufen die VMs über eine WLAN Verbindung des Laptops?

Das beantwortet somit meine frühere Frage, dass mein lokales Netzwerk trotz IPv6 ohne aktive Einstellungen geschützt bleibt.

Hmm, ich tippe einmal, wir zwei definieren Netzwerk Sicherheit unterschiedlich. NAT, oder genauer gesagt IPv4 PAT, bringt keine Sicherheit. Ist und bleibt "Bastelei am Symptom", ein Kunstgriff, weil damals in den RFC der Adressraum zu klein gewählt wurde. Clevere Marketing Strategen, die damit Kosten sparen und Geld verdienen konnten (aka AVM, Post, uvm.) haben das als Sicherheitsfeature verkauft und 99,2% glauben das auch. Am IPv6 Schutz stört mich die Intransparenz. Was bitte wird da genau gemacht, gefiltert oder geblockt? Warum kann man das nicht selbst konfigurieren? Nutzer erst einmal in Sicherheit wiegen, bis zum nächsten Sicherheitslüke in der AVM Firmware, was wieder einen riesigen Aufschrei erzeugt. Da sind die jetzt schon einige Male richtig böse mit aufgeschlagen. Komfort vs. Sicherheit.

Achso, wenn keine IPv6 Internetverbindung aktiv ist, dann weist der Router den Clients selbst "Unique Local Addresses" zu, damit die wenigstens untereinander kommunizieren können.

Nein. Eigentlich wollte ich das aussparen und mich nicht so tief mit dem Fritz!Box Micro-Kosmos beschäftigen.

Die lokale (LAN) Kommunikation ist mittels Link-Local-Adressen (Präfix: fe80::/10) möglich, innerhalb einer "Layer2 Broadcast Domäne" wobei der Begriff hier falsch gewählt ist. Müsste besser Link-Local-Multicast-Domäne heißen.

Link-Local-Adressen (Verbindungslokale Unicast-Adressen) sind nur innerhalb von geschlossenen Netzsegmenten gültig. Router dürfen Datenpakete mit Link-Local Adressen als Quelle oder Ziel nicht an andere Links weiterleiten. Link-Local-Adressen sind zwar eindeutige Einzelverbindungen, können aber durchaus mehrfach vorkommen, z.B. wenn ein Gerät (z.B. Server) über zwei oder mehr Netzwerk-Interfaces verfügt. Verbindungslokale Adressen werden u.a. von einem Host bei der automatischen Adresskonfiguration und zur Informationen über die Anwesenheit von anderen IPv6-Hosts und -Routern verwendet.

Daher wurde Link-Local-Adressen und Zonen-Index eingeführt: Nachzulesen und sehr gut erklärt hier

Unique Local-Adressen (ULAs) sind global einzigartig und sollen nur innerhalb von Sites verwendet werden. Sie entsprechen den Privaten Adressen des IPv4. Sie dürfen von speziell konfigurierten Routern, z.B. in Tunnel, weitergeleitet werden. ULAs in diesem Adressbereich werden lokal mit einem Zufallsverfahren erzeugt. Ein Sonderfall darin ist der von AVM verwendete Präfix: fd00::/8, indem Adressen von einem Administrator manuell vergeben werden können. Die Problematik der Unique Local sowie Pro und Contra sind hier gut erklärt: https://www.comconsult-research.de/ipv6-adresse-qual/ Die ursprüngliche Idee war, zwei Sites (LAN) zu verbinden. Site Local-Adressen, die sind aber seit 2004 überholt (deprecated). Wurde dann durch Unique Local-Adressen (ULAs) ersetzt, was aber auch nicht so ganz ausgegoren ist, siehe obigen Link.

Dein Zitat stammt aus der Hilfe zu deiner Fritz!Box, wenn ich das richtig sehe: https://www.macuser.de/threads/fritzbox-ipv6-probleme-im-lan-hilfe-bei-einstellungen.775732/

Daher meine Aussage

Komische Option. Keine Ahnung was die damit genau meinen könnten.

Einen Vorteil, den ich in der statischen Vergabe von ULA sehe, das damit lokale DNS Auflösungen möglich sind. Vorsicht ist jedoch geboten, wenn du dich über einen VPN Tunnel (ipv6 inside) mit deiner Fitz!Box verbindest, aus einem anderen Fritz!Box LAN, der die gleich ULA verwendet und seinen Clients zuteilt.

Was AVM sich bei dieser Option gedacht haben könnte, wobei die Begrifflichkeit trotzdem unglücklich gewählt ist, kann man hieraus vielleicht erahnen: https://mum.mikrotik.com//2018/EU/agenda/ES

Building an IPv4/IPv6 Environment with Dynamic IP Based WAN In this talk a proof of concept on how to build a network environment which is based on a dynamic IP ISP connection is explained.

ISPs like Deutsche Telekom VDSL provide IPv4 and IPv6 addresses which change between 24h and longer depending on the data plan.

By using RouterOS scripting, this solution takes care of:

  • Updating DDNS records for IPv4 and IPv6
  • Updating IPv6 firewall and forwarding rules on IPv6 prefix change
  • Updating IPv6 DNS static addresses on IPv6 prefix change
  • Providing ULA and GUA IPv6 addresses to internal clients
  • Providing static IPv6 DNS service to internal clients

Sorry, aber eigentlich wollte ich das schwierige Thema Unique Local-Adressen geschickt aussparen. Das verwirrt mehr, als es nützt. Und Fritz!Boxen auch, weil das ein Micro-Kosmos ist und nicht zu meinen Kernkompetenzen zählt.

k-plan commented 6 years ago

@MichaIng

Yeah that's true. But if I understand right, than using DHCP automates in case IPv6 configuration, SLAAC does anyway in background?

Du kommst aber auch immer mit den IPv6 Kinken ums Eck! 😃 DHCPv6 ist auch so eine "nachgeflickte" Aktion, wie Unique Local-Adressen.

Ja, SLAAC muss immer laufen. Es werden immer RA vom Router gesendet und RS von Clients angefragt, trotz DHCPv6. Dieser verteilt nur zusätzliche Netzwerksegment Parameter. Ohne SLAAC könnten Router und Clients keine eigene Link-Local-Adresse erzeugen. Und diese ist Pflicht, denn ohne fe80:: gibt es gar keine IPv6 Kommunikation.

Besser als hier kann ich es auch nicht erklären: https://www.elektronik-kompendium.de/sites/net/1902141.htm

Noch Fragen? 🙊 🙉 😃

Edit:

Wenn du mal ein wenig herum spielen willst: IPv6 Training VirtualMachines

MichaIng commented 6 years ago

@k-plan

Hmm ... laufen die VMs über eine WLAN Verbindung des Laptops?

Jep, jetzt wo dus sagst, erinnere ich mich, dass es da Einschränkungen für VMs gab.

Hmm, ich tippe einmal, wir zwei definieren Netzwerk Sicherheit unterschiedlich. NAT, oder genauer gesagt IPv4 PAT, bringt keine Sicherheit. Ist und bleibt "Bastelei am Symptom", ein Kunstgriff, weil damals in den RFC der Adressraum zu klein gewählt wurde. Clevere Marketing Strategen, die damit Kosten sparen und Geld verdienen konnten (aka AVM, Post, uvm.) haben das als Sicherheitsfeature verkauft und 99,2% glauben das auch. Am IPv6 Schutz stört mich die Intransparenz. Was bitte wird da genau gemacht, gefiltert oder geblockt? Warum kann man das nicht selbst konfigurieren? Nutzer erst einmal in Sicherheit wiegen, bis zum nächsten Sicherheitslüke in der AVM Firmware, was wieder einen riesigen Aufschrei erzeugt. Da sind die jetzt schon einige Male richtig böse mit aufgeschlagen. Komfort vs. Sicherheit.

Ja, ich bin eher ein Laie, was Netzwerk angeht. Aber so wie ich es verstehe, lässt sich im Fall von IPv4 PAT von "außen" ja zunächst tatsächlich nur der Router direkt ansprechen. Wenn dieser nicht aktiv die Anfragen an bestimmte Clients im internen Netzwerk weiterleitet, dann ich der Zugriff und wenigstens die offensichtlichen Angriffe damit blockiert, oder habe ich das falsch verstanden? Klar gibt es immer Sicherheitslücken, liegt irgendwie in der Natur der Sache, ob nun beim Router, oder in der Firewall des Clients selbst, oder in der Hardware/Firmware: siehe WPA2 Sicherheitslücke, Meltdown und Spectre. Aber immerhin bietet der Router eine extra Barriere, auch wenn man trotzdem die Clients dahinter unabhängig davon sichern sollte. Auch wenn diese strickte Trennung der Adressräume vor- und hinter Router ursprünglich andere Gründe gehabt haben mag, für mich ist es irgendwie eine "schöne" Lösung, wenn das komplette Intranet halt völlig unabhängig vom Internet läuft, die Adressen komplett eigenständig gewählt werden und Kommunikation läuft. Und dann halt ein zentrales Gerät, was sämtliche Zugriffe von und nach "außen", falls genehmigt, regelt. Aber Schönheit liegt im Auge des Betrachters und Geschmack ist immer auch Gewöhnung 😉. Ja, was/wie genau im Fall von IPv6 geblockt wird, bzw. um was für eine Art von Firewall es sich da handelt, kann man sicherlich bei AVM, ggf. auf Nachfrage, erfahren, aber mich als Laie interessieren diese Details dann doch weniger, bzw. ich könnte damit ohnehin nix anfangen. Ich muss darauf vertrauen, dass zumindest eine grundsätzliche Sicherheit gegeben ist, so wie ich das auch bei Software-Firewalls und Antiviren Programmen tun muss. Der Rest ist dann proaktives Handeln und gesunder Menschenverstand bei allen Arten von Internetaktivitäten. Bisher bin ich immerhin gut damit gefahren: Seit bestimmt 10 Jahren keinen (erkenntlichen) Virus mehr gehabt nur kurzzeitig SSH brute force Attacken aus dem Ausland auf meinen Pi (bei aktiver key authentication + pass phrase), bis ich extern auf einen anderen Port gewechselt bin, bzw. inzwischen nur noch Netzwerk-intern SSH erlaube.

Ich hebe mir deinen letzten Link mal für später auf, ist tatsächlich nicht so ganz einfache Kost als Laie 😆.

k-plan commented 6 years ago

@MichaIng

Jep, jetzt wo dus sagst, erinnere ich mich, dass es da Einschränkungen für VMs gab.

👍 😄

Wenn ich das richtig verstanden habe, liegt das auch wieder an den RFC des WiFi Standards.

Bridged Client Mode Issues

https://unix.stackexchange.com/questions/16854/why-is-virtualbox-bridged-networking-slow

Keine Ahnung ob der Trick hier funktioniert: https://superuser.com/questions/1162055/virtualbox-vm-with-bridged-adapter-cant-access-internet-while-host-can

Ich habe halt eine Ethernet Kabel dran und das funktioniert einfach. 😃

Das mit deiner Fritz!Box ist schon in Ordnung für mich, wenn es das für dich auch ist.

Wie für 90% der anderen Deutschen Internet-Nutzer auch. Was natürlich wieder das Angriffspotential und die Hacking-Motivation für die Geräte vergrößert. Komfort und Intransparenz erhöhen das Fehlerrisiko weiter und somit die Gefahren. Wichtig ist, dass man sich darüber bewusst wird.

Der Rest ist dann proaktives Handeln und gesunder Menschenverstand bei allen Arten von Internetaktivitäten.

Jep, "Brain 1.0" ist das aller Wichtigste! Dies kann auch durch keine Fritz!Box ersetzen werden.

Mehr wollte ich damit gar nicht zum Ausdruck bringen. Alles gut! 😄

MichaIng commented 6 years ago

@k-plan

Keine Ahnung ob der Trick hier funktioniert: https://superuser.com/questions/1162055/virtualbox-vm-with-bridged-adapter-cant-access-internet-while-host-can

Hehe, der Kerl hat irgendwie doppelt gebridged. Bei Windows muss man bei aktuellem VirtualBox ja keine Bridge mehr einrichten. VirtualBox installiert so einen "Bridged Network Driver" (wie im Screenshot rechts innerhalb der Netzwerkkarten-Einstellungen zu sehen), sodass man in der Software nur noch "bridged" und das Internet-Netzwerkgerät auswählen muss. Der hat ja irgendwie die VM mit einer unter Windows eingerichteten Bridge gebridged oder so 😆. Internet haben meine VMs und ich kann innerhalb des local networks web services unter DietPi testen, das reicht. Dass IPv6 aktuell nicht geht, ist ja eher nebensächlich und immerhin haben wir so einen potentiellen Bug identifiziert und mit dem neuen preparation script gefixt 😎.

k-plan commented 6 years ago

@MichaIng

hmm ... ich könnte aber schon gut leiden, dass IPv6 in deinen VM richtig funktioniert.

Wie sollen wir sonst die IPv6 Implementation in DietPi voran bringen? 😄 Dan ist ja so ein Dual-Stack Verweigerer. 🙊 😄

Oder darf ich dir Hardware (OrangePi One) zum spielen und testen schicken? Das Angebot steht noch.

Edit: Sorry, bei Windows bin ich mit XP ausgestiegen. Daher musst du meine Unwissenheit entschuldigen.

MichaIng commented 6 years ago

@k-plan Von mir aus verschiebe ich IPv6 erst mal, bis DietPi v6.0 raus ist und die ggf. erste Bugwelle in v6.1 eingearbeitet ist.

Dein Angebot mit dem OrangePi One habe wiederum ich bewusst noch nicht angenommen. Ich aktuell genug Zeit in DietPi und so wie ich mich kenne, würde mit einem neuen Spielzeug viel dazu kommen, bzw. ein bisschen würde ich mich auch verpflichtet fühlen den OrangePi aktiv für zusätzliche Tests und Imageerstellungen zu benutzen. Aber das wird mir momentan zu viel, jedenfalls auch hier bis v6.0 über die Bühne ist. Aber es ist in jedem Fall super nett von dir und ich behalte es im Hinterkopf 😃.

k-plan commented 6 years ago

@MichaIng

Ja, alles in Ordnung, passt schon. IPv6 hat Zeit. Wartet eh' schon über 10 Jahre auf die flächendeckende Einführung. 😄

Nein. Alles ohne Verpflichtung und Druck. Alles kann, nichts muss. Ist nur ein Hobby und soll Freude und vor allem Spass bereiten. Melde dich, wenn die Zeit reif ist.

MichaIng commented 6 years ago

PR is there: https://github.com/Fourdee/DietPi/pulls