Het grote IPv6 topic

[Roetzen]

L0g0ff schreef op donderdag 30 december 2021 @ 07:31:

Nu is mijn ipv4 adres bij ziggo de afgelopen 5 jaar naar 1x veranderd. En ik ga toch wel vanuit dat dit ook zo zit met ipv6.

Mijn ervaring met de (Arris) Connectbox in router mode is dat de IPv6 prefix vaker wijzigt dan eens in de vijf jaar. Het zou in bridge mode anders kunnen zijn, daar heb ik nog geen ervaring mee.

[Brahiewahiewa]

Roetzen schreef op donderdag 30 december 2021 @ 14:52:
[...]

Mijn ervaring met de (Arris) Connectbox in router mode is dat de IPv6 prefix vaker wijzigt dan eens in de vijf jaar. Het zou in bridge mode anders kunnen zijn, daar heb ik nog geen ervaring mee.

Bij de invoering destijds - zo'n 2½ jaar geleden - is m'n prefix 3 keer gewijzigd. Sindsdien al 2 jaar stabiel

[kroonen]

Hoi,

Ik heb een edgerouter x heb ipv6 nu goed werkend erop en mijn clients op de verschillen vlans krijgen ook netjes ipv6 adressen.

Nu wil ik alleen de dns zelf bepalen, en heb ik op de interface al --no-dns staan (eth4 is mijn koppeling naar ziggo, switch0.10 is vlan 10))

set interfaces ethernet eth4 dhcpv6-pd pd 1 interface switch0 no-dns
set interfaces ethernet eth4 dhcpv6-pd pd 1 interface switch0.10 no-dns

Nu krijg ik nog steeds ipv6 dns , dus iets gaat niet goed, en de vraag is hoe ik kan zorgen dat ik ook mijn pihole als dns weer kan zetten.

is dit met dit of is meer nodig?

set interfaces switch switch0 ipv6 router-advert name-server fe80 enz?
set interfaces switch switch0.10 ipv6 router-advert name-server fe80 enz?
set interfaces switch switch0.10 ipv6 router-advert send-advert true
set interfaces switch switch0 ipv6 router-advert send-advert true

[Roetzen]

Brahiewahiewa schreef op donderdag 30 december 2021 @ 18:06:
[...]

Bij de invoering destijds - zo'n 2½ jaar geleden - is m'n prefix 3 keer gewijzigd. Sindsdien al 2 jaar stabiel

Invoering van wat? Ipv6? Ik heb al native IPv6 van Ziggo sinds 2016. (fZiggo gebied)

Sinds maart 2019 heb ik een Arris Connectbox. Sindsdien is mijn IPv6 prefix 15 keer gewijzigd. Voor het laatst op 1 december j.l. na een firmware update.

[Brahiewahiewa]

Roetzen schreef op donderdag 30 december 2021 @ 23:22:
[...]

Invoering van wat? Ipv6? Ik heb al native IPv6 van Ziggo sinds 2016. (fZiggo gebied)

Sinds maart 2019 heb ik een Arris Connectbox. Sindsdien is mijn IPv6 prefix 15 keer gewijzigd. Voor het laatst op 1 december j.l. na een firmware update.

Invoering van ipv6 bij mij thuis ;o)
In mijn beleving was dat zo'n tweeëneenhalf jaar geleden, maar ik kan me vergissen. Als het je ècht interesseert kun je in dit topic terugzoeken; ik heb toen wat feedback geplaatst hier.

Maar mijn Compal is na die eerste hick-ups dus stabiel vwb z'n prefix (fCasema)

[Roetzen]

Brahiewahiewa schreef op vrijdag 31 december 2021 @ 00:12:
[...]
Maar mijn Compal is na die eerste hick-ups dus stabiel vwb z'n prefix

Opmerkelijk. Zou het een specifiek verschil tussen de Compal en de Arris zijn? Verschil in fZiggo vs fUPC is het dus niet want we zitten allebei in fCasema.

[ Voor 10% gewijzigd door Roetzen op 31-12-2021 00:22 ]

[Brahiewahiewa]

Roetzen schreef op vrijdag 31 december 2021 @ 00:20:
[...]

Opmerkelijk. Zou het een specifiek verschil tussen de Compal en de Arris zijn of is het fZiggo vs fUPC

offtopic:
Euh fCasema is nadrukkelijk niet fUPC; je gaat een Rotterdammer niet vertellen dat-ie in Amsterdam woont ;o)

[Roetzen]

Brahiewahiewa schreef op vrijdag 31 december 2021 @ 00:23:
[...]

offtopic:
Euh fCasema is nadrukkelijk niet fUPC; je gaat een Rotterdammer niet vertellen dat-ie in Amsterdam woont ;o)

Ja, even gemist. Zie edit.

[L0g0ff]

kroonen schreef op donderdag 30 december 2021 @ 21:59:
Hoi,

Ik heb een edgerouter x heb ipv6 nu goed werkend erop en mijn clients op de verschillen vlans krijgen ook netjes ipv6 adressen.

Nu wil ik alleen de dns zelf bepalen, en heb ik op de interface al --no-dns staan (eth4 is mijn koppeling naar ziggo, switch0.10 is vlan 10))

set interfaces ethernet eth4 dhcpv6-pd pd 1 interface switch0 no-dns
set interfaces ethernet eth4 dhcpv6-pd pd 1 interface switch0.10 no-dns

Nu krijg ik nog steeds ipv6 dns , dus iets gaat niet goed, en de vraag is hoe ik kan zorgen dat ik ook mijn pihole als dns weer kan zetten.

is dit met dit of is meer nodig?

set interfaces switch switch0 ipv6 router-advert name-server fe80 enz?
set interfaces switch switch0.10 ipv6 router-advert name-server fe80 enz?
set interfaces switch switch0.10 ipv6 router-advert send-advert true
set interfaces switch switch0 ipv6 router-advert send-advert true

Ik ken Edgerouter x verder niet. Wat ik wel weet is dat SLAAC bij mij default een dns uitdeelde. Dit was het publieke ipv6 (2001:) adres van mijn eigen router.

Op mijn router stond vervolgens een dns forwarder ingesteld naar mijn pi.hole.

Voor pi.hole is dit niet handig want hierdoor komen alle dns requests van mijn router terwijl ik wil kunnen zien van welk device een request komt.

Ik heb toen dhcpv6 ingesteld met de volgende optie:

code:

dhcp-option=option6:dns-server,[2001:xxxxxxx]

De SLAAC dns heb ik daarna uitgezet.

Al mijn ipv6 devices krijgen nu netjes het ipadres van mijn pihole uitgedeeld.

[ Voor 4% gewijzigd door L0g0ff op 31-12-2021 07:13 ]

[babbelbox]

Hier meldt zicht nog een IPv6 newbie.
Ik heb sinds deze maand ook via Ziggo en bridge-mode modem de mogelijkheid tot het gebruiken van IPv6.
Als eigen router heb ik er een Mikrotik (RB4011 for that matter) achter voor de routing en firewalling.
Op IPv4 werkt alles as-intended.
Maar voor IPv6 ben ik nog een beetje aan het zoeken en speuren.
Als ik op m'n MikroTik DHCPv6 aanslinger krijg ik IPv6 address toegewezen op m'n WAN interface (ether1 in mijn geval) en ook ontvang ik een /56 prefix als pool die ik kan gebruiken op m'n interne config.
Als ik dan vanuit m'n ontvangen prefix en pool een IPv6 address op m'n local-bridge zetten, zie ik ook dat er diverse devices op m'n interne netwerk ook een IPv6 address vastleggen in dezelfde range. So far so good.
Nu dus de strubbelingen, ik heb op m'n MikroTik router nog een 3 tal aanvullende bridges en gebruikmakend van VLAN's dus wat scheiding aangebracht. Maar hoe kan ik er nu voor zorgen dat deze extra bridges ook een IPv6 address krijgen, gebruikmakend van de door ziggo aangeleverde prefix, maar dus met elk een eigen /64 subnet.
Ik merk dat wanneer ik ::1/64 als gewenst IP aangeef en gebruik maak van de aangeleverde pool dat er weldegelijk dedicated segmenten worden gemaakt 2001:xxxx:xxxx:xx00::1/64 wodt dus als eerste gebruikt. Aanvullende bridges krijgen vervolgens 2001:xxxx:xxxx:xx01::1/64 en dan 2001:xxxx:xxxx:xx02::1/64.
Maar ik heb helemaal geen invloed op deze volgorde en nummering. Ik zou graag zelf willen bepalen welk /64 segment uit de beschikbare /56 waar wordt gebruikt.

[Brahiewahiewa]

L0g0ff schreef op vrijdag 31 december 2021 @ 07:05:
[...]


Ik ken Edgerouter x verder niet. Wat ik wel weet is dat SLAAC bij mij default een dns uitdeelde. Dit was het publieke ipv6 (2001:) adres van mijn eigen router.

Op mijn router stond vervolgens een dns forwarder ingesteld naar mijn pi.hole.

Voor pi.hole is dit niet handig want hierdoor komen alle dns requests van mijn router terwijl ik wil kunnen zien van welk device een request komt.

Ik heb toen dhcpv6 ingesteld met de volgende optie:

code:

dhcp-option=option6:dns-server,[2001:xxxxxxx]

De SLAAC dns heb ik daarna uitgezet.

Al mijn ipv6 devices krijgen nu netjes het ipadres van mijn pihole uitgedeeld.

Het is mij niet helemaal duidelijk wat je nu gedaan hebt. Het lijkt er op dat je nu èn SLAAC draait èn DHCPv6. Dat wordt inderdaad geacht te werken; zie https://datatracker.ietf.org/doc/html/rfc8106
Maar het is voor jou dubbel werk.

Andere optie zou zijn om jouw router er van te overtuigen om niet z'n eigen adres als DNS server te broadcasten maar het ip-adres van de pi-hole. Maar ik ken jouw router niet dus ik weet niet of zijn UI dat toelaat.

Als jouw router alleen de keuze heeft om z'n eigen DNS server wel of niet te broadcasten, kun je op de pi-hole een RAD gaan draaien die enkel DNS announcements doet

[nescafe]

@babbelbox je hebt helaas geen invloed op de toegewezen adressen, het liefst zou je de functie IPv6 > Pool > Used prefixes static willen kunnen maken zoals dat bij DHCPv6 Server Bindings wel kan.

Zodra je meer dan 1 IPv6 address "From Pool" toewijst gaat de router inderdaad erg vervelend doen - bij iedere configuratiewijziging bijv. de prefixes ophogen. Ik heb hier al een support request voor ingediend ("Allow IPv6 prefix hint").

Vooralsnog moet je dus om kunnen (of willen) gaan met zeer dynamische prefixen - zet dan in ieder geval je prefix lifetime een stuk lager (IPv6 > ND > Prefixes > Default). Of stel je IPv6-adressen static in zonder from-pool.

[babbelbox]

@nescafe Ok er zijn dus nogal wat strubbels als je niet al te veel statisch wilt, maar toch ook niet zeker bent van statische toewijzing vanuit de ISP.
Volgende vraag. Hoe verkrijg ik 'normale' hostname(s) voor interne diensten die ik heb.
Ik draai diverse zaken op een raspberry incl Traefik. Ook heb ik een domain name beschikbaar waarbij ik bij m'n provider voor *.home.<domain>.com een A-record heb gemaakt naar m'n publieke IPv4 adres.
Hoe ga ik dat met IPv6 regelen?

[vanaalten]

Het zal ongetwijfeld kunnen, maar ik zie door de bomen het bos nog niet:
- Ziggo modem in bridge mode
- Unifi USG-3P router
- Debian 'stable' servertje in de meterkast

IPv6 werkt op zich prima, MAAR ik zou liefst het IP adres van de server deels vast willen hebben: de prefix en subnet ID van de router ontvangen, maar het stuk interface identifier NIET gebaseerd op het MAC adres maar zelf bepaald.

Reden: ik heb nog niet het vertrouwen in Ziggo dat het prefix-deel echt vast is (plus dat ik t.z.t. wel eens van provider zal veranderen), maar ik wil ook niet dat het IPv6 adres wisselt als ik hardware verander.

Ik heb met Google wel wat gezocht en kwam o.a. op https://wiki.gentoo.org/w...ic_Addresses_using_Tokens uit, maar ik vraag mij af of dit de handigste manier is, of dat het tegenwoordig wellicht simpel in /etc/network/interfaces kan. Iemand hier ervaring mee?

[nescafe]

@babbelbox ik begrijp je vraag niet helemaal.. en vermoedelijk heb je nog niet gegoogled naar iets als IPv6 DNS entry? Waar kom je precies niet uit?

