TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Moin @ all Seit einigen Tagen werkelt bei mir IPv6 ... neben dem ebenfalls noch laufenden IPv4. Die offenen Fragen werden gsd immer weniger. Im Moment beschäftigt mich die Frage, wie ich am besten mit den ULAs umgehe. Zwischenzeitlich war ich mal der Annahme, dass man ULAs eigentlich gar nicht benötigt, da sich ja alle Clients im Netz des IPS-Prefix befinden und alle Maschinen einfachst über ihren Hostnamen erreicht werden können. Aber dann kam mir der Gedanke, dass das wohl nur solange klappt, wie ein ISP-Prefix gegeben ist.... oder mit anderen Worten, wenn nicht für alle Clients eine Global-Unicast-IP erstellt werden konnte (z.B. kein RA auf Grund eines Fehlers), gibts auch keine Verbindung unter den Clients bzw. zum Server. Also sind die ULAs wohl doch obligatorisch. Aber, und jetzt kommt die Unklarheit... wenn ich das richtig verstanden habe, bekomme ich heute keine ULA mehr vom DHCP-Server resp. der Fritzbox. Also war der erste Gedanke für alle Clients jeweils eine Static-ULA zu vergeben. Aber genau das will ich eigentlich nicht... deswegen die Frage: Wie kann man das am besten automatisieren.... also dergestalt, dass der Client heute auch wieder eine ULA via (quasi-)DHCP bekommt? Momentan habe ich mir als Lösung überlegt, die via DHCP verwendete IPv4 auf IPv6 zu adaptieren. Als Beispiel: Mein IPv4-Lan hat das Netz 10.20.30/24. Dann hätte ein bestimmter Client nach dem Boot vielleicht die IP 10.20.30.5, die ihm von der Fritzbox aus dem DHCP-Range zugewiesen wurde. Mit
ip -f inet -o addr show eth0 | cut -d\ -f 7 | cut -d/ -f 1 | cut -d. -f 4
würde ich nun aus der IP die "5" als (i.ü.s.) LAN-Identifier des Gerätes bekommen. Als ULA-Prefix bietet sich hier das "gleiche" Netz an:
fd00:10:20:30/64 Und via
ip addr add fd00:10:20:30::$GeraeteID/64 dev eth0
hätte ich damit eine zum lokalen IPv4-Netz passende IPv6-ULA fd00:10:20:30::5 generiert. Was mir nur unklar ist... ob das nicht alles zu kompliziert ist und ob es nicht vielleicht einfachere Möglichkeiten gibt, wenn ich keine Static-ULA einrichten möchte. Hat jemand einen Rat für mich?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
... wenn ich das richtig verstanden habe, bekomme ich heute keine ULA mehr vom DHCP-Server resp. der Fritzbox.
Man kann eine Fritzbox, zumindestens die 7490 unter OS 6.60, ohne Trickserei so konfigurieren, dass gleichzeitig der vom Provider zugewiesene IPv6-Prefix und ein selbst gewählter Prefix der Länge 64 aus dem ULA-Bereich fd00::/8 im LAN angepriesen werden. Schau mal auf der Fritzbox unter: Heimnetz/Heimnetzübersicht/Netzwerkeinstellungen/IPv6-Adressen Eventuell ist zuvor auf der Fritzbox die „Expertenansicht“ zu aktivieren (links unten Ansicht:Standard umschalten auf Ansicht:erweitert).
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Hallo Ja, das hat funktioniert. Danke. Aber es hat mir auch deutlich gemacht, dass man ULAs eigentlich nicht braucht. So sagt meine Fritzbox in der aktivierten Option:
[J] Unique Local Addresses (ULA) zuweisen, solange keine IPv6-Internetverbindung besteht (empfohlen)
Das heisst, der Router machts automatisch, wenn beispielsweise jemand das DSL-Kabel abzieht. Aber interessant dabei ist der Hinweis "(empfohlen)" ... woraus ich schließe, dass das nur ne Notfall-Option ist, aber im Regelbetrieb nicht benötigt wird. Als Resumee bleibt, ich muss eigentlich gar nix machen und kann die ULAs erstmal unberücksichtigt lassen. Eigentlich wird das eigene Netz jetzt durch den ISP-Prefix bestimmt... *hmmm*... ich weiss aber nicht, ob mich das stören müsste ... und mangels Sachkenntnis tuts das erst mal auch nicht... *lol*
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
TomLu schrieb: Eigentlich wird das eigene Netz jetzt durch den ISP-Prefix bestimmt... *hmmm*... ich weiss aber nicht, ob mich das stören müsste ... und mangels Sachkenntnis tuts das erst mal auch nicht... *lol*
Schau mal mit:
host dns.fritz.box
nach, ob deine FritzBox eine ULA als IPv6-DNS-Server, zur Verfügung stellt. Wenn ja, dann starte auf deinem IPv6-Client (der keine ULA hat):
sudo tcpdump -c 10 -vvveni <Interface> ether proto 0x86dd and port 53
und mache auf deinem Client eine Namensauflösung mit dem IPv6-DNS-Server/ULA der FritzBox:
host -t AAAA heise.de <IPv6-DNS-Server-FritzBox/ULA>
Was zeigt tcpdump, bzgl. Verbindung Client-FritzBox, an?
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Moin Meine Fritzbox bietet keine egiene ULA als DNS an, sondern (via RA) nur die vom ISP zugewiesenen - aber sie ist über ULA ereichbar. lubux Was zeigt tcpdump, bzgl. Verbindung Client-FritzBox, an?
Zwei Pakete: 1. von meiner GUA > zur Fritzbox-ULA 2. von der Fritzbox-ULA > zu meiner GUA Was sagt mir das jetzt...?... vor dem Hintergrund, dass mein PC beim Test keine ULA zugewiesen hatte.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
TomLu schrieb: ..., sondern (via RA) nur die vom ISP zugewiesenen - ...
Sind das IPv6-DNS-Server, die via RA von deiner FritzBox angeboten werden? TomLu schrieb: 1. von meiner GUA > zur Fritzbox-ULA 2. von der Fritzbox-ULA > zu meiner GUA Was sagt mir das jetzt...?... vor dem Hintergrund, dass mein PC beim Test keine ULA zugewiesen hatte.
Na, dass dein PC via GUA mit ULAs kommunizieren kann.
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
lubux schrieb: TomLu schrieb: ..., sondern (via RA) nur die vom ISP zugewiesenen - ...
Sind das IPv6-DNS-Server, die via RA von deiner FritzBox angeboten werden?
Ja, zwei IPv6 DNS, aber auch 2 IPv4 DNS... ich habe ja derzeit nen Dualstack. Wobei aber immer die IPv6 die primär verwendeten DNS sind. Ebenso ist meine Temp-GUA immer die primäre für neue Verbindungen ins Internet.
Na, dass dein PC via GUA mit ULAs kommunizieren kann.
War das denn zweifelhaft? Was anderes hätte ich mir eigentlich gar nicht vorstellen können, weil ich davon ausgehe, dass die Fritzbox intern (!) das via Route, Forwarding und vielleicht auch über DNAT (o.s.ä) sauber handhabt. Also, die ULA generiert sich die FB gemäß meinem vorgegebenen Prefix und mit ihrer MAC selber, teilt sie aber gemäß Einstellung nicht über das RA den Clients mit... und sie ist trotzdem darüber erreichbar. Aber die Frage bleibt immer noch: Für den Normalbetrieb mit vorhandener GUA ist eine ULA auf den Clients meiner jetzigen Meinung nach eigentlich unnötig. Merken kann ich mir beide nicht mehr, also nutze ich sowieso nur noch die Hostnamen. Und wenn bei Nichtverfügbarkeit eines ISP-Prefix alternativ der ULA-Prefix via RA verteilt und sich die Clients damit eine ULA erzeugen, scheint mir das für die LAN-Funktionalität auch ausreichend zu sein. Aber beides gleichzeitig ist doch eigentlich nicht notwendig. Wie siehst Du das? BTW, ich habe mal alle GUAs deleted und nur eine gültige ULA eingerichtet. Ich bin damit nichts ins WEB gekommen, obwohl ich das Gateway mit der richtigen ULA der FB benannt habe. Der Prefix war natürlich auch übereinstimmend. Ist das normal oder hätte das eigentlich gehen müssen?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
TomLu schrieb: Also, die ULA generiert sich die FB gemäß meinem vorgegebenen Prefix und mit ihrer MAC selber, teilt sie aber gemäß Einstellung nicht über das RA den Clients mit... und sie ist trotzdem darüber erreichbar.
Bei meiner FritzBox wird die ULA, den Clients per RA (als IPv6-DNS-Server) mitgeteilt und diese ULA der FritzBox ist auch im ipv6-arp-cache der Clients zu finden:
rdnss option (25), length 24 (3): lifetime 1200s, addr: fd00::####:#ff:fe##:####
:~ $ host heise.de fritz.box
Using domain server:
Name: fritz.box
Address: fd00::####:#ff:fe##:#####53
Aliases:
heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 10 relay.heise.de.
fd00::####:#ff:fe##:#### dev wlan0 lladdr ##:##:##:##:##:## router DELAY TomLu schrieb: Aber die Frage bleibt immer noch: Für den Normalbetrieb mit vorhandener GUA ist eine ULA auf den Clients meiner jetzigen Meinung nach eigentlich unnötig.
Ich benutze die GUAs der Clients in ip6tables, für diverse Einschränkungen aus dem Internet. Deshalb nutze ich intern auch ULAs. TomLu schrieb: Ist das normal oder hätte das eigentlich gehen müssen?
Ich denke, das ist normal. Schau mal mit z. B.:
ip -6 r
nach, ob dein IPv6-Client in so einem Fall, (noch) eine ipv6-default-route hat.
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
lubux schrieb: Bei meiner FritzBox wird die ULA, den Clients per RA (als IPv6-DNS-Server) mitgeteilt und diese ULA der FritzBox ist auch im ipv6-arp-cache der Clients zu finden:
Ja, ist bei mir genau so... ich habe das mal ausprobiert. Und anschließend hab ichs erst mal wieder disabled. Das heisst, jetzt ist der ULA-Prefix nicht mehr im RA enthalten und der Client generiert sich jetzt auch keine ULA mehr.
Ich benutze die GUAs der Clients in ip6tables, für diverse Einschränkungen aus dem Internet. Deshalb nutze ich intern auch ULAs.
Das ist bei mir eigentlich genauso. Ich händel in meinen IPv6-Paketfilter ebenfalls für die GUA genau die Ports, die ich für den Zugriff von außen benötige und darüber hinaus einige spezielle Dienste, die ich in Ergänzung zu den eigenen Einstellungen der Dienste hier auch konkret betrachte. Das ist zwar der Hosenträger zusätzlich zum Gürtel... aber manchmal sind mir einzelne Einstellungen bei den Dienst nicht ganz klar oder ich bin über deren Wirksamkeit misstrauisch, also nehme ich die Sense "iptables" um ganz sicher zu sein. Aber ich hatte bisher noch keine Einschränkungen, die die ULAs notwendig gemacht hätten. Aber dazu passt meine Frage unten......
nach, ob dein IPv6-Client in so einem Fall, (noch) eine ipv6-default-route hat.
Nee, hat er nicht, nur auf die LLA des Routers. Aber was mir heute nachmittag eingefallen ist und was ich Dich noch fragen wollte.... welche IPv6 ist denn im LAN die primär verwendete? Zum Beipiel innhalb des LANs bei SSH- oder VNC-Verbindungen... welche IPv6 nimmt das System, wenn mein PC und der Zielrechner beide eine ULA und eine GUA haben.... vor dem Hintergrund, dass für Connects ins Internet die temporäre GUA gemäß der PE verwendet wird. Weisst Du das so oder muss ich das morgen selber mal testen?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
TomLu schrieb: .... welche IPv6 ist denn im LAN die primär verwendete? Zum Beipiel innhalb des LANs bei SSH- oder VNC-Verbindungen... welche IPv6 nimmt das System, wenn mein PC und der Zielrechner beide eine ULA und eine GUA haben.... vor dem Hintergrund, dass für Connects ins Internet die temporäre GUA gemäß der PE verwendet wird.
Für Verbindungen im (W)LAN wird die ULA verwendet und für Verbindungen ins Internet, wird die GUA verwendet.
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
lubux schrieb: TomLu schrieb: .... welche IPv6 ist denn im LAN die primär verwendete? Zum Beipiel innhalb des LANs bei SSH- oder VNC-Verbindungen... welche IPv6 nimmt das System, wenn mein PC und der Zielrechner beide eine ULA und eine GUA haben.... vor dem Hintergrund, dass für Connects ins Internet die temporäre GUA gemäß der PE verwendet wird.
Für Verbindungen im (W)LAN wird die ULA verwendet und für Verbindungen ins Internet, wird die GUA verwendet.
Mein erster Gedanke war "Klasse, das lässt sich ja dann noch besser einstellen". Aber dann, beim Test, folgte die Ernüchterung. Bei mir ist das nicht so, es wird auch für LAN-interne Verbindungen zumeist die GUA und machmal die IPv4 genommen. Ich habe das Router-RA geändert und sichergestellt, dass jetzt auch immer der LAN-Prefix gesendet wird. Alle Clients generieren jetzt via SLAAC jeweils zwei GUAs und zwei ULAs, jeweils eine als tempaddr und hwdaddr, also vier IPv6. Im systemd-resolved habe ich beide IPv{4+6} des Routers/Gateway hinterlegt. Und dennoch werden alle Verbindungen mit der IPv6 des ISP hergestellt. Ich habe auf dem Zielrechner tcpdump mit wechselnden Ports laufen lassen, z.B. 139 und 65000. Bei 139 habe ich auf meinem PC einfach einen Mount (der auf dem anderen PC gar nicht existiert) gestartet. Ich sehe den Traffic auf Port 139, aber es ist immer die ISP-IP (GUA) meines PC als "Anforderer". Das gleiche, wenn ich ssh -p 65000 versuche... auf dem Zielrechner wieder die GUA meines PC. Und jetzt beim letzten Test sehe ich sogar die IPv4, also wurde gar keine IPv6 verwendet. Dann, wenn ich die IPv4 entferne, DHCP4 deaktiviere, systemd-networkd/resolved korrekt auf IPv6 einstelle und neu starte, habe ich überhaupt keine Verbindung mehr, weder ins LAN noch ins Internet - trotz gültiger GUA und ULA. *hmmmm* Im Moment entzieht sich das so ein wenig meiner Kontrolle und auch dem Verstehen.... kann das vielleicht mit dem Dualstack zuammenhängen, dass also beides noch lebt - IPv4 und IPv6?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
TomLu schrieb: Alle Clients generieren jetzt via SLAAC jeweils zwei GUAs und zwei ULAs, jeweils eine als tempaddr und hwdaddr, also vier IPv6.
Evtl. kann das auch Probleme verursachen. TomLu schrieb: .... kann das vielleicht mit dem Dualstack zuammenhängen, dass also beides noch lebt - IPv4 und IPv6?
Versuch mal mit einem ssh, das nur für IPv6 konfiguriert ist. Z. B.:
AddressFamily inet6 # (use IPv6 only)
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Das ist im Moment faszinierend... aber für mich unheimlich schwer, da jetzt die richtigen Schlüsse zu ziehen. Der Durchbruch im Verhalten war die "/etc/hosts" .... die mir erst vorhin bei meiner Gassirunde wieder in den Sinn gekommen ist. Und siehe da, der Test-Zielrechner war natürlich direkt (aus früheren Versuchen) mit seiner IPv4 benannt. Vermutlich hatte das den Einfluss auf die bevorzugte Verwendung der IPv4, wenn ich nicht explizit IPv6 vorgegeben habe. Nachdem ich das entfernt habe und zudem zwei IPv6-Einträge hinzugefügt habe (sind die so richtig?):
127.0.0.1 localhost.localdomain thomaspc
::1 ip6-localhost ip6-loopback thomaspc
fe00::0 ip6-localnet
...war das Verhalten völlig anders. Der Connect "ssh testraspi -p 65000" wurden auf dem raspi wie folgt ge'tcpdump't:
temp-GUA → hwaddr-GUA temp-ULA → temp-ULA temp-GUA → temp-GUA temp-ULA → hwaddr-ULA IPv4 → IPv4
Der Connect-Versuch hat also alle Möglichkeiten durchgespielt... natürlich erfolglos, weil kein Dienst gelauscht hat. Aber interessant ist die Reihenfolge, wie er das versucht hat.... angefangen mit der temp-GUA und nicht mit der LAN-internen ULA *hmmmm*. Vor dem Hintergrund komme ich wieder auf den Eingangsgedanken zurück und frage mich, ob die ULA bei aktiver GUA überhaupt einen Sinn ergibt, zumal ich das anscheinend sowieso nicht beeinflussen kann, welche IP ein Programm verwendet und ob es sich an die Regeln gemäß RFC-Doku hält.
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Hi lubux lubux schrieb: TomLu schrieb: Aber die Frage bleibt immer noch: Für den Normalbetrieb mit vorhandener GUA ist eine ULA auf den Clients meiner jetzigen Meinung nach eigentlich unnötig.
Ich benutze die GUAs der Clients in ip6tables, für diverse Einschränkungen aus dem Internet. Deshalb nutze ich intern auch ULAs.
Ich hoffe, ich kann Dich noch mal zu nem Statement verleiten, gerade auch zu Deiner vorherigen Aussage hinsichtlich ip6tables.... denn ich komme nach sehr viel Lesen jetzt zu einem anderen Fazit. Meiner Meinung nach sind ULAs 'für uns' unnötig.... deshalb habe ich sie erst mal wieder deaktiviert. Im folgenden versuche ich das zu erklären und hoffe, Du (oder gerne auch jemand anderes) bewertest das vielleicht einmal. Man kann sich ja immer auch täuschen und einer falschen Fährte gefolgt sein. Also... ...hier die markanten Punkte, die zu meinem Fazit geführt haben:
Mit den ULA und die GUA wird immer jeweils eine Site-ID/64 repräsentiert, einmal fd00::/8, einmal 2000::/3 für die IANA-IPs. Beide haben das Merkmal "global scope", was aber nur bedeutet, dass sie beide weltweit einmalig sein möchten.... worauf es allerdings bei der ULA keine Garantie gibt, sondern nur eine gewisse Wahrscheinlichkeit. Einen Unterschied hinsichtlich der Funktion innerhalb des LANs gibt es nicht - es sind hier beides einfach nur Site-IDs.
Hinsichtlich des LAN-internen Routings besteht zwischen GUA und ULA keinerlei Unterschied, solange keine explizite Subnet-Trennung bezüglich besonderen Client-Groups/Ranges eingerichtet ist, also sowas wie ein Intranet. Soll heissen, solange in einer Firma oder Privat nicht zwei oder mehr Netzwerke tatsächlich getrennt werden müssen, hat man mit ULA und GUA einfach nur 2 Site-IDs fürs gleiche Netz. Für mich ist das i.ü.S. analog zum Klingelschild "Ursula und Gustav" an der Wohnungstür... zwei Namen, eine Wohnung, die gleichen Räume.
Die GUA wird ebenso wie früher die IPv4 ins Internet geroutet, wenn kein lokaler Empfänger gefunden wird.Insofern besteht auch hier kein vordergründig ersichtlicher Unterschied zwischen GUA und frühererIPv4. Die ULA wird hingegen nicht ins WWW geroutet, ähnlich eines gekapselten IP4-Netzes ohne Gateway. Aber wer braucht das so in einem typischen Klein-Netz?
Ein typisches privates Netzwerk mit seinen dazugehörigen Clients hat ihmo keine Vorteile mit 2 Site-IDs, da im Regelfall beide Site-IDs auf den Interfaces bekannt sind und deswegen alle Clients sowieso immer untereinander erreichbar sind, entweder über die eine oder die andere Site-ID.
Die zusätzliche Verwendung von ULAs neben den obligatorischen GUAs in einem typischen privaten Netzwerk, in dem alle LAN-Clients einschließlich des Servers (z.B. f. dist-upgrade, Remote-Access) immer auch Internet-User sind (durch ISP-Site-ID), bringt faktisch keinerlei Sicherheitsgewinn.
Der folgende Artikel hat auch zu meinem Fazit beigetragen.Ich empfand den als sehr interessant und lesenswert. http://www.comconsult-research.de/ipv6-adresse-qual/ vg, Thomas
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
TomLu schrieb: ..., zumal ich das anscheinend sowieso nicht beeinflussen kann, welche IP ein Programm verwendet und ob es sich an die Regeln gemäß RFC-Doku hält.
Dann hast Du dich noch nicht richtig, mit der Konfiguration von sshd/ssh beschäftigt. In der sshd_config (Server) kannst Du festlegen, auf welcher IP-Adresse/Port der sshd lauscht bzw. von welcher IP-Adresse der user sich verbinden darf:
ListenAddress <IP-Adresse-Server>:<Port-Server>
AllowUsers <user>@<IP-Adresse-ssh-Client> Auf dem ssh-Client kannst Du z. B. konfigurieren:
Host <hostname>
HostName <IP-Adresse-sshd-Server>
BindAddress <IP-Adresse-ssh-Client>
CheckHostIP yes
Port <lauschender-Port-sshd-Server>
|