[L0g0ff]

Brahiewahiewa schreef op vrijdag 31 december 2021 @ 10:48:
[...]

Het is mij niet helemaal duidelijk wat je nu gedaan hebt. Het lijkt er op dat je nu èn SLAAC draait èn DHCPv6. Dat wordt inderdaad geacht te werken; zie https://datatracker.ietf.org/doc/html/rfc8106
Maar het is voor jou dubbel werk.

Andere optie zou zijn om jouw router er van te overtuigen om niet z'n eigen adres als DNS server te broadcasten maar het ip-adres van de pi-hole. Maar ik ken jouw router niet dus ik weet niet of zijn UI dat toelaat.

Als jouw router alleen de keuze heeft om z'n eigen DNS server wel of niet te broadcasten, kun je op de pi-hole een RAD gaan draaien die enkel DNS announcements doet

Ik heb beide aan staan omdat ik begreep dat niet alle devices dhcpv6 accepteren. Maar SLAAC zou ik eventueel ook uit kunnen zetten.

Ik zal eens kijken hoe dat RAD precies werkt. Ik heb pihole wel in docker draaien dus even kijken of dat zonder 3th party modules gaat werken.

Tnx voor je feedback

[Brahiewahiewa]

vanaalten schreef op vrijdag 31 december 2021 @ 12:59:
... het IP adres van de server ...

Hier gaat het al fout: er is geen sprake van "het ip adres van een server". Een server kan achteloos 1000-en ip adressen hebben. Jij hebt de beschikking over een address space ter grootte van het huidige ip4 internet. Vier miljard adressen. Je server is er klaar voor om desnoods alle 4 miljard te gebruiken; nu jij nog ;o)

[RobertMe]

L0g0ff schreef op vrijdag 31 december 2021 @ 13:14:
Ik heb pihole wel in docker draaien dus even kijken of dat zonder 3th party modules gaat werken.

Docker en IPv6 bedoel je dan? Best worse case thing dat ik laatst zelf op een VPS heb gedaan was de Docker containers in een private IPv6 range plaatsen en Docker DNAT laten toepassen op IPv6, hetzelfde als dat voor IPv4 standaard wordt gedaan. Maar dat is dus NATen en voelt nasty. En het IPv6 NAT verhaal zit tegenwoordig in Docker ingebakken, daar waar veel voorbeelden tot nog toe verwijzen naar een 3th party Docker container om dat te regelen.

Maar hoe ik het thuis ga aanpakken met Pi-Hole in Docker ben ik ook nog niet over uit. Of ik ook daarbij voor DNAT ga, of ik de container met macvlan rechtstreeks aan het netwerk hang, of iets anders.
Iets anders zou dan neerkomen op ook weer in Docker een IPv6 netwerk maken, maar dat binnen het netwerk ook routeerbaar maken met het host OS als route er naartoe. Of wat volgens mij ook kan is een Docker netwerk maken met een kleiner subnet dan de host heeft, en vervolgens "ARP van IPv6" laten proxien door het host OS.

Voor mij als "netwerk hobbiest / prutser" (ben programmeuvan beroep) lastig om daar de juiste oplossing in te vinden dus.

[Accretion]

Is het zo dat mensen op IPv4 niet kunnen verbinden met een server op IPv6?

[Keiichi]

Accretion schreef op vrijdag 31 december 2021 @ 15:16:
Is het zo dat mensen op IPv4 niet kunnen verbinden met een server op IPv6?

Zonder verdere context, dat klopt

Wat de praktijk is dat servers die ipv6 hebben, ook nog ipv4 hebben waarop wel verbonden kan worden.

[nero355]

RobertMe schreef op vrijdag 31 december 2021 @ 14:21:
Maar hoe ik het thuis ga aanpakken met Pi-Hole in Docker ben ik ook nog niet over uit.

Of ik ook daarbij voor DNAT ga, of ik de container met macvlan rechtstreeks aan het netwerk hang, of iets anders.

MACVLAN is gewoon de enige juiste optie voor Pi-Hole in een Docker Container en wordt zo'n beetje door iedereen die Docker gebruikt toegepast in het Pi-Hole Topic

[L0g0ff]

RobertMe schreef op vrijdag 31 december 2021 @ 14:21:
[...]

Docker en IPv6 bedoel je dan? Best worse case thing dat ik laatst zelf op een VPS heb gedaan was de Docker containers in een private IPv6 range plaatsen en Docker DNAT laten toepassen op IPv6, hetzelfde als dat voor IPv4 standaard wordt gedaan. Maar dat is dus NATen en voelt nasty. En het IPv6 NAT verhaal zit tegenwoordig in Docker ingebakken, daar waar veel voorbeelden tot nog toe verwijzen naar een 3th party Docker container om dat te regelen.

Maar hoe ik het thuis ga aanpakken met Pi-Hole in Docker ben ik ook nog niet over uit. Of ik ook daarbij voor DNAT ga, of ik de container met macvlan rechtstreeks aan het netwerk hang, of iets anders.
Iets anders zou dan neerkomen op ook weer in Docker een IPv6 netwerk maken, maar dat binnen het netwerk ook routeerbaar maken met het host OS als route er naartoe. Of wat volgens mij ook kan is een Docker netwerk maken met een kleiner subnet dan de host heeft, en vervolgens "ARP van IPv6" laten proxien door het host OS.

Voor mij als "netwerk hobbiest / prutser" (ben programmeuvan beroep) lastig om daar de juiste oplossing in te vinden dus.

Ik heb docker rechtsreeks op poort 53 en 8080 van de host draaien. En die host is een synology.

Die host heeft naast een ipv4 adres ook een ipv6 adres gekregen. En idd dit is natten en verdient misschien niet de schoonheidsprijs. Maar het werkt dikke prima

Ik had docker een paar maanden terug op met zijn eigen virtuele netwerk interface rechtstreeks in mijn netwerk hangen. En op een avond deed ik een update en brak heel de boel. Nu is het gewoon een plate config zonder poespas. En 1 ding weet ik zeker... Het blijft zo altijd werken

[Accretion]

Keiichi schreef op vrijdag 31 december 2021 @ 15:26:
[...]


Zonder verdere context, dat klopt

Wat de praktijk is dat servers die ipv6 hebben, ook nog ipv4 hebben waarop wel verbonden kan worden.

Ja, de provider probeert mij richting IPv6 te drukken, maar uit jou reactie komt eigenlijk dat ik IPv4 moet hebben?

(Als ik mijn eigen server host en IPv4 toe wil laten?)

[ Voor 7% gewijzigd door Accretion op 01-01-2022 00:39 ]

[nero355]

L0g0ff schreef op vrijdag 31 december 2021 @ 17:52:
Ik heb docker rechtsreeks op poort 53 en 8080 van de host draaien. En die host is een synology.

Wablief

/EDIT :

@L0g0ff Gewoon Pi-Hole in een Docker Image dus... NICE!

[ Voor 15% gewijzigd door nero355 op 01-01-2022 17:01 ]

[L0g0ff]

nero355 schreef op zaterdag 1 januari 2022 @ 16:40:
[...]

Wablief

Duidelijker dan dit artikel kan ik het niet uitleggen

https://mariushosting.com...ole-on-your-synology-nas/

code:

docker run -d --name=pihole \
-e WEB_PORT=8080 \
-e WEBPASSWORD=yourpassword \
-e ServerIP=IPSynology \
-e DNSMASQ_LISTENING=local \
-v /volume1/docker/pihole/dnsmasq.d:/etc/dnsmasq.d \
-v /volume1/docker/pihole/pihole:/etc/pihole \
--net=host \
--restart always \
pihole/pihole

Ik heb in de docker config een extra ipv6 regel gezet. Die mapt gewoon beide host ip's naar mijn docker container toe. Feitelijk gezien luisteren en r gewoon 2 tcp/udp poorten op mijn synology.

Ik hoop dat het een beetje duidelijk is

[ Voor 17% gewijzigd door L0g0ff op 01-01-2022 16:51 ]

[CAPSLOCK2000]

Accretion schreef op zaterdag 1 januari 2022 @ 00:39:
Ja, de provider probeert mij richting IPv6 te drukken, maar uit jou reactie komt eigenlijk dat ik IPv4 moet hebben?

(Als ik mijn eigen server host en IPv4 toe wil laten?)

IPv4 en IPv6 zijn niet compatible maar kun je wel tegelijkertijd gebruiken. Als je server alleen IPv4 kan dan moeten je gebruikers ook IPv4 doen, als je server alleen IPv6 kan dan moeten je gebruikers ook IPv6 doen. De meesten kunnen echter allebij, in praktijk hoef je meestal niet te kiezen, al begint dat langzaam te veranderen.
IPv4 wordt op zich door meer mensen ondersteunt maar omdat die adressen schaars zijn moet je daar steeds meer voor betalen. IPv6 adressen zijn meestal gratis.

In praktijk wil je dus in ieder geval IPv6 want dat is toch gratis en daarmee ben je beter voorbereid op de toekomst.
Als je optimaal bereikbaar wil zijn en/of gebruikers hebt die alleen IPv4 kunnen dan betaal je ook voor een IPv4 adres.
Alleen IPv4 zou ik tegenwoordig niet meer doen want vroeg of laat zul je dan alsnog IPv6 moeten toevoegen en dat is meer werk dan het vanaf het begin gewoon meenemen.

[BushWhacker]

Qlimaxxx schreef op vrijdag 17 december 2021 @ 12:41:
[...]
Doet me denken aan Google producten. Als je iets van Google wil gebruiken, kun je het gebruik van Pihole vergeten. Local discovery van een product dat Google assistant ondersteunt doet het gewoon niet als je Google's praktijken probeert in te dammen. Ik snap best dat het product niet werkt, maar het is toch te zot voor woorden hoe ver ze hier in gaan.

Klopt. En hij weigert oook je lokale dns-instelingen te gebruiken gaat altijd naar de Google DNS-Servers.
Enige wat helpt is een DNAT-Rule, die alle requests die niet naar je pi.hole gaan (behalve die vanaf de pi.hole komen) te DNAT-ten naar je pi.hole.

[Qlimaxxx]

BushWhacker schreef op zondag 2 januari 2022 @ 11:30:
[...]

Klopt. En hij weigert oook je lokale dns-instelingen te gebruiken gaat altijd naar de Google DNS-Servers.
Enige wat helpt is een DNAT-Rule, die alle requests die niet naar je pi.hole gaan (behalve die vanaf de pi.hole komen) te DNAT-ten naar je pi.hole.

Bij het instellen van Google Assistant op mijn Sonos Move is dat niet het geval. Dan doet hij het gewoon niet als DHCP de Pihole als DNS uitdeelt. Zal wel komen doordat Google Assistant gewoon een applicatie is, ik denk dat het OS van Sonos zelf de netwerkverbinding beheert.

DNAT is wel een interessante, hoewel je natuurlijk ook gewoon enkel voor de pihole DNS-verkeer naar een specifieke public DNS-server kan toestaan in je firewall (blokkeer gewoon UDP poort 53 van andere clients en/of naar andere DNS-servers).

Maar ja, het is een kwestie van tijd voordat ze dan overstappen op DNS over HTTPS. Poort 443 blokkeren is ook niet bepaald praktisch, en met DNAT dat omleiden naar een Pihole (kan die überhaupt DoH?) breekt sowieso TLS volgens mij.

Best ironisch: een van de redenen om DNS-verkeer te encrypten is toch wel om tracking tegen te gaan, en juist die techniek wordt dan tegen je gebruikt.

[babbelbox]

nescafe schreef op vrijdag 31 december 2021 @ 12:59:
@babbelbox ik begrijp je vraag niet helemaal.. en vermoedelijk heb je nog niet gegoogled naar iets als IPv6 DNS entry? Waar kom je precies niet uit?

Klopt dat ik nog niet echt onderzoek heb gedaan naar DNS icm IPv6
Wat voor mij dus nog niet duidelijk is:
Hoe kan ik ervoor zorgen dat ik over IPv6 gebruik kan maken van bijvoorbeeld hostname hass.home.domain.tld en verbinding krijg met een home assistant docker installatie die thuis draait.
ik heb dus domain.tld geregistreerd en voor IPv4 heb ik een A record geconfigureerd bij m'n provider die naar m'n externe IPv4 huis address verwijst.
Ik heb nu ook voor home.domain.tld een AAAA record geconfigureerd, die verwijst naar m'n router, maar hoe nu verder?

[nero355]

Qlimaxxx schreef op zondag 2 januari 2022 @ 14:20:
DNAT is wel een interessante, hoewel je natuurlijk ook gewoon enkel voor de pihole DNS-verkeer naar een specifieke public DNS-server kan toestaan in je firewall (blokkeer gewoon UDP poort 53 van andere clients en/of naar andere DNS-servers).

Dat is niet altijd een optie, want sommige apparaten werken dan niet meer!

Je moet echt DNAT/SNAT toepassen om te faken dat het verkeer vanaf de 8.8.4.4 en 8.8.8.8 DNS servers komt!

Maar ja, het is een kwestie van tijd voordat ze dan overstappen op DNS over HTTPS.

Breng ze niet op ideeën joh!

Best ironisch: een van de redenen om DNS-verkeer te encrypten is toch wel om tracking tegen te gaan, en juist die techniek wordt dan tegen je gebruikt.

Ik heb nog steeds het idee dat ze dat meer voor zichzelf hebben gedaan dan voor ons... zoals het al heel vaak het geval is...

babbelbox schreef op zondag 2 januari 2022 @ 15:12:
Klopt dat ik nog niet echt onderzoek heb gedaan naar DNS icm IPv6

Dan wordt het tijd om dat te doen!

Wat voor mij dus nog niet duidelijk is:

Hoe kan ik ervoor zorgen dat ik over IPv6 gebruik kan maken van bijvoorbeeld hostname hass.home.domain.tld en verbinding krijg met een home assistant docker installatie die thuis draait.

ik heb dus domain.tld geregistreerd en voor IPv4 heb ik een A record geconfigureerd bij m'n provider die naar m'n externe IPv4 huis address verwijst.
Ik heb nu ook voor home.domain.tld een AAAA record geconfigureerd, die verwijst naar m'n router, maar hoe nu verder?

Dan ben je er toch

Eventueel nog op je Apache/NginX/LigHTTPd/Willekeurige Reverse Proxy de juiste Virtual Host opzetten of de huidige aanpassen en gaan met die banaan!

[nescafe]

babbelbox schreef op zondag 2 januari 2022 @ 15:12:
Hoe kan ik ervoor zorgen dat ik over IPv6 gebruik kan maken van bijvoorbeeld hostname hass.home.domain.tld en verbinding krijg met een home assistant docker installatie die thuis draait.
[..]
Ik heb nu ook voor home.domain.tld een AAAA record geconfigureerd, die verwijst naar m'n router, maar hoe nu verder?

Als je Home Assistant wilt kunnen benaderen via IPv6 dien je het ip-adres van de server waar Home Assistant op draait als AAAA-record op te nemen. Tevens zorg je ervoor dat je server bereikbaar is via poort 80 en 443, je moet de firewalls op zowel je server als je gateway voorzien van de nodige allow-rules.

Niet het ip-adres van de router gebruiken, want dan moet je gaan port forwarden en dat is bij IPv6 niet echt gebruikelijk.

[babbelbox]

nescafe schreef op zondag 2 januari 2022 @ 16:47:
[...]


Als je Home Assistant wilt kunnen benaderen via IPv6 dien je het ip-adres van de server waar Home Assistant op draait als AAAA-record op te nemen. Tevens zorg je ervoor dat je server bereikbaar is via poort 80 en 443, je moet de firewalls op zowel je server als je gateway voorzien van de nodige allow-rules.

Niet het ip-adres van de router gebruiken, want dan moet je gaan port forwarden en dat is bij IPv6 niet echt gebruikelijk.

Ok,dat leek me ook al het geval, moet ik alleen nog ff kijken hoe ik er voor kan zorgen dat m'n raspberry (=docker host = bron voor HA [en meer]) een goed en duidelijk IPv6 adres krijgt (en vast bij voorkeur)

[toevoeging]
Begin me nu wel af te vragen of het zinvol/handig/lastig is om zelf iets van DNS te gaan opzetten voor interne diensten.

[ Voor 7% gewijzigd door babbelbox op 02-01-2022 16:53 ]

[L0g0ff]

Ik heb dat ook een tijdje gedaan. Al het poort 53 verkeer naar buiten geblokkeerd alleen mijn pihole mocht nog naar buiten.

Op zich werkte dit wel maar ik had elke keer nadat ik iets vroeg aan Google home een seconden of 7 extra vertraging. En alleen bij mijn eerste vraag wat duidelijk liet zien dat het dns gerelateerd was.

In mijn logging zag ik gewoon dat die Google devices eerst 8.8.8.8 proberen te benaderen. En pas daarna de dns die ik uitdeelde via dhcp.

Ik heb nu die regel er weer afgehaald. Snelheid voor zorgvuldigheid zeg maar...

[BushWhacker]

vanaalten schreef op vrijdag 31 december 2021 @ 12:59:
Het zal ongetwijfeld kunnen, maar ik zie door de bomen het bos nog niet:
- Ziggo modem in bridge mode
- Unifi USG-3P router
- Debian 'stable' servertje in de meterkast

IPv6 werkt op zich prima, MAAR ik zou liefst het IP adres van de server deels vast willen hebben: de prefix en subnet ID van de router ontvangen, maar het stuk interface identifier NIET gebaseerd op het MAC adres maar zelf bepaald.

Reden: ik heb nog niet het vertrouwen in Ziggo dat het prefix-deel echt vast is (plus dat ik t.z.t. wel eens van provider zal veranderen), maar ik wil ook niet dat het IPv6 adres wisselt als ik hardware verander.

Ik heb met Google wel wat gezocht en kwam o.a. op https://wiki.gentoo.org/w...ic_Addresses_using_Tokens uit, maar ik vraag mij af of dit de handigste manier is, of dat het tegenwoordig wellicht simpel in /etc/network/interfaces kan. Iemand hier ervaring mee?

Yep. Heb ik.

Dan mag je NetworkManager installeren (let op de hoofdletters) en dhcpcd deactiveren in systemd.
En dan enable en start NetworkManager in systemd.

Afhankelijk van de naam van je connection: (31 is de suffix (hostpart) die ik gebruik voor deze server)

nmcli connection
sudo nmcli connection modify "Wired connection 1" ipv6.method "auto"
sudo nmcli connection modify "Wired connection 1" ipv6.addr-gen-mode "eui64"
sudo nmcli connection modify "Wired connection 1" ipv6.token "::31"
sudo nmcli connection up "Wired connection 1"

[BushWhacker]

nescafe schreef op zondag 2 januari 2022 @ 16:47:
[...]


Als je Home Assistant wilt kunnen benaderen via IPv6 dien je het ip-adres van de server waar Home Assistant op draait als AAAA-record op te nemen. Tevens zorg je ervoor dat je server bereikbaar is via poort 80 en 443, je moet de firewalls op zowel je server als je gateway voorzien van de nodige allow-rules.

Niet het ip-adres van de router gebruiken, want dan moet je gaan port forwarden en dat is bij IPv6 niet echt gebruikelijk.

Dat zou ik niet doen.
Ik zou nginx op 1 server zetten als reverse-proxy en die alles laten afhandelen.
Wel heb je dan voor alle ha-instances een AAAA-record nodig, maar die kunnen alle naar hetzellfde IPv6 adres staan.
Ook het TLS-Certificaat hoeft dan alleen maar op de nginx-server te staan en is het gemakkelijker om alle security te regelen (op 1 server ipv alle).

En nog veel beter. Helemaal niets open zetten en alleen via een VPN-verbinding werken.

[nero355]

BushWhacker schreef op zondag 2 januari 2022 @ 17:34:
Dat zou ik niet doen.
Ik zou nginx op 1 server zetten als reverse-proxy en die alles laten afhandelen.

Ik zou een echte Proxy dat soort dingen laten doen

En nog veel beter. Helemaal niets open zetten en alleen via een VPN-verbinding werken.

Sowieso!

L0g0ff schreef op zondag 2 januari 2022 @ 17:24:
Ik heb dat ook een tijdje gedaan. Al het poort 53 verkeer naar buiten geblokkeerd alleen mijn pihole mocht nog naar buiten.

Op zich werkte dit wel maar ik had elke keer nadat ik iets vroeg aan Google home een seconden of 7 extra vertraging. En alleen bij mijn eerste vraag wat duidelijk liet zien dat het dns gerelateerd was.

In mijn logging zag ik gewoon dat die Google devices eerst 8.8.8.8 proberen te benaderen. En pas daarna de dns die ik uitdeelde via dhcp.

Ik heb nu die regel er weer afgehaald. Snelheid voor zorgvuldigheid zeg maar...

Daar heb je dus DNAT/SNAT voor!

Maar ook dat kan nog veel beter : Alle Google Spyware het huis uit trappen!

[borft]

nero355 schreef op maandag 3 januari 2022 @ 00:25:
[...]

Ik zou een echte Proxy dat soort dingen laten doen

Waarom (en wat vind jij een echte proxy dan)? nginx als reverse proxy is een vrij standaard oplossing om backend services te exposen (en eventueel te load balancen / ssl termination te doen). Er zijn redelijk standaard docker images voor die nagenoeg geen configuratie nodig hebben.

[L0g0ff]

Ik denk dat @nero355 doelt op pound of squid.

Maar nginx werkt ook prima voor hass vind ik zelf

[RobertMe]

L0g0ff schreef op maandag 3 januari 2022 @ 14:04:
Ik denk dat @nero355 doelt op pound of squid.

Maar nginx werkt ook prima voor hass vind ik zelf

Of HAProxy

In ieder geval heb je bij Nginx ook twee smaakjes? Nginx de traditionele webserver, zoals Apache httpd, die ook reverse proxy ondersteund. Iets wat ik zelf ook wel eens heb gebruikt. En NPM / Nginx Proxy Manager, iets waar ik verder onbekend mee ben, maar AFAIK wel populair is in het Docker / container landschap. Sterker nog, volgens mij is NPM de defacto standaard ingress controller in Kubernetes. Zelf gebruik ik dan weer Traefik, wat in ieder geval voor mijn doeleinden ook meer dan prima is.

[RobertMe]

RobertMe schreef op vrijdag 31 december 2021 @ 14:21:
Maar hoe ik het thuis ga aanpakken met Pi-Hole in Docker ben ik ook nog niet over uit. Of ik ook daarbij voor DNAT ga, of ik de container met macvlan rechtstreeks aan het netwerk hang, of iets anders.
Iets anders zou dan neerkomen op ook weer in Docker een IPv6 netwerk maken, maar dat binnen het netwerk ook routeerbaar maken met het host OS als route er naartoe. Of wat volgens mij ook kan is een Docker netwerk maken met een kleiner subnet dan de host heeft, en vervolgens "ARP van IPv6" laten proxien door het host OS.

Voor mij als "netwerk hobbiest / prutser" (ben programmeuvan beroep) lastig om daar de juiste oplossing in te vinden dus.

Mij hier gisteren maar eens aan begeven. Tussen de soep en aardappelen door, wat ik achteraf beter niet had kunnen doen aangezien het nogal wat downtime mee bracht (maar misschien ook eigen schuld en had ik eerst de DNS server van alle VLANs terug moeten zetten naar de USG ).
Ik heb PiHole nu draaien met een macvlan pootje in elk VLAN. Probleem daarbij bleek achteraf dat PiHole (/dnsmasq) by default alleen op eth0 luistert terwijl ik dus eth0 t/m eth5 of iets dergelijks heb. Verder probleem zat in dat Docker in een LXC container op Proxmox draait, en daar iets niet helemaal lekker ging. Ik had een eerste test gedaan met een VLAN in 172.16.10.0/24 en dat leek te werken (achteraf waarschijnlijk nog steeds niet door de listen interface quirk). Dit puur door het macvlan aan te maken met ala parent eth0.40 waarbij deze door Docker aangemaakt werd als VLAN subinterface. Dat werkte ook allemaal prima en ik kon de container zowel op zijn IPv4 als IPv6 adres bereiken. Vervolgens de andere VLANs op dezelfde manier gedaan, maar die had ik ook al als interface aangemaakt in Proxmox. Dus Proxmox maakte bv al eth0.10 voor VLAN 10. Omdat ik dit niet nodig had bij VLAN 40 heb ik dit toen ook allemaal opgeruimd. Maar de boel werkte dus niet, waarbij de container niet naar buiten kon communiceren over deze interfaces / VLANs en ik ook niet met de container kon communiceren. Na vele vormen van trial & error bleek de oplossing dus tweeledig te zijn. Proxmox moest wel de interfaces voor de VLANs aanmaken en die dan ook gebruiken als parent voor het macvlan netwerk in Docker, en daarnaast DNSMasq op alle interfaces laten werken. Waarbij ik achteraf gezien dus met de trial & error tegen steeds een van deze twee problemen aan liep, maar niet door had dat het twee ongerelateerde issues waren.

In het kort heb ik nu dus PiHole ook beschikbaar via IPv6. En meer on topic / relevant. Blijkbaar hoef je in de Docker config (daemon.json) dus niet IPv6 te configureren, en kun je dan toch handmatig netwerken aanmaken met IPv6 support. De configuratie in de daemon.json zal dus puur betrekking hebben op de bridge die Docker altijd aanmaakt.

[nero355]

borft schreef op maandag 3 januari 2022 @ 12:38:
Waarom (en wat vind jij een echte proxy dan)?

Wat @L0g0ff en @RobertMe al hebben gepost :

- http://www.squid-cache.org/
Bestaat al heel lang en is zo'n beetje de meest bekende oplossing IMHO
- [Traefik - Proxy/Loadbalancer] Ervaringen & Discussie
Vooral populair bij de Docker gebruikers voor zover ik dat goed heb begrepen...
- https://www.haproxy.org/
Schijnt van alles en nog wat te kunnen naast het Proxy gebeuren, maar nog steeds een betere keuze dan een willekeurige HTTPd

nginx als reverse proxy is een vrij standaard oplossing om backend services te exposen (en eventueel te load balancen / ssl termination te doen). Er zijn redelijk standaard docker images voor die nagenoeg geen configuratie nodig hebben.

Tegenwoordig is NginX heel hip net als Apache dat vroeger was, maar ook toen riep iedereen : Gebruik een echte Proxy en misbruik je Webserver niet voor dat soort meuk!

/EDIT :

RobertMe schreef op maandag 3 januari 2022 @ 14:31:
Ik heb PiHole nu draaien met een macvlan pootje in elk VLAN.

NICE!

Probleem daarbij bleek achteraf dat PiHole (/dnsmasq) by default alleen op eth0 luistert terwijl ik dus eth0 t/m eth5 of iets dergelijks heb.

Had effe "voorbijgefietst' in het Pi-Hole Topic dan hadden we je dat meteen verteld!

Maar de boel werkte dus niet, waarbij de container niet naar buiten kon communiceren over deze interfaces / VLANs en ik ook niet met de container kon communiceren. Na vele vormen van trial & error bleek de oplossing dus tweeledig te zijn. Proxmox moest wel de interfaces voor de VLANs aanmaken en die dan ook gebruiken als parent voor het macvlan netwerk in Docker, en daarnaast DNSMasq op alle interfaces laten werken. Waarbij ik achteraf gezien dus met de trial & error tegen steeds een van deze twee problemen aan liep, maar niet door had dat het twee ongerelateerde issues waren.

Let er ook op dat je niet meerdere Gateways gebruikt en dus meerdere Default Routes naar buiten hebt!

In principe handelt Linux dat wel goed af door elke Interface een andere Weight mee te geven, maar neem het zekere voor het onzekere en gooi alle overbodige Gateways gewoon overboord!

Ohh en vergeet je Services/Daemons zoals SSH en LigHTTPd niet op één bepaalde Interface te binden!

[ Voor 40% gewijzigd door nero355 op 03-01-2022 14:43 ]

[RobertMe]

nero355 schreef op maandag 3 januari 2022 @ 14:34:
[...]

Had effe "voorbijgefietst' in het Pi-Hole Topic dan hadden we je dat meteen verteld!

Had ik dus wel moeten weten dat er een issue met PiHole was Doordat dat ene (test) VLAN goed ging, zonder dat daarvoor een interface in Proxmox geregistreerd stond, ben ik dus al die andere interfaces gaan verwijderen uit Proxmox. Dat in combinatie met tussendoor niet testen, en ik kon dus in 99% van de trial & errors überhaupt de container niet pingen. Tegen de tijd dat ik dat door had, en de interfaces vanuit Proxmox weer had aangemaakt, was het fixen van de PiHole config peanuts. Het probleem zat hem puur er in dat de test situatie werkte / leek te werken (achteraf waarschijnlijk dus niet door alleen op eth0 te luisteren verhaal), en ik daardoor dingen ben gaan opruimen die for whatever reason niet weg konden. Waardoor dus op adres van het ene VLAN / subnet de container wel te pingen was, en de andere niet. En vanuit de container via de ene (default) route weer wel naar buiten gecommuniceerd kon worden, maar via de andere route niet.

[...]

Let er ook op dat je niet meerdere Gateways gebruikt en dus meerdere Default Routes naar buiten hebt!

ip route show heb ik meer dan eens uitgevoerd, en leverde netjes één enkele default route op. So no issues there.

Ohh en vergeet je Services/Daemons zoals SSH en LigHTTPd niet op één bepaalde Interface te binden!

Of juist wel. Deze LXC bevat alleen maar infrastructuur. Dus juist alles wat er op draait zou alleen in het default VLAN beschikbaar moeten zijn. Iets dat nu niet het geval is en ik nog moet fixen. Beetje knullig dat de USG zijn firewall wél verkeer tussen de VLANs blokkeert zodat IoT spul dus niet aan bv PCs kan komen, maar de "server" (/LXC) waar ook de UniFi Controller in draait een IP in elk VLAN heeft en IoT hardware dus wel de UniFi Controller zou kunnen opvragen. Of zoals je aangeeft, SSH kunnen doen naar die server / LXC.

[nero355]

RobertMe schreef op maandag 3 januari 2022 @ 14:59:
ip route show heb ik meer dan eens uitgevoerd, en leverde netjes één enkele default route op. So no issues there.

Mooi!

Of juist wel. Deze LXC bevat alleen maar infrastructuur. Dus juist alles wat er op draait zou alleen in het default VLAN beschikbaar moeten zijn. Iets dat nu niet het geval is en ik nog moet fixen.

Ja, dat bedoel ik dus ook

Mijn Management VLAN kan alles bereiken via eth0 en via alle VLAN sub-interfaces kunnen de apparaten in die VLAN's alleen de Pi-Hole FTLDNS/DNSmasq poort voor DNS bereiken!

Beetje knullig dat de USG zijn firewall wél verkeer tussen de VLANs blokkeert zodat IoT spul dus niet aan bv OCs kan komen, maar de "server" (/LXC) waar ook de UniFi Controller in draait een IP in elk VLAN heeft en IoT hardware dus wel de UniFi Controller zou kunnen opvragen. Of zoals je aangeeft, SSH kunnen doen naar die server / LXC.

Als je maar geen IP Forwarding per ongeluk aanzet dan is er IMHO weinig aan de hand!

[borft]

nero355 schreef op maandag 3 januari 2022 @ 14:34:
[...]

Wat @L0g0ff en @RobertMe al hebben gepost :

- http://www.squid-cache.org/
Bestaat al heel lang en is zo'n beetje de meest bekende oplossing IMHO
- [Traefik - Proxy/Loadbalancer] Ervaringen & Discussie
Vooral populair bij de Docker gebruikers voor zover ik dat goed heb begrepen...
- https://www.haproxy.org/
Schijnt van alles en nog wat te kunnen naast het Proxy gebeuren, maar nog steeds een betere keuze dan een willekeurige HTTPd

Hmm, we gaan een beetje off topic, maar ben het niet met je eens. Squid is helemaal niet een bekende reverse proxy oplossing. We hebben het hier over het opvangen van inkomend verkeer, niet over een uitgaande caching proxy. HAProxy loopt ver achter op nginx, het heeft bijvoorbeeld jaren geduurd voordat ze uberhaupt ssl-termination ondersteunden. Het is een leuke oplossing voor load balancing, maar als je in de docker wereld gaat kijken, kom je veel eerder bij oplossingen als nginx of inderdaad traefik (vooral als ingress bij bv k8s) uit.

Overigens nginx is niet een willekeurige httpd, reverse proxying is precies een van de toepassingen waar het voor geschreven is.

[nero355]

borft schreef op maandag 3 januari 2022 @ 15:15:
Squid is helemaal niet een bekende reverse proxy oplossing. We hebben het hier over het opvangen van inkomend verkeer, niet over een uitgaande caching proxy.

Squid is al 20+ jaar "de Proxy der Proxies" zo'n beetje en doet wel meer dan alleen wat caching!

HAProxy loopt ver achter op nginx, het heeft bijvoorbeeld jaren geduurd voordat ze uberhaupt ssl-termination ondersteunden. Het is een leuke oplossing voor load balancing, maar als je in de docker wereld gaat kijken, kom je veel eerder bij oplossingen als nginx of inderdaad traefik (vooral als ingress bij bv k8s) uit.

Wat betreft HAProxy : Zou best kunnen, want de ex-collega's die er lyrisch over waren deden vooral Load Balancing en nog wat andere zaken

Maar als ik een Proxy nodig zou hebben dan zou ik eerder voor Traefik kiezen dan NginX om de simpele reden dat ik vreselijk veel klanten heb gehad die het toch echt vooral als Webserver gebruikten en voor zover ik weet NginX ook als Apache concurrent is ontwikkeld

Overigens nginx is niet een willekeurige httpd, reverse proxying is precies een van de toepassingen waar het voor geschreven is.

Dat heb ik destijds dus niet zo ervaren...

[mrdemc]

nero355 schreef op maandag 3 januari 2022 @ 15:26:
[...]

Squid is al 20+ jaar "de Proxy der Proxies" zo'n beetje en doet wel meer dan alleen wat caching!


[...]

Wat betreft HAProxy : Zou best kunnen, want de ex-collega's die er lyrisch over waren deden vooral Load Balancing en nog wat andere zaken

Maar als ik een Proxy nodig zou hebben dan zou ik eerder voor Traefik kiezen dan NginX om de simpele reden dat ik vreselijk veel klanten heb gehad die het toch echt vooral als Webserver gebruikten en voor zover ik weet NginX ook als Apache concurrent is ontwikkeld


[...]

Dat heb ik destijds dus niet zo ervaren...

Wat betreft nginx, dat wordt echt ontzettend veel gebruikt als proxyserver voor inkomend verkeer, en niet alleen HTTP. Het zit ook niet voor niets als reverse proxy optie in standaard we hosting platformen als Plesk, DirectAdmin en CPanel. Kijk ook even naar de eigen about pagina:

quote: https://nginx.org/en/

nginx [engine x] is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server, originally written by Igor Sysoev.

Wat squid betreft kan het inderdaad meerdere kanten op, al kom ik het vooral tegen voor uitgaande verbindingen.

quote: http://www.squid-cache.org/

Website Content Acceleration and Distribution
Thousands of web-sites around the Internet use Squid to drastically increase their content delivery. Squid can reduce your server load and improve delivery speeds to clients.

[ Voor 4% gewijzigd door mrdemc op 03-01-2022 16:06 ]

[borft]

nero355 schreef op maandag 3 januari 2022 @ 15:26:
[...]

Squid is al 20+ jaar "de Proxy der Proxies" zo'n beetje en doet wel meer dan alleen wat caching!


[...]

Wat betreft HAProxy : Zou best kunnen, want de ex-collega's die er lyrisch over waren deden vooral Load Balancing en nog wat andere zaken

Maar als ik een Proxy nodig zou hebben dan zou ik eerder voor Traefik kiezen dan NginX om de simpele reden dat ik vreselijk veel klanten heb gehad die het toch echt vooral als Webserver gebruikten en voor zover ik weet NginX ook als Apache concurrent is ontwikkeld


[...]

Dat heb ik destijds dus niet zo ervaren...

Fair enough Mijn ervaringen zijn anders (zo leren we ook nog wat). Ik ben Squid in het wild eigenlijk voornamelijk als lokale proxy tegengekomen, niet als reverse proxy. Volgens mij heeft squid ook matige support voor dingen als http2, SNI, etc. Nginx kan dat allemaal wel, overigens ook jaren eerder dan Apache

[Snow_King]

nero355 schreef op maandag 3 januari 2022 @ 15:26:
[...]

mrdemc schreef op maandag 3 januari 2022 @ 16:05:
[...]

borft schreef op woensdag 5 januari 2022 @ 17:41:
[...]

Of je nu HAProxy, Apache HTTPd, Nginx, Squid of Traefik gebruikt (ik heb ze allemaal gebruikt): Het ligt aan de operator hoe je het in zet, vaak niet aan de software.

Alles heeft voordelen en nadelen, maar het belangrijkste is hoe je de tool in zet en niet welke tool.

Het ondersteund allemaal IPv6 en daar gaat het toch vooral om in dit topic?

[borft]

Snow_King schreef op donderdag 6 januari 2022 @ 08:44:
[...]


[...]


[...]

Of je nu HAProxy, Apache HTTPd, Nginx, Squid of Traefik gebruikt (ik heb ze allemaal gebruikt): Het ligt aan de operator hoe je het in zet, vaak niet aan de software.

Alles heeft voordelen en nadelen, maar het belangrijkste is hoe je de tool in zet en niet welke tool.

Het ondersteund allemaal IPv6 en daar gaat het toch vooral om in dit topic?

helemaal mee eens

[Paul]

nero355 schreef op maandag 3 januari 2022 @ 15:26:
Squid is al 20+ jaar "de Proxy der Proxies" zo'n beetje en doet wel meer dan alleen wat caching!

Ik denk: "Die komt met Citrix of F5 aanzetten", maar nee, met oude meuQ

[nero355]

Paul schreef op donderdag 6 januari 2022 @ 10:17:
Ik denk: "Die komt met Citrix of F5 aanzetten", maar nee, met oude meuQ

Doe maar duur!

Vrijwel rechtstreekse quote van een ex-collega :

"Ik doe dingen met HA Proxy binnen een paar uur waar ik met zo'n F5 meerdere dagen voor nodig heb!"

Maar dat kwam vooral door zijn ervaring met beiden denk ik!

[CAPSLOCK2000]

Haproxy is zo'n 80/20 oplossing. In 80% van de gevallen voldoet het met maar 20% van de moeite die je nodig hebt voor andere oplossingen. De inhoudsopgave van F5 is volgens mij langer dan de hele handleiding van haproxy. En als je handig bent met Linux kun je best veel van wat zo'n F5 kan zelf nabouwen met weinig moeite, uiteindelijk is een groot deel van wat een F5 doet standaard Linux-functionaliteit met een mooi jasje.

Ik gebruik haproxy zelf als front-end voor mijn Docker-omgeving. Een van de voordelen van zo'n constructie is dat ik aan de buitenkant IPv4 en IPv6 kan aanbieden, ongeacht wat de container zelf kan. Ik heb namelijk nog een stukje legacy en dat is zo toch bereikbaar via IPv6.
Eerlijk gezegd heb ik meer dan legacy want mijn ervaringen met Docker (swarm) en multistack netwerken zijn niet zo best. Ik zoek behoorlijk het randje op van hoe Docker werkt maar het is toch teleurstellend dat Docker minder goed met IPv6 omgaat dan met IPv4. Ik weet niet eens zeker of het de 'schuld' is van Docker of dat IPv6 me "beschermt" tegen stommiteiten want ik geloof dat duplicate-adress detection een rol speelt. IPv4 controleert dat niet dus kom ik weg met 3 servers die op een bepaald punt allemaal hetzelfde IP-adres gebruiken als gateway voor een intern netwerkje dat via een bridge naar een wireguard tunnel wordt gestuurd. Niet echt alledaags zeg maar.
Eerlijk gezegd kan ik zo snel niet meer verwoorden wat er nu precies fout ging. Ik heb het punt bereikt dat ik heb besloten het maar even te laten liggen en over een jaar eens te kijken of er nog iets veranderd is (in de software of in mijn inzicht).

Poeh, back on topic, dat was even aanpoten

[RnB]

Sinds een paar dagen heb ik naast een IPv4, ook een IPv6 adres op de interface naar het internet.
Middels Prefix Delegation hebben al mijn clients in mijn VLANs ook een IPv6 adres.
Alles lijkt prima te werken: websites die IPv6 ondersteunen, bereik ik met mijn IPv6 adres, websites die het niet ondersteunen bereik ik met mijn IPv4 adres. Ook in mijn interne netwerk kan ik alle devices die IPv6 ondersteunen op hun adres bereiken.

Nu viel het mij op dat de IPv6 adressen van mijn clients, niet op basis van EUI-64 zijn, maar totaal random. Her en der lees ik dat dit in ieder geval onder MacOS een doel heeft, namelijk dat je IPv6 adres randomly wordt gegenereerd vanwege privacy redenen. Daar kan ik inkomen, echter kan ik hier geen bevestiging van Apple zelf van vinden. Ook mijn Windows clients gebruiken een random gegenereerd adres, maar misschien is het ook onder Windows vanwege privacy redenen.
Uiteraard ben ik in de config van de clients gedoken, maar nergens heb ik de mogelijkheid tot het kiezen van hoe mijn adressen gegenereerd worden. Ook mijn firewall geeft me hierin geen keuze, anders dan dat ik mijn adressen uitdeel middels Prefix Delegation.

Mijn IPv6 kennis is nog beperkt, heb er heel kort wat mee gespeeld toen ik drie jaar geleden voor mijn CCNA ging. Naar mijn weten kunnen clients een IPv6 adres krijgen door een Statefull DHCPv6 server of door SLAAC, waarbij het laatste een makkelijk te herkennen adres geeft, want ergens in het adres komt FFFE voor en een gedeelte van het MAC adres van de client.

Mis ik nu iets of kunnen mijn adressen inderdaad random gegenereerd zijn vanwege privacy redenen? Herkent iemand dit?

[mrdemc]

RnB schreef op donderdag 13 januari 2022 @ 20:00:
Sinds een paar dagen heb ik naast een IPv4, ook een IPv6 adres op de interface naar het internet.
Middels Prefix Delegation hebben al mijn clients in mijn VLANs ook een IPv6 adres.
Alles lijkt prima te werken: websites die IPv6 ondersteunen, bereik ik met mijn IPv6 adres, websites die het niet ondersteunen bereik ik met mijn IPv4 adres. Ook in mijn interne netwerk kan ik alle devices die IPv6 ondersteunen op hun adres bereiken.

Nu viel het mij op dat de IPv6 adressen van mijn clients, niet op basis van EUI-64 zijn, maar totaal random. Her en der lees ik dat dit in ieder geval onder MacOS een doel heeft, namelijk dat je IPv6 adres randomly wordt gegenereerd vanwege privacy redenen. Daar kan ik inkomen, echter kan ik hier geen bevestiging van Apple zelf van vinden. Ook mijn Windows clients gebruiken een random gegenereerd adres, maar misschien is het ook onder Windows vanwege privacy redenen.
Uiteraard ben ik in de config van de clients gedoken, maar nergens heb ik de mogelijkheid tot het kiezen van hoe mijn adressen gegenereerd worden. Ook mijn firewall geeft me hierin geen keuze, anders dan dat ik mijn adressen uitdeel middels Prefix Delegation.

Mijn IPv6 kennis is nog beperkt, heb er heel kort wat mee gespeeld toen ik drie jaar geleden voor mijn CCNA ging. Naar mijn weten kunnen clients een IPv6 adres krijgen door een Statefull DHCPv6 server of door SLAAC, waarbij het laatste een makkelijk te herkennen adres geeft, want ergens in het adres komt FFFE voor en een gedeelte van het MAC adres van de client.

Mis ik nu iets of kunnen mijn adressen inderdaad random gegenereerd zijn vanwege privacy redenen? Herkent iemand dit?

Wat je zegt klopt inderdaad. Waarschijnlijk is dit het Privacy Extension deel van IPv6 waar je tegenaan loopt. Dit staat standaard ingeschakeld op Windows en MacOS. Je kunt het uitschakelen, maar normaal gesproken zou ik verwachten dat je dit ingeschakeld wilt laten. Als je een client wilt benaderen kun je dit vervolgens het beste doen via de interne hostnaam van het apparaat. Soms is het inderdaad wel nodig/handig

[ Voor 6% gewijzigd door mrdemc op 13-01-2022 20:50 ]

[RnB]

Ah top, IPv6 Privacy Extension is inderdaad waar ik tegenaan loop. Best mooi dat het onderdeel is van het protocol.

Thanks!

[ Voor 39% gewijzigd door RnB op 13-01-2022 21:07 ]

[Keiichi]

TIP: The NTP pools starting with 2 point to IPv6-ready servers.
2.pool.ntp.org has servers with IPv6 connectivity while 1.pool.ntp.org and 3.pool.ntp.org do NOT.

Similarly, 2.europe.pool.ntp.org supports IPv6. 1.europe.pool.ntp.org and 3.europe.pool.ntp.org do NOT support IPv6.

Weet iemand waarom dit zo is? Ben bezig met ipv6 only servers en heb standaard eigenlijk een ntp source te weinig op deze manier.

(Ik kan vaste v6 servers erin zetten, maar dan is er altijd kans dat die precies in de gebruikte pool zitten )

[Roetzen]

Al sinds enige dagen is nos.nl niet meer via IPv6 bereikbaar.

fZiggo gebied.

Ligt het aan mij of zijn er meer die dit zo ervaren?

[DDX]

nos.nl heeft zover ik kan zien geen AAAA record ?

[Roetzen]

DDX schreef op maandag 24 januari 2022 @ 16:07:
nos.nl heeft zover ik kan zien geen AAAA record ?

Nu niet meer inderdaad. Maar tot een paar dagen geleden was dat er wel. En dat was al minstens vijf jaar zo.

[DDX]

Roetzen schreef op maandag 24 januari 2022 @ 16:33:
[...]

Nu niet meer inderdaad. Maar tot een paar dagen geleden was dat er wel. En dat was al minstens vijf jaar zo.

Ok nooit op gelet, maar mogelijk dus issues met ipv6 routing en hebben ze daarom AAAA records weggehaald.

[nero355]

Keiichi schreef op maandag 24 januari 2022 @ 15:19:
Ben bezig met ipv6 only servers en heb standaard eigenlijk een ntp source te weinig op deze manier.

Ik misbruik altijd de volgende twee als ik effe snel een NTP Source nodig heb :
- time.windows.com
- ntp.ubuntu.com

Dus misschien is dat een idee

[Keiichi]

nero355 schreef op maandag 24 januari 2022 @ 18:23:
[...]

Ik misbruik altijd de volgende twee als ik effe snel een NTP Source nodig heb :
- time.windows.com
- ntp.ubuntu.com

Dus misschien is dat een idee

Jawel, maar moet dat nu elke keer gaan configgen als ik een server config. Althans, voor het meeste grut heb ik ansible waar ik basis config mee maak, die moet ik nu uitbreiden met een ansible-role

time.windows.com heeft geen v6 records

[ Voor 4% gewijzigd door Keiichi op 24-01-2022 18:54 ]

[Nakebod]

Zo te zien geen IPv6 (meer) op nos.nl, maar nog wel cookies.nos.nl en adcdn.ster.nl

Hoe zit het eigenlijk met fallback naar IPv4 als IPv6 een timeout geeft?
Afgelopen week moest ik op https://asolutions.nl zijn, en die geeft na een 30 seconden een timeout.
Geen automatische fallback naar IPv4. Zowel in Chrome als Firefox, meerdere devices. Pas toen ik op mobiele data zat @ telefoon kon ik naar die site via IPv4.
Met www 'subdomein' doet die het wel, maar die geeft een heel ander IPv6 adres terug.

Volgens ipv6-test.com: Fallback to IPv4 in 1 second
Dan verwacht ik dat een site het alsnog doet via IPv4 als IPv6 stuk is, of verwacht ik dan wonderen?

[nero355]

Keiichi schreef op maandag 24 januari 2022 @ 18:53:
Jawel, maar moet dat nu elke keer gaan configgen als ik een server config. Althans, voor het meeste grut heb ik ansible waar ik basis config mee maak, die moet ik nu uitbreiden met een ansible-role

Dat gedeelte van je vorige reactie begreep ik dus niet echt en deed daarom gewoon wat voorstellen

time.windows.com heeft geen v6 records

Typisch!

Kon het niet checken, want geen IPv6 hier, maar had het online kunnen checken nou ik erover nadenk...

Ohh well!

[Keiichi]

Ik ben tegenwoordig ergens aan het hopen dat in ieder geval grote partijen gewoon ipv6 ondersteunen. Kan me ook voorstellen zoals bij die NTP servers dat ze niet direct alles van v6 gaan voorzien, er zullen nog legio aan machines zijn die wel graag ipv6 gaan pakken maar uiteindelijk 0.0 connectiviteit hebben zonder dat er een goede fallback naar v4 gedaan word

Misschien toch maar 127.[1-255].x.x publiek routerbaar maken

[Snow_King]

Nakebod schreef op maandag 24 januari 2022 @ 18:59:
Zo te zien geen IPv6 (meer) op nos.nl, maar nog wel cookies.nos.nl en adcdn.ster.nl

Lekker is dat zeg! Ik vind het een vreemde gang van zaken dat zoiets gedaan is.

Ik zou even mailen met [e-mail] (reageren snel!)

[AW_Bos]

Ik heb net maar bij mijn nieuwe VPS-hosting ook maar even IPv6 gekoppeld aan mijn server, en met succes!

Uit interesse heb ik eens zitten neuzelen tussen een traceroute van IPv4 en IPv6, maar toch merk ik dat een traceroute naar bijv. Tweakers bij IPv6 13 hops geeft tegenover 10 hops met IPv4?

Zo kom ik bij IPv6 traceroute deze tegen:

code:

 7     9 ms     8 ms     8 ms  cr0.eunets.nl.fusixnetworks.net [2a00:a7c0:e20a::9]

Bij de IPv4 traceroute kan ik niet een tussenhop bij Fusixnetwerks terugvinden?
Wat gebeurt er hier, en hoe kan het dat er meer hops zijn? En waarom zou je dit willen?

[Brahiewahiewa]

AW_Bos schreef op dinsdag 25 januari 2022 @ 23:21:
...
Wat gebeurt er hier, en hoe kan het dat er meer hops zijn? En waarom zou je dit willen?

Waarom zou de ipv6 routing precies zo moeten lopen als de ip4 routing? De ene keer zal de ipv6 route meer hops hebben, de andere keer zal de ip4 route meer hops hebben.

btw:

code:

  7    15 ms    15 ms    14 ms  br0.nikhef.nl.fusixnetworks.net [37.139.139.240]
  8    15 ms    16 ms    13 ms  cr0.eunets.nl.fusixnetworks.net [37.139.139.25]

[AW_Bos]

Brahiewahiewa schreef op woensdag 26 januari 2022 @ 01:07:
[...]

Waarom zou de ipv6 routing precies zo moeten lopen als de ip4 routing? De ene keer zal de ipv6 route meer hops hebben, de andere keer zal de ip4 route meer hops hebben.

btw:

code:

  7    15 ms    15 ms    14 ms  br0.nikhef.nl.fusixnetworks.net [37.139.139.240]
  8    15 ms    16 ms    13 ms  cr0.eunets.nl.fusixnetworks.net [37.139.139.25]

Hm, het gaat dus met regelmaat zie ik?
Via IPv4 kom ik hier niet langs.

[ Voor 28% gewijzigd door AW_Bos op 26-01-2022 01:17 ]

[Brahiewahiewa]

AW_Bos schreef op woensdag 26 januari 2022 @ 01:15:
[...]

Hm, het gaat dus met regelmaat zie ik?
Via IPv4 kom ik hier niet langs.

Een groot gedeelte van de routers op internet wordt automatisch geconfigureerd, vaak afhankelijk van de hoeveelheid traffic. Momenteel zitten we in de overgangsperiode tussen ip4 en ipv6. Daarom zal ip4 verkeer verschuiven naar ipv6 en dat beïnvloedt zowel de ip4 routers als de ipv6 routers

[Snow_King]

AW_Bos schreef op woensdag 26 januari 2022 @ 01:15:
[...]

Hm, het gaat dus met regelmaat zie ik?
Via IPv4 kom ik hier niet langs.

Ja, zeker. Sowieso is je route heen en terug zelfs niet altijd het zelfde, bijna nooit eigenlijk.

IPv4 en IPv6 heb hun eigen routeringstabellen en zullen dus vaak andere routes nemen.

[c-nan]

Zijn er nog leuke extensies voor Chrome om makkelijk te kunnen zien of je via IPv4 of via IPv6 op een website zit?

[darkrain]

c-nan schreef op woensdag 26 januari 2022 @ 10:22:
Zijn er nog leuke extensies voor Chrome om makkelijk te kunnen zien of je via IPv4 of via IPv6 op een website zit?

Ja heet IPvFoo (is er ook voor Firefox), deze werkt prima!

[Snow_King]

Snow_King schreef op dinsdag 25 januari 2022 @ 10:37:
[...]

Lekker is dat zeg! Ik vind het een vreemde gang van zaken dat zoiets gedaan is.

Ik zou even mailen met [e-mail] (reageren snel!)

@Nakebod Ik heb gemailed met [e-mail] en kreeg terug:

Het klopt dat nos.nl geen IPv6 meer heeft. En nog wel meer sites van publieke omroepen maken zo'n zelfde verhuizing mee.

De veranderde onderliggende techniek die nu gebruikt wordt heeft helaas (nog) geen IPv6 ondersteuning.

In de toekomst keert IPv6 vast wel weer terug, maar dat is momenteel helaas niet in handen van NPO of NOS, en er valt dus ook geen planning op af te geven.

Ik heb al een reactie gegeven dat ik het een vreemde gang van zaken vind. Anno 2022 vind ik het zeker voor een website als nos.nl een hele rare move. Zo zien we dus hoe serieus het genomen wordt door een aantal mensen.

[c-nan]

Snow_King schreef op woensdag 26 januari 2022 @ 11:21:
[...]

@Nakebod Ik heb gemailed met [e-mail] en kreeg terug:


[...]


Ik heb al een reactie gegeven dat ik het een vreemde gang van zaken vind. Anno 2022 vind ik het zeker voor een website als nos.nl een hele rare move. Zo zien we dus hoe serieus het genomen wordt door een aantal mensen.

Kennelijk nemen ze IPv6 niet op in hun requirements list bij een move/migratie naar een ander platform/omgeving.

[Roetzen]

c-nan schreef op woensdag 26 januari 2022 @ 11:29:
[...]

Kennelijk nemen ze IPv6 niet op in hun requirements list bij een move/migratie naar een ander platform/omgeving.

En dat is dan een grote misser.

Onze overheidsdiensten hadden allemaal per 1 jan van dit jaar via IPv6 bereikbaar moeten zijn.Dat dit niet geldt voor een publieke organisatie die grotendeels door belastinggeld wordt gefinancierd vind ik kwalijk.

[Vinnienerd]

code:

dig AAAA nos.nl

; <<>> DiG 9.10.6 <<>> AAAA nos.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33180
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;nos.nl.                IN  AAAA

;; ANSWER SECTION:
nos.nl.         0   IN  AAAA    2600:9000:2315:9600:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:5800:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:d200:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:b200:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:4e00:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:4200:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:1e00:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:fc00:f:425b:9b80:93a1

code:

curl -6 https://nos.nl -v -s > /dev/null
*   Trying 2600:9000:2204:6000:f:425b:9b80:93a1:443...
* TCP_NODELAY set
* Connected to nos.nl (2600:9000:2204:6000:f:425b:9b80:93a1) port 443 (#0)

Mis ik iets?

[Snow_King]

Roetzen schreef op woensdag 26 januari 2022 @ 13:44:
[...]

En dat is dan een grote misser.

Onze overheidsdiensten hadden allemaal per 1 jan van dit jaar via IPv6 bereikbaar moeten zijn.Dat dit niet geldt voor een publieke organisatie die grotendeels door belastinggeld wordt gefinancierd vind ik kwalijk.

Het lijkt er op dat iemand een vinkje heeft aan gezet!

Vinnienerd schreef op woensdag 26 januari 2022 @ 13:59:

code:

dig AAAA nos.nl

; <<>> DiG 9.10.6 <<>> AAAA nos.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33180
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;nos.nl.                IN  AAAA

;; ANSWER SECTION:
nos.nl.         0   IN  AAAA    2600:9000:2315:9600:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:5800:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:d200:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:b200:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:4e00:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:4200:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:1e00:f:425b:9b80:93a1
nos.nl.         0   IN  AAAA    2600:9000:2315:fc00:f:425b:9b80:93a1

code:

curl -6 https://nos.nl -v -s > /dev/null
*   Trying 2600:9000:2204:6000:f:425b:9b80:93a1:443...
* TCP_NODELAY set
* Connected to nos.nl (2600:9000:2204:6000:f:425b:9b80:93a1) port 443 (#0)

Mis ik iets?

Nee, zeker niet. NOS is naar EC2 gegaan en gebruikt CloudFront. Daar heeft iemand waarschijnlijk IPv6 uit gezet of niet aan gezet bij die CloudFront instance. Het kan ook nog zijn dat de AAAA-records ontbraken.

Deze ochtend heen en weer lopen mailen met de NPO en nu staat magisch IPv6 weer aan!

[Roetzen]

Snow_King schreef op woensdag 26 januari 2022 @ 14:05:
[...]


Deze ochtend heen en weer lopen mailen met de NPO en nu staat magisch IPv6 weer aan!

Nadat ik Firefox opnieuw had opgestart krijg ik hier nos.nl ook weer via IPv6.

Mooi dat het opgelost is. Maar wel opmerkelijk dat er een Tweaker aan te pas moest komen. Aan de andere kant: de providers roepen graag dat "je' van de overgang naar IPv6 niets zal merken. En voor wie geen Tweaker is klopt dat dus. Zelfs voor de IT afdeling van de NOS.

[Snow_King]

Roetzen schreef op donderdag 27 januari 2022 @ 12:01:
[...]

Nadat ik Firefox opnieuw had opgestart krijg ik hier nos.nl ook weer via IPv6.

Mooi dat het opgelost is. Maar wel opmerkelijk dat er een Tweaker aan te pas moest komen. Aan de andere kant: de providers roepen graag dat "je' van de overgang naar IPv6 niets zal merken. En voor wie geen Tweaker is klopt dat dus. Zelfs voor de IT afdeling van de NOS.

Ja, helaas. Maar laten we met zijn allen scherp blijven! Gewoon zeggen dat men 100% moet scoren op internet.nl. Dan is DNSSEC ook direct geregeld.

Heb de NPO ook nog aangegeven IPv6 bij Office365 aan te laten zetten: https://docs.microsoft.co...-ipv6?view=o365-worldwide

[RnB]

@Robvef Ik zag dat jij in december een werkende configuratie op een 60E hebt kunnen krijgen.

Ik heb een werkende situatie gehad op mijn 60F met OS 6.4.8, maar sinds ik over ben naar 7.0.4 krijg ik het niet meer voor elkaar. Althans, deels werkt het niet.

Met de volgende config heeft het dus gewerkt onder 6.4.8:

Config wan1:

code:

config ipv6
    set ip6-mode dhcp
    set dhcp6-prefix-delegation enable
    config dhcp6-iapd-list
        edit 1
            set prefix-hint ::/60
        next
    end
end

Config een van de vlans:

code:

config ipv6
            set ip6-mode delegated
            set ip6-allowaccess ping
            set ip6-delegated-prefix-iaid 1
            set ip6-send-adv enable
            set ip6-manage-flag enable
            set ip6-other-flag enable
            set ip6-upstream-interface "wan1"
            set ip6-subnet ::3:0:0:0:1/64
            config ip6-delegated-prefix-list
                edit 1
                    set upstream-interface "wan1"
                    set subnet 0:0:0:3::/64
                    set rdnss 2a02:xx:xxx:xxx::1
                next
            end
        end

code:

FortiGate_60F # diagnose ipv6 address list
dev=5 devname=wan1 flag=P scope=0 prefix=128 addr=2a02:xx:x:x::xx
dev=5 devname=wan1 flag=P scope=253 prefix=64 addr=fe80::aef2:c5ff:feed:eb83
dev=24 devname=Private Wi-Fi flag= scope=0 prefix=64 addr=2a02:xx:xx:xxxx::1
dev=24 devname=Private Wi-Fi flag=P scope=253 prefix=64 addr=fe80::6d5:90ff:feca:86bd

Mijn subinterfaces krijgen netjes een adres, maar alle clients in dat netwerk doen niets. Ik heb mijn config naast de jouwe gelegd en naast vele andere configs die op het web zijn te vinden en ik zie niet waar het mis gaat.

Met WireShark zie ik de RA's langskomen, maar vanuit mijn clients gebeurd er vrij weinig.

Heb jij (of iemand anders die met een FortiGate meekijkt) nog ideeën?

[Robvef]

Hoi RnB, ik zie dat je bij je WAN-interface een ::/60 hebt neergezet. Volgens mij moet dat een ::/56 zijn toch? Zo is het bij mij thuis in ieder geval wel:

Dus voor je WAN-interface zou het dan de onderstaande code moeten zijn:

code:

config system interface
    edit "wan1"
        config ipv6
            set ip6-mode dhcp
            set dhcp6-prefix-delegation enable
            config dhcp6-iapd-list
                edit 1
                    set prefix-hint ::/56
                next
            end
        end
    next

En voor je vlans moet je eerst even kijk in de GUI naar IPv6 Address/Prefix onder de interface/vlan waar je de wijziging maakt. Het ipv6-adres wat je daar krijg toegewezen vanuit Ziggo moet je dan expliciet vermelden in de CLI (ik pak even een fictief adres)

code:

config ipv6
            set ip6-mode delegated
            set ip6-allowaccess ping
            set ip6-delegated-prefix-iaid 1
            set ip6-send-adv enable
            set ip6-manage-flag enable
            set ip6-other-flag enable
            set ip6-upstream-interface "wan1"
            set ip6-subnet ::3:0:0:0:1/64 
            config ip6-prefix-list
                edit 2a02:1c03:d08:4603::/64
                next
            end
            config ip6-delegated-prefix-list
                edit 1
                    set upstream-interface "wan1"
                    set subnet ::/64
                    set rdnss 2a02:xx:xxx:xxx::1
                next
            end
        end

Heb hiervoor de config van mijn eigen vlan met die ::3:0:0:0:1/64 gepakt en naast die van jou gelegd (heb wel het network gedeelte beetje aangepast)

Ik zou als ik jouw was eerst het gedeelte van je vlans proberen aan te passen. Ik hoor graag of het werkt of niet.

RnB schreef op zondag 30 januari 2022 @ 10:28:
@Robvef Ik zag dat jij in december een werkende configuratie op een 60E hebt kunnen krijgen.

Ik heb een werkende situatie gehad op mijn 60F met OS 6.4.8, maar sinds ik over ben naar 7.0.4 krijg ik het niet meer voor elkaar. Althans, deels werkt het niet.

Met de volgende config heeft het dus gewerkt onder 6.4.8:

Config wan1:

code:

config ipv6
    set ip6-mode dhcp
    set dhcp6-prefix-delegation enable
    config dhcp6-iapd-list
        edit 1
            set prefix-hint ::/60
        next
    end
end

Config een van de vlans:

code:

config ipv6
            set ip6-mode delegated
            set ip6-allowaccess ping
            set ip6-delegated-prefix-iaid 1
            set ip6-send-adv enable
            set ip6-manage-flag enable
            set ip6-other-flag enable
            set ip6-upstream-interface "wan1"
            set ip6-subnet ::3:0:0:0:1/64
            config ip6-delegated-prefix-list
                edit 1
                    set upstream-interface "wan1"
                    set subnet 0:0:0:3::/64
                    set rdnss 2a02:xx:xxx:xxx::1
                next
            end
        end

code:

FortiGate_60F # diagnose ipv6 address list
dev=5 devname=wan1 flag=P scope=0 prefix=128 addr=2a02:xx:x:x::xx
dev=5 devname=wan1 flag=P scope=253 prefix=64 addr=fe80::aef2:c5ff:feed:eb83
dev=24 devname=Private Wi-Fi flag= scope=0 prefix=64 addr=2a02:xx:xx:xxxx::1
dev=24 devname=Private Wi-Fi flag=P scope=253 prefix=64 addr=fe80::6d5:90ff:feca:86bd

Mijn subinterfaces krijgen netjes een adres, maar alle clients in dat netwerk doen niets. Ik heb mijn config naast de jouwe gelegd en naast vele andere configs die op het web zijn te vinden en ik zie niet waar het mis gaat.

Met WireShark zie ik de RA's langskomen, maar vanuit mijn clients gebeurd er vrij weinig.

Heb jij (of iemand anders die met een FortiGate meekijkt) nog ideeën?

[RnB]

Potverdorie @Robvef , ik moet nu inderdaad de prefix die ik vanuit mijn SP krijg, expliciet vermelden in de IPv6 prefix list. Dat hoefde ik onder 6.4.8 niet te doen.

Bedankt voor de tip!

[Keiichi]

In mijn netwerk thuis aak ik gebruik van DNS64/NAT64.

Als ik nu naar pagina's ga om te zien wat mijn v4 en v6 adres zijn, dan geeft ie bij m'n v4 adres, de NAT64 gateway aan.

Ik snap denk ik even niet hoe het nu werkt.. ik dacht dat het IP adres opgehaald werd aan de hand van een v4 geforceerde verbinding, maar blijkbaar toch weer niet.

[Dreamvoid]

Keiichi schreef op maandag 31 januari 2022 @ 16:01:
In mijn netwerk thuis aak ik gebruik van DNS64/NAT64.

Als ik nu naar pagina's ga om te zien wat mijn v4 en v6 adres zijn, dan geeft ie bij m'n v4 adres, de NAT64 gateway aan.

Ik snap denk ik even niet hoe het nu werkt.. ik dacht dat het IP adres opgehaald werd aan de hand van een v4 geforceerde verbinding, maar blijkbaar toch weer niet.

Dat is toch logisch? De IPv4 verbinding begint pas bij de NAT64 gateway, dus websites zullen altijd dat adres detecteren.

[Keiichi]

Dreamvoid schreef op vrijdag 4 februari 2022 @ 12:26:
[...]

Dat is toch logisch? De IPv4 verbinding begint pas bij de NAT64 gateway, dus websites zullen altijd dat adres detecteren.

Maar hoe word je v4 verbinding gemaakt dan? over v6? dat klinkt onlogisch.

Als ik bv met netcat test, krijg ik dit:

code:

# Server
$ nc -n -l -v 1.2.3.4 1234
Connection from 4.3.2.1 45308 received!

# client
$ nc -4 -vz hostname  1234
Connection to 1.2.3.4 1234 port [tcp/*] succeeded!

Dan laat die server mij keurig mijn v4 adres weten.

Hetzelfde voor een webserver van mzelf die ik op v4 aanspreek:

code:

$ curl -4 https://keiichi.vps/mijnip/
4.3.2.1

(php echo $_SERVER['REMOTE_ADDR'] doet ie)

[Brahiewahiewa]

Keiichi schreef op vrijdag 4 februari 2022 @ 14:04:
[...]


Maar hoe word je v4 verbinding gemaakt dan? over v6? dat klinkt onlogisch....

Jouw client maakt over ipv6 verbinding met de NAT64 gateway, à la <prefix>:123:45:67:89. De NAT64 gateway maakt over ip4 een verbinding met de target server. Die target server hoeft niet eens ipv6 aware te zijn, die ziet een inkomende verbinding vanaf het ip4 adres van de NAT64 gateway. Dus dat zal hij terugmelden, desgevraagd

[Keiichi]

Maar waarom word er dan een ipv6 verbinding gemaakt om mijn v4 adres te kunnen ophalen?

Een NAT64 acteert niet uit zichzelf, die werkt samen met DNS(64), die voegt een AAAA record toe vervolgens maak ik een ipv6 verbinding met NAT64prefix::$ipv4stukje en die nat64 proxied de boel door.

Dus als ik een verbinding naar mijn host maak op 1.2.3.4 , dan gaat deze echt niet door de nat64 bak heen

[Brahiewahiewa]

Keiichi schreef op vrijdag 4 februari 2022 @ 14:46:
Maar waarom word er dan een ipv6 verbinding gemaakt om mijn v4 adres te kunnen ophalen?

Een NAT64 acteert niet uit zichzelf, die werkt samen met DNS(64), die voegt een AAAA record toe vervolgens maak ik een ipv6 verbinding met NAT64prefix::$ipv4stukje en die nat64 proxied de boel door.

Dus als ik een verbinding naar mijn host maak op 1.2.3.4 , dan gaat deze echt niet door de nat64 bak heen

Nee. Van een website met ip4 adres 123.45.67.89 maakt DNS64 het adres <prefix>:123:45:67:89
Dus jouw client connect niet met 123.45.67.89 maar met <prefix>:123.45.67.89
De NAT64 gateway vangt dat af, opent zelf een connectie met 123.45.67.89 en sluist de reply's door naar jouw client. Jouw client heeft helemaal geen ip4 adres. Althans, als hij die wel heeft, vraag ik me af waar je dan helemaal mee bezig bent

[Paul]

Keiichi schreef op vrijdag 4 februari 2022 @ 14:46:
Dus als ik een verbinding naar mijn host maak op 1.2.3.4 , dan gaat deze echt niet door de nat64 bak heen

Dan moet je wel IPv4 hebben. En als je IPv4 hebt, vraag ik me af waarom je NAT64en DNS64 hebt...

Zie NAT64 als een soort VPN of proxy voor mensen die zelf geen IPv4 hebben om via die constructie toch een IPv4-adres te kunnen. Als je wel IPv4 (op je internetverbinding, LAN staat hier los van) hebt, dan heb je die constructie helemaal niet nodig.

[Dreamvoid]

Keiichi schreef op vrijdag 4 februari 2022 @ 14:46:
Dus als ik een verbinding naar mijn host maak op 1.2.3.4 , dan gaat deze echt niet door de nat64 bak heen

Hangt ervan af waarin je zit.

Browsers zijn anno 2022 slim genoeg om te zien dat ze in een NAT64/DNS64 omgeving zitten (dmv een DNS request naar ipv4only.arpa, wat een NAT64 prefix teruggeeft), en vervolgens plakken ze uit eigen initiatief de NAT64 prefix voor elk IPv4 adres wat ze tegenkomen in de webpagina of in de adresbalk.

Als je inderdaad handmatig ping 12.34.56.78 in de terminal doet, dan gebeurt dat niet.

[ Voor 8% gewijzigd door Dreamvoid op 04-02-2022 15:36 ]

[zx9r_mario]

Ik ben aan het testen met IPv6 only vpssen. Voor outbound traffic naar IPv4 sites gebruik ik Tayga/Unbound en ndppd voor NAT64/DNS64.

Voor legacy accessproviders zoals TMobile en Caiway gebruik ik nginx om IPv4 te streamen naar de IPv6 servers gebruik ik deze config. Voordeel is dat ik alleen een TLS certificaat op de IPv6 server hoef te zetten.

AAAA record verwijst naar de IPv6 server
A record verwijst naar de IPv4 proxy server



Tot nu toe werkt alles goed

PS Nog een aanvulling voor de nginx proxy server. om http naar https te redirecten:

code:

server {
    listen 80 default_server;

    server_name _;

    return 301 https://$host$request_uri;
}

Voor iedere website moet dus deze aangevuld worden in de nginx config. Het liefst zou ik zien dat nginx automatisch de inkomende URL matched met het IPv6 adres uit het AAAA record. Als iemand ideeën heeft hierover...

[ Voor 31% gewijzigd door zx9r_mario op 07-02-2022 12:19 ]

[supayoshi]

Beste mensen in de IPV6 topic, ik heb sinds gisteren IPV6 enabled op mijn KPN lijn, dat werkt.
Alleen kan ik mijn pihole niet instellen als DNS server op ipv6 omdat de devices in het LAN nu een SLAAC adres krijgen (standaard)

Nu wil ik DHCPv6 gaan gebruiken om de controle terug te krijgen, maar lees dat je hier een /64 voor nodig hebt en KPN slechts een /48 uitdeelt? Hoe nu verder, ik maak gebruik van OPNsense en wil IPV6 graag gebruiken maar wel de DNS server kunnen instellen voor mijn clients tbh

[fvbommel]

supayoshi schreef op donderdag 10 februari 2022 @ 07:59:
Beste mensen in de IPV6 topic, ik heb sinds gisteren IPV6 enabled op mijn KPN lijn, dat werkt.
Alleen kan ik mijn pihole niet instellen als DNS server op ipv6 omdat de devices in het LAN nu een SLAAC adres krijgen (standaard)

Het normale probleem met globale IPv6 adressen is dat als je provider de prefix veranderd, de IPv6-adressen van al je apparaten mee veranderen.

Als het goed is krijgen apparaten trouwens meer dan één adres: op z'n minst krijgen ze een link-local adres, beginnend met 'fe80', wat normaal niet veranderd maar onhandig in het gebruik is omdat de netwerk-interface erbij opgegeven moet worden (gescheiden met een '%'), en die interface apparaat-afhankelijk is.

Verder krijg je één of meer globale adressen, momenteel altijd beginnend met een '2'.

Als ze maar één (globaal) SLAAC adres krijgen is het waarschijnlijk een "modified EUI-64" adres waarbij de laatste 64 bits afgeleid worden van het MAC-adres van de netwerkkaart en dus alleen de prefix kan veranderen. Deze hebben "ff:fe" midden in de laatste 64 bits staan.

De meeste apparaten gebruiken echter niet modified EUI-64 maar zogenaamde privacy adressen, waar van één permanent (zolang de prefix niet verandert tenminste) en 1+ tijdelijk.

Als de prefix niet verandert ben je dus klaar: zet je modified EUI-64 of permanent privacy adres in DNS. Aangenomen je daar niet op wilt vertrouwen heb je ook nog de optie om ULA (Unique Local Addresses) aan te zetten door een apparaat op je netwerk (kan je router zijn als die de optie heeft, maar hoeft niet) een prefix in fd00::/8 (technisch fc00::/7, maar de eerste helft is reserved) aan te laten kondigen. Omdat je deze prefix zelf onder controle hebt, kun je garanderen dat deze niet verandert. Je apparaten geven zichzelf dan óók 1 of meer adressen uit deze prefix, en die kun je gewoon in je lokale DNS opnemen. (Ze zullen de provider-adressen nog steeds gebruiken om met het Internet te praten, want daarvoor zijn ULA-adressen niet bruikbaar) Als je meerdere lokale subnetten hebt kun je daarop verschillende ULA-prefixes aankondigen (liefst met de eerste 48 bits hetzelfde, als ik me goed herinner).

Er zijn ook routers die zelf een lokale DNS-naam (gebaseerd op hostnames) geeft aan alle apparaten (mijn Fritz!Box geeft ieder apparaat bijvoorbeeld "hostname.fritz.box", al kan je die hostname nog aanpassen). Eventueel kun je in de pihole daar misschien zelfs CNAME records naar aanmaken.

Als laatste redmiddel kun je in het lokale DNS gewoon ouderwets alleen IPv4-adressen zetten natuurlijk, dat blijft voorlopig prima werken...

supayoshi schreef op donderdag 10 februari 2022 @ 07:59:
Nu wil ik DHCPv6 gaan gebruiken om de controle terug te krijgen, maar lees dat je hier een /64 voor nodig hebt en KPN slechts een /48 uitdeelt? Hoe nu verder, ik maak gebruik van OPNsense en wil IPV6 graag gebruiken maar wel de DNS server kunnen instellen voor mijn clients tbh

Er lijkt hier een misverstand te bestaan: een /48 is 65536x groter dan een /64: bij een /48 staan de eerste 48 (van de 128) bits vast, bij een /64 de eerste 64.

Als KPN je een /48 geeft zal je router voor het lokale netwerk daaruit een /64 selecteren.

[ Voor 6% gewijzigd door fvbommel op 10-02-2022 08:54 ]

[ed1703]

supayoshi schreef op donderdag 10 februari 2022 @ 07:59:
Beste mensen in de IPV6 topic, ik heb sinds gisteren IPV6 enabled op mijn KPN lijn, dat werkt.
Alleen kan ik mijn pihole niet instellen als DNS server op ipv6 omdat de devices in het LAN nu een SLAAC adres krijgen (standaard)

Nu wil ik DHCPv6 gaan gebruiken om de controle terug te krijgen, maar lees dat je hier een /64 voor nodig hebt en KPN slechts een /48 uitdeelt? Hoe nu verder, ik maak gebruik van OPNsense en wil IPV6 graag gebruiken maar wel de DNS server kunnen instellen voor mijn clients tbh

Ik heb zoals @fvbommel al aangeeft als mogelijkheid uit een fd00::/8 een /64 gemaakt op m'n router en daarin heb ik een vast adres fd00:12::53:1/128 adres gemaakt op m'n Pi-Hole, waarbij 12 het vlan-id is.

[RnB]

fvbommel schreef op donderdag 10 februari 2022 @ 08:42:
[...]


Het normale probleem met globale IPv6 adressen is dat als je provider de prefix veranderd, de IPv6-adressen van al je apparaten mee veranderen.

Als het goed is krijgen apparaten trouwens meer dan één adres: op z'n minst krijgen ze een link-local adres, beginnend met 'fe80', wat normaal niet veranderd maar onhandig in het gebruik is omdat de netwerk-interface erbij opgegeven moet worden (gescheiden met een '%'), en die interface apparaat-afhankelijk is.

Verder krijg je één of meer globale adressen, momenteel altijd beginnend met een '2'.

Als ze maar één (globaal) SLAAC adres krijgen is het waarschijnlijk een "modified EUI-64" adres waarbij de laatste 64 bits afgeleid worden van het MAC-adres van de netwerkkaart en dus alleen de prefix kan veranderen. Deze hebben "ff:fe" midden in de laatste 64 bits staan.

De meeste apparaten gebruiken echter niet modified EUI-64 maar zogenaamde privacy adressen, waar van één permanent (zolang de prefix niet verandert tenminste) en 1+ tijdelijk.

Als de prefix niet verandert ben je dus klaar: zet je modified EUI-64 of permanent privacy adres in DNS. Aangenomen je daar niet op wilt vertrouwen heb je ook nog de optie om ULA (Unique Local Addresses) aan te zetten door een apparaat op je netwerk (kan je router zijn als die de optie heeft, maar hoeft niet) een prefix in fd00::/8 (technisch fc00::/7, maar de eerste helft is reserved) aan te laten kondigen. Omdat je deze prefix zelf onder controle hebt, kun je garanderen dat deze niet verandert. Je apparaten geven zichzelf dan óók 1 of meer adressen uit deze prefix, en die kun je gewoon in je lokale DNS opnemen. (Ze zullen de provider-adressen nog steeds gebruiken om met het Internet te praten, want daarvoor zijn ULA-adressen niet bruikbaar) Als je meerdere lokale subnetten hebt kun je daarop verschillende ULA-prefixes aankondigen (liefst met de eerste 48 bits hetzelfde, als ik me goed herinner).

Er zijn ook routers die zelf een lokale DNS-naam (gebaseerd op hostnames) geeft aan alle apparaten (mijn Fritz!Box geeft ieder apparaat bijvoorbeeld "hostname.fritz.box", al kan je die hostname nog aanpassen). Eventueel kun je in de pihole daar misschien zelfs CNAME records naar aanmaken.

Als laatste redmiddel kun je in het lokale DNS gewoon ouderwets alleen IPv4-adressen zetten natuurlijk, dat blijft voorlopig prima werken...

Mooie uitleg @fvbommel !
Als je dit nu extrapoleert naar firewall rules of ACL's, hoe zou je dan te werk gaan in combinatie met de privacy adressen?

Ik heb eens nagedacht over wat als ik mijn rules wil hardenen door ze op host ipv subnet/prefix te creëren, hoe ga ik dat doen met het tijdelijke en permanente privacy adres? Ik liep tegen hetzelfde aan met mijn interne DNS, ik zie geen mogelijkheid om de database te vullen, omdat het adres steeds wijzigt.

In mijn traffic logs zie ik nooit het permanente privacy adres voorbij komen, altijd het dynamische adres. Ik heb daaruit de conclusie gekomen dat voor outgoing verkeer, altijd het dynamische adres wordt gebruikt en dat je voor incoming verkeer het permanente adres kunt gebruiken. Dat is een + voor mijn DNS database, maar what about mijn firewall rules en ACL's?

Zeer benieuwd naar jouw visie hierop.

[fvbommel]

RnB schreef op donderdag 10 februari 2022 @ 09:04:
Als je dit nu extrapoleert naar firewall rules of ACL's, hoe zou je dan te werk gaan in combinatie met de privacy adressen?

Ik heb eens nagedacht over wat als ik mijn rules wil hardenen door ze op host ipv subnet/prefix te creëren, hoe ga ik dat doen met het tijdelijke en permanente privacy adres? Ik liep tegen hetzelfde aan met mijn interne DNS, ik zie geen mogelijkheid om de database te vullen, omdat het adres steeds wijzigt.

Eerlijk gezegd gebruik ik IPv6 alleen op mijn thuisnetwerk, het klinkt alsof jij op iets grotere schaal bezig bent.

RnB schreef op donderdag 10 februari 2022 @ 09:04:
In mijn traffic logs zie ik nooit het permanente privacy adres voorbij komen, altijd het dynamische adres. Ik heb daaruit de conclusie gekomen dat voor outgoing verkeer, altijd het dynamische adres wordt gebruikt en dat je voor incoming verkeer het permanente adres kunt gebruiken. Dat is een + voor mijn DNS database, maar what about mijn firewall rules en ACL's?

Het tijdelijke adres is inderdaad bedoeld voor uitgaand verkeer en het permanente voor inkomend verkeer.

Hoe het met de firewall en zo moet weet ik eigenlijk niet, ik heb zelf ook pas sinds kort IPv6 en heb nog geen prefix-wijziging hoeven overleven.

Wel kan ik zien dat mijn routertje (bovengenoemde Fritz!Box) meerdere adressen voor ieder apparaat kent, en van de apparaten waar ik het verschil zie zit daar ook het permanente adres tussen. Waarschijnlijk door duplicate address detection messages te onthouden (en te sorteren op MAC-adres)? Maar er staat geen indicatie van lifetime bij, dus het lijkt er niet op dat hij wéét welke permanent zijn en welke niet...

[Snow_King]

RnB schreef op donderdag 10 februari 2022 @ 09:04:
[...]


Mooie uitleg @fvbommel !
Als je dit nu extrapoleert naar firewall rules of ACL's, hoe zou je dan te werk gaan in combinatie met de privacy adressen?

Ik heb eens nagedacht over wat als ik mijn rules wil hardenen door ze op host ipv subnet/prefix te creëren, hoe ga ik dat doen met het tijdelijke en permanente privacy adres? Ik liep tegen hetzelfde aan met mijn interne DNS, ik zie geen mogelijkheid om de database te vullen, omdat het adres steeds wijzigt.

In mijn traffic logs zie ik nooit het permanente privacy adres voorbij komen, altijd het dynamische adres. Ik heb daaruit de conclusie gekomen dat voor outgoing verkeer, altijd het dynamische adres wordt gebruikt en dat je voor incoming verkeer het permanente adres kunt gebruiken. Dat is een + voor mijn DNS database, maar what about mijn firewall rules en ACL's?

Zeer benieuwd naar jouw visie hierop.

Je hebt het bij het juiste eind. Outbound (en related) zal altijd het privacy adres zijn.

Maar wat wil je precies bereiken? Ik heb een aantal hosts een static adres gegeven in mijn netwerk en daar heb ik specifieke poorten naar open gezet.

Verder staat alles behalve ICMPv6 dicht naar binnen toe. 22, 80 en 443 staat dan weer open naar een paar servers (groot woord) die ik thuis draai.

Ik heb ook wel eens iemand gezien die SLAAC uit heeft gezet in zijn netwerk en DHCPv6 gebruikt voor adres uitgifte en dan op basis van de DHCP lease database zijn firewall automatisch configureerd.

Daar heb je echter wel de uitdaging dat adresuitgifte met DHCPv6 zijn beperkingen kent (Android anyone?)

[RnB]

@Snow_King Tja, wat wil ik ermee bereiken? Eigenlijk wil ik er alleen maar van leren, ervaring ermee opdoen. Ik heb geen servers draaien die van buitenaf bereikbaar moeten zijn, gewoon een gesegmenteerd thuisnetwerk waar ik continu bezig ben om alles nog vaster te draaien dan dat het al is.

Nu dus mijn regels op prefix aangemaakt en ben dus benieuwd hoe ik dit strakker kan krijgen door ze op host basis aan te maken. Erg lastig met dynamische adressen. Met statische adressen werken is een oplossing, maar dat zie ik niet zitten. SLAAC werkt goed en simpel.

fvbommel schreef op donderdag 10 februari 2022 @ 09:22:
[...]


Eerlijk gezegd gebruik ik IPv6 alleen op mijn thuisnetwerk, het klinkt alsof jij op iets grotere schaal bezig bent.


[...]


Het tijdelijke adres is inderdaad bedoeld voor uitgaand verkeer en het permanente voor inkomend verkeer.

Hoe het met de firewall en zo moet weet ik eigenlijk niet, ik heb zelf ook pas sinds kort IPv6 en heb nog geen prefix-wijziging hoeven overleven.

Wel kan ik zien dat mijn routertje (bovengenoemde Fritz!Box) meerdere adressen voor ieder apparaat kent, en van de apparaten waar ik het verschil zie zit daar ook het permanente adres tussen. Waarschijnlijk door duplicate address detection messages te onthouden (en te sorteren op MAC-adres)? Maar er staat geen indicatie van lifetime bij, dus het lijkt er niet op dat hij wéét welke permanent zijn en welke niet...

Nee hoor, ook een thuisnetwerkje hier.
Maar ik heb tijdens kantooruren niet zoveel uitdaging, dus probeer ik die thuis maar te vinden.
Ik heb een FortiGate 60F die ik van binnen en buiten ken, maar ik ben dus ook net met IPv6 bezig en de gedachtes erachter zijn toch wel anders dan bij IPv4.

[Keiichi]

Ik blijf gebeten worden door ipv6 only servers. Heb een aantal productie servers en op een el-cheapo vps provider een VPS met zabbix erop voor monitoring. zabbix proxies en hosts/vm's die alleen intern worden gebruikt, hebben alleen IPv6.

Maar nu op de een of andere manier werkt alles, ipv4 geen probleem. ipv6 van m'n productie servers naar alles, ipv6 van die vm naar overal, BEHALVE ipv6 tussen die m'n productie servers en de zabbix... zucht... (waarschijnlijk peering issue omdat traceroutes in loops blijven hangen).

Begin haast te denken dat ik geen ipv6 mag hebben