Het grote IPv6 topic

[valkenier]

nero355 schreef op zaterdag 26 februari 2022 @ 00:03:
[...]

Noem dan effe enkele voorbeelden waarvan jij zeker weet dat ze goed werken, want in de meeste gevallen zullen WAN + LAN 1 met elkaar gebridged zijn en zijn alle andere poorten nutteloos...

Ik snap niet wat je bedoelt. Het is zoals ik zei.

[mindwarper]

Ik zie dat in je router advertisement other config flag en evt. managed config flag op false hebt staan...
Misschien die op enabled laten...

Maar het is een gok

[r3mi]

arjans schreef op donderdag 10 februari 2022 @ 15:47:
Update over Delta Fiber Netwerk: gisteren met de helpdesk gesproken omdat zij in mijn woonplaats ook glasvezel gaan aanleggen (bij >20% inschrijving) met alleen de eerder genoemde 4 providers erop. De helpdeskmedewerker gaf aan dat IPv6 er voorlopig nog niet aan zit te komen, maar hij durfde wel een hele grove schatting te geven: "over een jaar ofzo".

Ik had juist het tegenovergestelde, had in januari contact met support van Delta en die wist mij te vertellen dat het in het eerste half jaar van 2022 zou komen.

[Maurits van Baerle]

Dit is wel een aardig artikel, over hoe één EUI-64 adres de privacy van je hele netwerk om zeep kan helpen. Het is een beetje in de categorie 'da's toch logisch', maar je moet er wel even bij stil staan.

How legacy IPv6 addresses can spoil your network privacy

[Roetzen]

Maurits van Baerle schreef op dinsdag 22 maart 2022 @ 11:33:
Dit is wel een aardig artikel, over hoe één EUI-64 adres de privacy van je hele netwerk om zeep kan helpen. Het is een beetje in de categorie 'da's toch logisch', maar je moet er wel even bij stil staan.

How legacy IPv6 addresses can spoil your network privacy

Het zal wel ja. Maar ik zie niet in hoe dit nu "erger" is dan tracken aan de hand van IPv4 adressen. "Ze" hebben toch al lange manieren gevonden om je te tracken ondanks een dynamisch IPv4 adres? Beetje paniekverhaal.

Dat hele gedoe met privacy extensions geeft sowieso een vals gevoel van veiligheid wanneer het gebruikt wordt op een vaste aansluiting. Het is bedoeld voor gevallen waarbij je met een laptop de wereld rondreist en steeds bij een ander netwerk (met dus een andere IPv6 prefix) inlogt. Dan kan je niet op MAC adres gevolgd worden. Maar dat is het dan.

[ Voor 20% gewijzigd door Roetzen op 22-03-2022 14:12 ]

[Dreamvoid]

Privacy extenstions hebben wel degelijk nut: je prefix is weliswaar telkens hetzelfde, maar het adres niet, en het voorkomt zo dat aanvallers databases kunnen aanleggen met IP adressen waar ze later op terug kunnen komen als er een nieuwe exploit is gevonden. Met 24u wisselende adressen zijn dat soort databases waardeloos.

Verder is dat EUI-64 artikel een beetje paniekzaaierij idd, in 99.9% van de gevallen hangen die IoT devices achter een firewall, en dat je prefix over tijd aan jou gelinkt wordt is ook al lang bekend (en idd niet anders als bij IPv4).

[ Voor 26% gewijzigd door Dreamvoid op 23-03-2022 09:43 ]

[Roetzen]

@Dreamvoid
Dat wel, maar het artikel ging over privacy, niet over exploits.

[Dreamvoid]

Privacy is inderdaad hetzelfde als bij IPv4. Je huishouden is herkenbaar aan je prefix. Is voor een deel een goede zaak (IP-bans op gameservers bijvoorbeeld zijn zinloos voor individuele IPv6 adressen, prefix-bans wel), maar idd voor tracking niet.

[nero355]

Dreamvoid schreef op donderdag 24 maart 2022 @ 08:55:
Je huishouden is herkenbaar aan je prefix.

Is voor een deel een goede zaak (IP-bans op gameservers bijvoorbeeld zijn zinloos voor individuele IPv6 adressen, prefix-bans wel)

Mja, de vraag is hoe toepasselijk dat nog zal zijn in de toekomst sinds heel veel games over zijn gegaan op P2P toestanden i.p.v. Dedicated Servers

Om over ISP's die de IPv6 Prefix straks net zo dynamisch als het IPv4 adres gaan toewijzen maar te zwijgen...

[Dreamvoid]

Goed, maar die situatie is niet anders dan met IPv4.

[CeesBak]

Hoi Allen,
Ik heb een probleem met IPv6 op mijn Ubuntue 20.04.4 server waar NextCloud op draait. Heb 6 weken geleden mijn routers vervangen door MikroTik apparatuur. Inmiddels heb ik alles aan de praat, d.w.z. op de Ubuntu server na. Windows geeft met testipv6 en met http://test-ipv6.com/ en https://ipv6-test.com/ krijg ik 100% goede score op een Windows 10 machine.

Mijn Ubuntu/NextCloud server heeft ook een IPv6 adres toegewezen gekregen en door de firewall van de router aan te passen kan ik er van buiten zowel met IPv6 als met IPv4 bereiken, mooi!

Het is alleen dat er vertragingen optreden in de communicatie. Soms moet ik tot twee minuten wachten tot er een reactie komt van de Ubuntu server. Ik heb al zitten stoeien met het Netplan configuratie bestand via SSH op ipv4 en SSH op IPv6 wat weer prima werkt.. Maak je een foutje in het Netplan configuratiebestand dan ben je je communicatie via SSH kwijt en kan je niet meer naar je server. Beeldscherm en keyboard aansluiten is dan de enige optie.

Iemand een idee?

[valkenier]

CeesBak schreef op woensdag 30 maart 2022 @ 12:40:
Hoi Allen,
Ik heb een probleem met IPv6 op mijn Ubuntue 20.04.4 server waar NextCloud op draait. Heb 6 weken geleden mijn routers vervangen door MikroTik apparatuur. Inmiddels heb ik alles aan de praat, d.w.z. op de Ubuntu server na. Windows geeft met testipv6 en met http://test-ipv6.com/ en https://ipv6-test.com/ krijg ik 100% goede score op een Windows 10 machine.

Mijn Ubuntu/NextCloud server heeft ook een IPv6 adres toegewezen gekregen en door de firewall van de router aan te passen kan ik er van buiten zowel met IPv6 als met IPv4 bereiken, mooi!

Het is alleen dat er vertragingen optreden in de communicatie. Soms moet ik tot twee minuten wachten tot er een reactie komt van de Ubuntu server. Ik heb al zitten stoeien met het Netplan configuratie bestand via SSH op ipv4 en SSH op IPv6 wat weer prima werkt.. Maak je een foutje in het Netplan configuratiebestand dan ben je je communicatie via SSH kwijt en kan je niet meer naar je server. Beeldscherm en keyboard aansluiten is dan de enige optie.

Iemand een idee?

Kun je iets specifieker zijn over "vertragingen in de communicatie"?

[borft]

CeesBak schreef op woensdag 30 maart 2022 @ 12:40:
Hoi Allen,
Ik heb een probleem met IPv6 op mijn Ubuntue 20.04.4 server waar NextCloud op draait. Heb 6 weken geleden mijn routers vervangen door MikroTik apparatuur. Inmiddels heb ik alles aan de praat, d.w.z. op de Ubuntu server na. Windows geeft met testipv6 en met http://test-ipv6.com/ en https://ipv6-test.com/ krijg ik 100% goede score op een Windows 10 machine.

Mijn Ubuntu/NextCloud server heeft ook een IPv6 adres toegewezen gekregen en door de firewall van de router aan te passen kan ik er van buiten zowel met IPv6 als met IPv4 bereiken, mooi!

Het is alleen dat er vertragingen optreden in de communicatie. Soms moet ik tot twee minuten wachten tot er een reactie komt van de Ubuntu server. Ik heb al zitten stoeien met het Netplan configuratie bestand via SSH op ipv4 en SSH op IPv6 wat weer prima werkt.. Maak je een foutje in het Netplan configuratiebestand dan ben je je communicatie via SSH kwijt en kan je niet meer naar je server. Beeldscherm en keyboard aansluiten is dan de enige optie.

Iemand een idee?

Hmm op zowel mijn Debian server, als Ubuntu workstation heb ik niets specifiek hoeven instellen om ipv6 te laten werken, dus ben benieuwd wat jij aangepast hebt.

Daarnaast wil ik je aanraden ook een firewall op je server te draaien (zeker als je verkeer gaat doorlaten op je router)

[nero355]

CeesBak schreef op woensdag 30 maart 2022 @ 12:40:
Het is alleen dat er vertragingen optreden in de communicatie.

Soms moet ik tot twee minuten wachten tot er een reactie komt van de Ubuntu server. Ik heb al zitten stoeien met het Netplan configuratie bestand via SSH op ipv4 en SSH op IPv6 wat weer prima werkt...

Iemand een idee?

Klinkt als Reverse DNS Lookup van SSH die de boel vertraagt, maar misschien bedoel je wat anders dus inderdaad :

valkenier schreef op woensdag 30 maart 2022 @ 14:23:
Kun je iets specifieker zijn over "vertragingen in de communicatie"?

[PhilipsFan]

Is het echt zo erg met IPv6 of heb ik iets nog niet goed staan?

Situatie: Ziggo modem in bridgemode (voormalig Ziggo gebied), Unifi UDM erachter. Net op de UDM ingesteld dat hij IPv6 moet gebruiken (samen met IPv4) dus heb nu een dualstack verbinding, de UDM geeft aan dat hij zowel een IPv4 als een IPv6 adres krijgt. Als ik op mijn laptop naar whatismyip.com ga, dan krijg ik te zien dat ik zowel een IPv4 als een IPv6 extern IP-adres heb. So far so good.

Nu heb ik (om uit te proberen) even IPv4 uitgeschakeld in de instellingen van mijn NIC op de laptop. Ik heb nu alleen via IPv6 internetconnectie. Maar veel sites zijn nu niet bereikbaar. Tweakers doet het wel, Google ook, maar veel sites doen het niet. IMDB, Reddit, nu.nl, zelfs de site van Ziggo en Duckduckgo doen het niet. Betekent dat nu dat al die sites nog niet bereikbaar zijn via IPv6? Of heb ik iets nog niet goed ingesteld?

En hoe bereik ik m'n eigen router via IPv6? Als ik het IPv6 adres van de gateway invoer (uit de properties van de netwerkverbinding) dan schiet ie me door naar Google...

[ Voor 12% gewijzigd door PhilipsFan op 31-03-2022 19:15 ]

[Roetzen]

PhilipsFan schreef op donderdag 31 maart 2022 @ 19:09:
Is het echt zo erg met IPv6 of heb ik iets nog niet goed staan?

Situatie: Ziggo modem in bridgemode (voormalig Ziggo gebied), Unifi UDM erachter. Net op de UDM ingesteld dat hij IPv6 moet gebruiken (samen met IPv4) dus heb nu een dualstack verbinding, de UDM geeft aan dat hij zowel een IPv4 als een IPv6 adres krijgt. Als ik op mijn laptop naar whatismyip.com ga, dan krijg ik te zien dat ik zowel een IPv4 als een IPv6 extern IP-adres heb. So far so good.

Inderdaad, so far so good. Vermoedelijk heb je ook een goede score op https://ipv6-test.com/

Nu heb ik (om uit te proberen) even IPv4 uitgeschakeld in de instellingen van mijn NIC op de laptop. Ik heb nu alleen via IPv6 internetconnectie. Maar veel sites zijn nu niet bereikbaar. Tweakers doet het wel, Google ook, maar veel sites doen het niet. IMDB, Reddit, nu.nl, zelfs de site van Ziggo en Duckduckgo doen het niet. Betekent dat nu dat al die sites nog niet bereikbaar zijn via IPv6? Of heb ik iets nog niet goed ingesteld?

Het ligt niet aan je instellingen. Veel sites zijn helaas nog steeds niet via IPv6 bereikbaar.

[jvhaarst]

Het lijkt er op dat Ziggo aan het testen is om hier (fUPC) gebied IPv6 uit te rollen (of iemand heeft een foutje gemaakt).
Mijn Fritz!Box (achter een bridged modem) kreeg vanmorgen een IPv6 adres, en ook een paar hosts kregen een adres :

Nu is alles weer alleen IPv4, ik heb alleen een ander IPv4 adres dan voorheen.

[ReBr]

PhilipsFan schreef op donderdag 31 maart 2022 @ 19:09:
Is het echt zo erg met IPv6 of heb ik iets nog niet goed staan?

Situatie: Ziggo modem in bridgemode (voormalig Ziggo gebied), Unifi UDM erachter. Net op de UDM ingesteld dat hij IPv6 moet gebruiken (samen met IPv4) dus heb nu een dualstack verbinding, de UDM geeft aan dat hij zowel een IPv4 als een IPv6 adres krijgt. Als ik op mijn laptop naar whatismyip.com ga, dan krijg ik te zien dat ik zowel een IPv4 als een IPv6 extern IP-adres heb. So far so good.

Nu heb ik (om uit te proberen) even IPv4 uitgeschakeld in de instellingen van mijn NIC op de laptop. Ik heb nu alleen via IPv6 internetconnectie. Maar veel sites zijn nu niet bereikbaar. Tweakers doet het wel, Google ook, maar veel sites doen het niet. IMDB, Reddit, nu.nl, zelfs de site van Ziggo en Duckduckgo doen het niet. Betekent dat nu dat al die sites nog niet bereikbaar zijn via IPv6? Of heb ik iets nog niet goed ingesteld?

En hoe bereik ik m'n eigen router via IPv6? Als ik het IPv6 adres van de gateway invoer (uit de properties van de netwerkverbinding) dan schiet ie me door naar Google...

Als je via een webbrowser de webinterface wil benaderen, moet je volgens mij het ipv6 adres tussen [ ] zetten, zoals bv

https://[ipv6 adres router]:443

Zo benader ik iig al mn spulletjes thuis, vanaf externe locatie, via ipv6

[PhilipsFan]

ReBr schreef op donderdag 31 maart 2022 @ 21:42:
[...]


Als je via een webbrowser de webinterface wil benaderen, moet je volgens mij het ipv6 adres tussen [ ] zetten, zoals bv

https://[ipv6 adres router]:443

Zo benader ik iig al mn spulletjes thuis, vanaf externe locatie, via ipv6

Held! Dat werkt inderdaad. Zoiets zou in elke startpost over IPv6 moeten staan, want ik heb werkelijk alles geprobeerd. Ook die belachelijke % die Windows in de link-local adressen zet, lijkt daar alleen maar voor de vorm te staan. Als je het weglaat kun je het apparaat gewoon benaderen, als je het erin zet snapt de webbrowser niet dat het een IPv6 adres is.

Ik vind IPv6 toch slecht opgezet. Het biedt veel meer mogelijkheden voor tracking, want de server waar ik naartoe connect kan nu ook de computers in mijn lokale netwerk onderscheiden. Mijn iPhone krijgt een ander extern IPv6 nummer dan mijn laptop, dat wil ik niet. Ik denk dat ik het dus maar weer uit zet. Ik wil gewoon NAT voor IPv6.

Ook al die IPv6 guru's die beweren dat het net zo veilig is als NAT, omdat je je firewall op je router gewoon goed moet instellen, die hebben ongelijk. NAT is inherent veilig, want een inkomende connectie KAN gewoon nergens heen. Maar met IPv6 weet een hacker zelfs het interne IPv6 nummer van mijn devices (bijvoorbeeld als ik eerder naar zijn webserver heb geconnect). Met een werkende firewall op de router is dat nog steeds geen probleem, maar als je die per ongeluk uitzet heeft de hele wereld dus directe toegang tot al je interne devices. Dat is gewoon niet veilig, hoe je het ook wendt of keert. NAT is niet bedoeld als beveiliging, maar het werkt wel als zodanig, zeer effectief zelfs. Met IPv6 wordt dat er dus tussenuit gesloopt.

[nero355]

PhilipsFan schreef op donderdag 31 maart 2022 @ 19:09:
En hoe bereik ik m'n eigen router via IPv6? Als ik het IPv6 adres van de gateway invoer (uit de properties van de netwerkverbinding) dan schiet ie me door naar Google...

Klinkt als Google Chrome die je als browser gebruikt

Dat is sowieso een slechte browser voor de beheer van je eigen spulletjes en al helemaal via een eigen Intern Domein zonder allerlei chrome://flags dingen te slopen, zoals A-Sync DNS en zo...

Wat dat betreft zijn er maar twee keuzes die ik als de juiste beschouw :
- Pale Moon
- Firefox

En dan in die volgorde!

[Jef61]

PhilipsFan schreef op donderdag 31 maart 2022 @ 22:27:
[...]
Ik wil gewoon NAT voor IPv6.

Ik ben opgegroeid in de tijd dat er nog geen NAT was, je kreeg gewoon publieke adressen voor je device's (wel 3 stuks ), je had dus een firewall nodig. Vanwege IP-nummer gebrek kwam toen dat vreselijk NAT , end-to-end connectiviteit kapot, protocollen die niet meer goed werkten, getruuk met port-forwarding.

En nu is er weer end-to-end connectiviteit met IPv6. Alle servers bereikbaar op poort 443 zonder gedoe met reverse-proxy oid... Heerlijk dat IPv6 er is/komt...

Uiteraard wel je firewall juist instellen (waarvoor die bedoeld is).

[PhilipsFan]

nero355 schreef op donderdag 31 maart 2022 @ 23:19:
[...]

Klinkt als Google Chrome die je als browser gebruikt

Dat is sowieso een slechte browser voor de beheer van je eigen spulletjes en al helemaal via een eigen Intern Domein zonder allerlei chrome://flags dingen te slopen, zoals A-Sync DNS en zo...

Wat dat betreft zijn er maar twee keuzes die ik als de juiste beschouw :
- Pale Moon
- Firefox

En dan in die volgorde!

Ik gebruik Firefox, maar die schiet je term ook gewoon door naar Google (of een andere ingestelde zoeksite) als hij niet begrijpt dat het een webadres is. Maar met de [] werkt het inmiddels correct.

Jef61 schreef op donderdag 31 maart 2022 @ 23:48:
[...]

Ik ben opgegroeid in de tijd dat er nog geen NAT was, je kreeg gewoon publieke adressen voor je device's (wel 3 stuks ), je had dus een firewall nodig. Vanwege IP-nummer gebrek kwam toen dat vreselijk NAT , end-to-end connectiviteit kapot, protocollen die niet meer goed werkten, getruuk met port-forwarding.

En nu is er weer end-to-end connectiviteit met IPv6. Alle servers bereikbaar op poort 443 zonder gedoe met reverse-proxy oid... Heerlijk dat IPv6 er is/komt...

Uiteraard wel je firewall juist instellen (waarvoor die bedoeld is).

Als je servers beheert is het een vooruitgang. Ik zal eens kijken of ik mijn Wireguard servers ook via IPv6 kan bereiken, dan heb ik geen port forwarding meer nodig en zelfs geen dynamic dns, want je IP-adres verandert toch nooit bij Ziggo. Maar als je servers beheert heb je meestal ook wel verstand van zaken en weet je ook hoe je een firewall moet inrichten. Voor de particulier maakt NAT helemaal niks uit. Mobiele dataverbindingen doen niet anders. Maar het punt van tracking van devices bij IPv6 heb je daarmee nog niet ondervangen.

[Muis666]

PhilipsFan schreef op vrijdag 1 april 2022 @ 00:48:
[...]
Voor de particulier maakt NAT helemaal niks uit. Mobiele dataverbindingen doen niet anders. Maar het punt van tracking van devices bij IPv6 heb je daarmee nog niet ondervangen.

Daarvoor zijn IPv6 privacy extensions https://cryptomonkeys.com/2013/02/privacy-extensions/ bedacht.

[borft]

PhilipsFan schreef op donderdag 31 maart 2022 @ 22:27:
[...]


Ook al die IPv6 guru's die beweren dat het net zo veilig is als NAT, omdat je je firewall op je router gewoon goed moet instellen, die hebben ongelijk. NAT is inherent veilig, want een inkomende connectie KAN gewoon nergens heen.

Jij bent af. Er zijn tal van mogelijkheden waardoor connecties prima door je NAT heengaan. NAT is een hack om het gebrek aan adresruimte op te lossen voor IPv4. Het is zeker geen security feature, en al helemaal niet inherent veilig.

[Snow_King]

PhilipsFan schreef op donderdag 31 maart 2022 @ 22:27:
[...]

Held! Dat werkt inderdaad. Zoiets zou in elke startpost over IPv6 moeten staan, want ik heb werkelijk alles geprobeerd. Ook die belachelijke % die Windows in de link-local adressen zet, lijkt daar alleen maar voor de vorm te staan. Als je het weglaat kun je het apparaat gewoon benaderen, als je het erin zet snapt de webbrowser niet dat het een IPv6 adres is.

Ik vind IPv6 toch slecht opgezet. Het biedt veel meer mogelijkheden voor tracking, want de server waar ik naartoe connect kan nu ook de computers in mijn lokale netwerk onderscheiden. Mijn iPhone krijgt een ander extern IPv6 nummer dan mijn laptop, dat wil ik niet. Ik denk dat ik het dus maar weer uit zet. Ik wil gewoon NAT voor IPv6.

Ook al die IPv6 guru's die beweren dat het net zo veilig is als NAT, omdat je je firewall op je router gewoon goed moet instellen, die hebben ongelijk. NAT is inherent veilig, want een inkomende connectie KAN gewoon nergens heen. Maar met IPv6 weet een hacker zelfs het interne IPv6 nummer van mijn devices (bijvoorbeeld als ik eerder naar zijn webserver heb geconnect). Met een werkende firewall op de router is dat nog steeds geen probleem, maar als je die per ongeluk uitzet heeft de hele wereld dus directe toegang tot al je interne devices. Dat is gewoon niet veilig, hoe je het ook wendt of keert. NAT is niet bedoeld als beveiliging, maar het werkt wel als zodanig, zeer effectief zelfs. Met IPv6 wordt dat er dus tussenuit gesloopt.

Sorry, maar ik denk echt dat je een aantal fundamenten van routing en firewalling niet begrijpt.

Mijn iPhone durf ik gewoon een publiek IPv4/IPv6 adres te geven, succes met scannen. Beveiliging begint niet bij je firewall/router, maar al op het device.

NAT is echt een van slechtste dingen die het internet ooit gezien heeft en nog steeds ziet. Dat geklooi met die RFC1918 (10.0.0.x, etc) IP adresjes is echt een heel gedoe als je echte netwerken draait.

Je kan IPv6 uiteraard uit zetten, maar je kan ook NAT toepassen met IPv6 als je daar echt blij van wordt. Beide zijn echter een reactie op het niet begrijpen van de materie en daardoor op die manier er op reageren.

En tracking, daar is je IP(v6) adres allang niet meer voor nodig. We hebben cookies, tcp fingerprinting, dns verzoeken, ga zo maar door. Veel meer dingen dan je IP-adres waarmee je getracked kan worden.

[PhilipsFan]

Snow_King schreef op vrijdag 1 april 2022 @ 10:56:
[...]

Sorry, maar ik denk echt dat je een aantal fundamenten van routing en firewalling niet begrijpt.

Mijn iPhone durf ik gewoon een publiek IPv4/IPv6 adres te geven, succes met scannen. Beveiliging begint niet bij je firewall/router, maar al op het device.

Bij een iPhone is dat inderdaad wel prima, die zijn goed dichtgetimmerd en worden regelmatig voorzien van updates. Maar ik heb ook veel devices in huis waar dat niet voor geldt. 'Security' camera's bijvoorbeeld, die hebben best een lange levensduur maar krijgen al snel geen updates meer, en draaien toch een volledige Linux. Mijn eigen Windows server, waar een verouderde Apache op draait en de oude versie van SMB/CIFS. Ik ben dan toch wel blij dat die dingen achter NAT zitten, want als dat niet zo was waren ze binnen notime gehacked.

Natuurlijk zou je het probleem op de juiste manier moeten oplossen. Maar in mijn geval zou dat dus betekenen dat ik om de 2 jaar nieuwe camera's moet kopen (plus het inregelwerk wat daarbij hoort, zoals het aanpassen van de apps en configuraties van alles wat de beelden van de camera's gebruikt), ik zou mijn server moeten beheren alsof het een produktiemachine is die permanent aan het internet hangt, terwijl het dat niet is. Hij is alleen voor intern gebruik en moet niet toegankelijk zijn vanuit het internet. Dat scheelt een pak beheerwerk, daar zou je anders een dagtaak aan hebben.

NAT is echt een van slechtste dingen die het internet ooit gezien heeft en nog steeds ziet. Dat geklooi met die RFC1918 (10.0.0.x, etc) IP adresjes is echt een heel gedoe als je echte netwerken draait.

Dat snap ik wel, maar voor thuisnetwerken (wat ik ook als een 'echt' netwerk beschouw) is het best wel een handige oplossing. Het is alleen wat lastig als je wel van buiten naar binnen wilt, dan moet je met portforwarding gaan werken. Dat is extra administratie, maar veel minder werk dan de alternatieven die ik noemde.

Je kan IPv6 uiteraard uit zetten, maar je kan ook NAT toepassen met IPv6 als je daar echt blij van wordt. Beide zijn echter een reactie op het niet begrijpen van de materie en daardoor op die manier er op reageren.

En tracking, daar is je IP(v6) adres allang niet meer voor nodig. We hebben cookies, tcp fingerprinting, dns verzoeken, ga zo maar door. Veel meer dingen dan je IP-adres waarmee je getracked kan worden.

Dat is natuurlijk wel waar, maar moet je een maatregel dan niet nemen omdat er ook andere problemen zijn?

[Jef61]

PhilipsFan schreef op vrijdag 1 april 2022 @ 16:47:
[...]
Bij een iPhone is dat inderdaad wel prima, die zijn goed dichtgetimmerd en worden regelmatig voorzien van updates. Maar ik heb ook veel devices in huis waar dat niet voor geldt. 'Security' camera's bijvoorbeeld, die hebben best een lange levensduur maar krijgen al snel geen updates meer, en draaien toch een volledige Linux. Mijn eigen Windows server, waar een verouderde Apache op draait en de oude versie van SMB/CIFS. Ik ben dan toch wel blij dat die dingen achter NAT zitten, want als dat niet zo was waren ze binnen notime gehacked.

Maar dit is toch allemaal een firewall kwestie?
Op een consumenten router zal de IPv6 firewall standaard 'van buiten naar binnen' dicht staan en zul je per poort naar een bepaald IPv6-nummer moeten openzetten (net zoals port forwarding bij IPv4). Ik zie het probleem eigenlijk niet zo...

[Snow_King]

PhilipsFan schreef op vrijdag 1 april 2022 @ 16:47:
[...]
Bij een iPhone is dat inderdaad wel prima, die zijn goed dichtgetimmerd en worden regelmatig voorzien van updates. Maar ik heb ook veel devices in huis waar dat niet voor geldt. 'Security' camera's bijvoorbeeld, die hebben best een lange levensduur maar krijgen al snel geen updates meer, en draaien toch een volledige Linux. Mijn eigen Windows server, waar een verouderde Apache op draait en de oude versie van SMB/CIFS. Ik ben dan toch wel blij dat die dingen achter NAT zitten, want als dat niet zo was waren ze binnen notime gehacked.

Natuurlijk zou je het probleem op de juiste manier moeten oplossen. Maar in mijn geval zou dat dus betekenen dat ik om de 2 jaar nieuwe camera's moet kopen (plus het inregelwerk wat daarbij hoort, zoals het aanpassen van de apps en configuraties van alles wat de beelden van de camera's gebruikt), ik zou mijn server moeten beheren alsof het een produktiemachine is die permanent aan het internet hangt, terwijl het dat niet is. Hij is alleen voor intern gebruik en moet niet toegankelijk zijn vanuit het internet. Dat scheelt een pak beheerwerk, daar zou je anders een dagtaak aan hebben.

[...]
Dat snap ik wel, maar voor thuisnetwerken (wat ik ook als een 'echt' netwerk beschouw) is het best wel een handige oplossing. Het is alleen wat lastig als je wel van buiten naar binnen wilt, dan moet je met portforwarding gaan werken. Dat is extra administratie, maar veel minder werk dan de alternatieven die ik noemde.

[...]

Dat is natuurlijk wel waar, maar moet je een maatregel dan niet nemen omdat er ook andere problemen zijn?

Maar uiteindelijk hebben we toch gewoon firewalls? Alle consumenten IPv6 routers firewallen gewoon. Inkomend kan er niets naar binnen.

Met IPv6 is het internet afscannen ook niet meer mogelijk, dus ALS die firewall al open staat is het niet zo dat een scan op poort X even langs komt en snel misbruik maakt. Dat gaat gewoon niet meer.

Firewalls lossen dit probleem gewoon op. Op je router en op het device.

[PhilipsFan]

Snow_King schreef op vrijdag 1 april 2022 @ 19:56:
[...]

Maar uiteindelijk hebben we toch gewoon firewalls? Alle consumenten IPv6 routers firewallen gewoon. Inkomend kan er niets naar binnen.

Daar lijkt het inderdaad op, mijn router lijkt dat ook te doen. Ik geloof het pas als ik het zelf geprobeerd heb, maar ik heb op dit moment geen methode om het te proberen. Dan moet je namelijk een 2e IPv6 adres hebben buiten je eigen netwerk. Mijn mobiele telefoon krijgt op dit moment alleen een IPv4 adres. Ook de service die ik normaal gebruik om te controleren of ik helemaal dicht sta (grc.com) doet op dit moment alleen IPv4.

Met IPv6 is het internet afscannen ook niet meer mogelijk, dus ALS die firewall al open staat is het niet zo dat een scan op poort X even langs komt en snel misbruik maakt. Dat gaat gewoon niet meer.

Goed punt, maar hoe kan dit? Waarom is het met IPv6 niet meer mogelijk om het internet te scannen? Je kunt toch gewoon alle IPv6 nummers proberen? Het zijn er wel veel meer, dus je bent veel langer bezig, maar het kan toch nog steeds?

Firewalls lossen dit probleem gewoon op. Op je router en op het device.

Ja, dat klopt ook wel. Misschien moet ik er gewoon aan wennen. Voor veel mensen die geen ingewikkelde dingen met internet doen is het ook geen probleem, alle devices blijven normaal werken. Alleen als je zelf servers draait, moet je opeens beter gaan opletten.

Ik ben gewoon bang dat die firewall op de router niet voldoende is. Als iemand die per ongeluk uitzet, of er komt een firmware update voor de router met een bug erin, dan moet je maar weer afwachten of alles nog dicht staat. Bij NAT had je gewoon een extra laagje dat ervoor zorgde dat zelfs bij een verkeerd geconfigureerde (of zelfs helemaal afwezige firewall) de meeste inkomende verzoeken alsnog de bietenbak in gingen. Het voelt minder veilig met IPv6.

[CeesBak]

Dank voor jullie reacties @valkenier @borft @nero355 !

Samenvatting: Mijn vraag is of iemand me een hint kan geven over traag werkende communicatie van een server waar NextCloud op draait.

Momenteel draai ik NextCloud 23.0.03 op Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-105-generic x86_64). De router is een Mikrotik RB750GR3 die draait op 7.1.5. Met kabel verbindingen van de server naar deze router en de Windows 10 machine waarop de ervaringen spelen. Via CAPsMAN heb ik twee Access Points in huis.

Toen de Mikrotik router nog op versie 6 van RouterOS draaide had ik allerlei rare problemen die met versie 7.1.5. allemaal zijn verdwenen. In Windows 10 heb ik in de firewall instellingen gedaan om ICMP door te laten volgens opgave van Microsoft. Elk apparaat draait perfect van PC tot Android tablets en telefoons.

De vertragingen op de Ubuntu server met Nextcloud kan op elk moment optreden. Zojuist wil ik de juiste versie van NextCloud opzoeken op een Windows machine met Firefox.. Dus ik laad de pagina van NextCloud dat neemt dan ruim een minuut waarna de pagina opkomt. Dan log ik in als admin wat opnieuw ruim een minuut duurt. Daarna door de pagina bladeren gaat normaal prima snel. Op de apparaten via de wifi zijn verbonden heb ik de NextCloud App geïnstalleerd. Gebruik ik erg veel. Als je de App opent dan treed de zelfde vertraging op zoals hierboven beschreven. ruim een minuut wachten.

Dan log ik in met IPv4 via Putty op de server om de juiste versie van Ubuntu op te zoeken, geen enkel probleem. Via het IPv6 adres gaat het net zo snel. Geen enkele vertraging.

Al dit verkeer vindt binnen de router plaats, denk ik. Voor IPv4 heb ik de volgende regels voor de server:

code:

add action=masquerade chain=srcnat comment="Hairpin prive network" src-address=192.168.88.0/24
add action=dst-nat chain=dstnat comment=Http dst-address-list=WAN-IP dst-port=80 protocol=tcp to-addresses=192.168.88.100 to-ports=80
add action=dst-nat chain=dstnat comment=Https dst-address-list=WAN-IP dst-port=443 protocol=tcp to-addresses=192.168.88.100 to-ports=443

En voor IPv6:

code:

add action=accept chain=forward comment="http to Hover" dst-address=xxxx:xxxx:xxxx:xxxx:7285:c2ff:fe82:71cc/128 dst-port=80 protocol=tcp
add action=accept chain=forward comment="https to Hover" dst-address=xxxx:xxxx:xxxx:xxxx:7285:c2ff:fe82:71cc/128 dst-port=443 protocol=tcp

Op de Ubuntu server draait de standaard configuratie:

code:

# This is the network config written by 'subiquity'
network:
  ethernets:
    enp3s0:
      dhcp4: true
  version: 2

Hopelijk helpt deze extra informatie.

[duvekot]

CeesBak schreef op zaterdag 2 april 2022 @ 13:29:
Dank voor jullie reacties @valkenier @borft @nero355 !

Samenvatting: Mijn vraag is of iemand me een hint kan geven over traag werkende communicatie van een server waar NextCloud op draait.

Momenteel draai ik NextCloud 23.0.03 op Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-105-generic x86_64). De router is een Mikrotik RB750GR3 die draait op 7.1.5. Met kabel verbindingen van de server naar deze router en de Windows 10 machine waarop de ervaringen spelen. Via CAPsMAN heb ik twee Access Points in huis.

Toen de Mikrotik router nog op versie 6 van RouterOS draaide had ik allerlei rare problemen die met versie 7.1.5. allemaal zijn verdwenen. In Windows 10 heb ik in de firewall instellingen gedaan om ICMP door te laten volgens opgave van Microsoft. Elk apparaat draait perfect van PC tot Android tablets en telefoons.

De vertragingen op de Ubuntu server met Nextcloud kan op elk moment optreden. Zojuist wil ik de juiste versie van NextCloud opzoeken op een Windows machine met Firefox.. Dus ik laad de pagina van NextCloud dat neemt dan ruim een minuut waarna de pagina opkomt. Dan log ik in als admin wat opnieuw ruim een minuut duurt. Daarna door de pagina bladeren gaat normaal prima snel. Op de apparaten via de wifi zijn verbonden heb ik de NextCloud App geïnstalleerd. Gebruik ik erg veel. Als je de App opent dan treed de zelfde vertraging op zoals hierboven beschreven. ruim een minuut wachten.

Dan log ik in met IPv4 via Putty op de server om de juiste versie van Ubuntu op te zoeken, geen enkel probleem. Via het IPv6 adres gaat het net zo snel. Geen enkele vertraging.

Hopelijk helpt deze extra informatie.

Dat klinkt eerder alsof een bepaald script of iets anders dat op die pagina's staat niet lekker wil laden. Dus kijk eens naar de logging/details van de browser die je gebruikt of daar helder wordt waar de vertraging door ontstaat. Als het na de inlog alles werkt is al bewijs dat het niet direct een netwerk issue hoeft te zijn.

[nero355]

CeesBak schreef op zaterdag 2 april 2022 @ 13:29:
Toen de Mikrotik router nog op versie 6 van RouterOS draaide had ik allerlei rare problemen die met versie 7.1.5. allemaal zijn verdwenen.

Dat vind ik ook best wel vaag eerlijk gezegd...

Zou niet mogen gebeuren!

De vertragingen op de Ubuntu server met Nextcloud kan op elk moment optreden. Zojuist wil ik de juiste versie van NextCloud opzoeken op een Windows machine met Firefox.. Dus ik laad de pagina van NextCloud dat neemt dan ruim een minuut waarna de pagina opkomt. Dan log ik in als admin wat opnieuw ruim een minuut duurt. Daarna door de pagina bladeren gaat normaal prima snel. Op de apparaten via de wifi zijn verbonden heb ik de NextCloud App geïnstalleerd. Gebruik ik erg veel. Als je de App opent dan treed de zelfde vertraging op zoals hierboven beschreven. ruim een minuut wachten.

IMHO allemaal DNS gerelateerd, maar ik weet niet hoe jij de boel benadert : DNS naam of IP adres ?!

Dan log ik in met IPv4 via Putty op de server om de juiste versie van Ubuntu op te zoeken, geen enkel probleem. Via het IPv6 adres gaat het net zo snel. Geen enkele vertraging.

Dat is mooi, want dan heb je geen Reverse DNS problemen met SSH

Al dit verkeer vindt binnen de router plaats, denk ik. Voor IPv4 heb ik de volgende regels voor de server:

code:

add action=masquerade chain=srcnat comment="Hairpin prive network" src-address=192.168.88.0/24
add action=dst-nat chain=dstnat comment=Http dst-address-list=WAN-IP dst-port=80 protocol=tcp to-addresses=192.168.88.100 to-ports=80
add action=dst-nat chain=dstnat comment=Https dst-address-list=WAN-IP dst-port=443 protocol=tcp to-addresses=192.168.88.100 to-ports=443

Hairpin NAT vindt op je Router plaats, maar gaat dus wel van LAN naar WAN om vervolgens weer richting LAN te gaan!

Waarom heb je Hairpin NAT nodig en ben je daar wel van bewust ?!

Op de Ubuntu server draait de standaard configuratie:

code:

# This is the network config written by 'subiquity'
network:
  ethernets:
    enp3s0:
      dhcp4: true
  version: 2

Een Server hoort IMHO altijd een Static IP address te hebben en niet afhankelijk te zijn van DHCP

Je zou hooguit als backup optie een Static DHCP Mapping op basis van MAC adres aan kunnen maken voor het geval er iets omvalt, maar die kans is over het algemeen erg klein!

/EDIT :

Snow_King schreef op vrijdag 1 april 2022 @ 10:56:
Sorry, maar ik denk echt dat je een aantal fundamenten van routing en firewalling niet begrijpt.

Ik begrijp ze wel, maar ik begrijp @PhilipsFan ook : Ik wil ook niet terug naar de jaren '90 waarbij mijn inbelmodem mijn PC een IP geeft dat direct aan het Internet hangt!
Of nog erger : Mijn Printer die aan het netwerk hangt en daar 0,0 behoefte aan heeft...

Wel of geen ZoneAlarm Firewall : IK WIL dat gewoon NIET!

Mijn iPhone durf ik gewoon een publiek IPv4/IPv6 adres te geven, succes met scannen. Beveiliging begint niet bij je firewall/router, maar al op het device.

Als in : Wat je op 127.0.0.1 houdt hoef je ook niet te Firewallen

Dat is over het algemeen ook mijn beleid

NAT is echt een van slechtste dingen die het internet ooit gezien heeft en nog steeds ziet. Dat geklooi met die RFC1918 (10.0.0.x, etc) IP adresjes is echt een heel gedoe als je echte netwerken draait.

Niet zo dramatisch doen

Je kan IPv6 uiteraard uit zetten, maar je kan ook NAT toepassen met IPv6 als je daar echt blij van wordt. Beide zijn echter een reactie op het niet begrijpen van de materie en daardoor op die manier er op reageren.

Zoveel mensen, zoveel wensen!

PhilipsFan schreef op vrijdag 1 april 2022 @ 16:47:
Bij een iPhone is dat inderdaad wel prima, die zijn goed dichtgetimmerd en worden regelmatig voorzien van updates.

Zolang je dus geen Services draait die Extern benaderbaar moeten/mogen zijn dan ben je al een heel eind IMHO

Maar ik heb ook veel devices in huis waar dat niet voor geldt. 'Security' camera's bijvoorbeeld, die hebben best een lange levensduur maar krijgen al snel geen updates meer, en draaien toch een volledige Linux.

Dat zal eerder iets van BusyBox zijn en is typisch een voorbeeld van apparatuur die je makkelijk in een eigen IPv4 subnet/VLAN kan proppen en daar lekker kan laten!

Mijn eigen Windows server, waar een verouderde Apache op draait en de oude versie van SMB/CIFS.

Apache kan je updaten, maar je kan ook gewoon Windows dumpen en een leuke Linux distro installeren en dan ben je ook van dat gezeik af!

Ik ben dan toch wel blij dat die dingen achter NAT zitten, want als dat niet zo was waren ze binnen notime gehacked.

Het probleem is dat men tegenwoordig veel te vaak :
- Automatisch alle apparaten een Gateway geeft.
- Ook nog eens het subnet waarin ze zitten meteen gaat zitten NAT'ten...

Terwijl je die apparaten alleen lokaal wilt kunnen benaderen en dus het een en ander makkelijk kan beperken/weglaten!

Natuurlijk zou je het probleem op de juiste manier moeten oplossen. Maar in mijn geval zou dat dus betekenen dat ik om de 2 jaar nieuwe camera's moet kopen (plus het inregelwerk wat daarbij hoort, zoals het aanpassen van de apps en configuraties van alles wat de beelden van de camera's gebruikt), ik zou mijn server moeten beheren alsof het een produktiemachine is die permanent aan het internet hangt, terwijl het dat niet is. Hij is alleen voor intern gebruik en moet niet toegankelijk zijn vanuit het internet. Dat scheelt een pak beheerwerk, daar zou je anders een dagtaak aan hebben.

Dat snap ik wel, maar voor thuisnetwerken (wat ik ook als een 'echt' netwerk beschouw) is het best wel een handige oplossing. Het is alleen wat lastig als je wel van buiten naar binnen wilt, dan moet je met portforwarding gaan werken. Dat is extra administratie, maar veel minder werk dan de alternatieven die ik noemde.

Niet zo dramatisch doen!

Snow_King schreef op vrijdag 1 april 2022 @ 19:56:
Maar uiteindelijk hebben we toch gewoon firewalls? Alle consumenten IPv6 routers firewallen gewoon. Inkomend kan er niets naar binnen.

Gevaarlijke aanname!

Met IPv6 is het internet afscannen ook niet meer mogelijk, dus ALS die firewall al open staat is het niet zo dat een scan op poort X even langs komt en snel misbruik maakt. Dat gaat gewoon niet meer.

Moeilijker/langdraadiger maakt het niet meteen onmogelijk!

Firewalls lossen dit probleem gewoon op. Op je router en op het device.

Laten we niet doen alsof een Firewall meteen alles oplost...

[ Voor 47% gewijzigd door nero355 op 03-04-2022 15:03 ]

[CeesBak]

@nero355 Dank voor je reactie.

Hairpin NAT vindt op je Router plaats, maar gaat dus wel van LAN naar WAN om vervolgens weer richting LAN te gaan!

Waarom heb je Hairpin NAT nodig en ben je daar wel van bewust ?!

Hairpin in noodzakelijk om op de adresbalk een url in te tikken en die dan van buiten weer binnen komt.

Een Server hoort IMHO altijd een Static IP address te hebben en niet afhankelijk te zijn van DHCP

Op de router staat een statisch adres ingesteld met behulp van het MAC adres.

[Keeper of the Keys]

Hey, ik ben aan het beginnen met experimenteren met IPv6 thuis en wil het binnenkort ook op mijn werk proberen uit te rollen (uiteraard eerst op een test systeem).

Nou vroeg ik mij af, wat is de juiste manier om met meerdere ISPs om te gaan in een IPv6 wereld?
Met IPv4 zitten we achter een NAT op een of meer "echte" IPv4 adressen maar in de IPv6 wereld werkt dit toch anders.

[begintmeta]

@Keeper of the Keys , is het niet mogelijk om de diverse devices meerdere echte IPv6-adressen (link-local, meerdere ISP-prefixes) te geven?

[Keeper of the Keys]

@begintmeta Ik neem aan van wel, maar om per ISP IPv6 ranges te gaan definiëren op elke vlan lijkt me niet erg schaalbaar.

[Dreamvoid]

Met IPv6 heb je meerdere netwerken op 1 interface.

Multi-WAN werkt bij IPv6 dmv meerdere global routes tegelijkertijd, met verschillende Priority.

Oftewel, je adverteert je standaard IPv6 route met hoge Priority en een lifetime van bv 10 seconden. Je adverteert je backup route met lage Priority -> alle devices gebruiken de standaard route. Dan draai je een check functie (kan zelfs een cronjob scriptje zijn) dat als de standaard route eruit ligt, de router stopt met het adverteren van die route, en binnen 10 seconden switchen alle devices automatisch naar de backup route.

[ Voor 14% gewijzigd door Dreamvoid op 04-04-2022 10:24 ]

[CeesBak]

@duvekot @nero355 @borft @valkenier
Jullie reacties hebben geleid tot nadenken. Mijn certificaat van Letsencrypt was vernieuwd juist voor mijn escapades met IPv6. Natuurlijk stonden het A en AAAA record al juist ingesteld, dat kon het niet zijn. Vanmorgen heb ik het certificaat vernieuwd.
Het geheel is een stuk sneller, maar af en toe heb ik nog een wachttijd van meer dan een minuut, dat wordt toch nog verder zoeken.
Tijdens het vernieuwen van het certificaat vroeg Certbot of er twee sites noesten worden aangemaakt. Nu heb ik alleen "www.mijnsite.nl" alleen in het certificaat. Moet je voor "mijnsite.nl" ook een certificaat aanvragen? Poeh dat wordt verder zoeken over de consequenties hiervan voor Apache.

[borft]

CeesBak schreef op zondag 3 april 2022 @ 16:31:
@nero355 Dank voor je reactie.

[...]

Hairpin in noodzakelijk om op de adresbalk een url in te tikken en die dan van buiten weer binnen komt.

Dat klopt niet helemaal. Voor ipv6 is het sowieso niet nodig, omdat je niet over de router naar je server verbindt. Voor ipv4 is het alleen nodig als je hostname resolved naar iets buiten je subnet (en de connectie dus over de router/gateway gaat). Dat kan je ook oplossen door op je interne DNS het internet IP adres terug te geven. NAT + hairpin is, imho, een beetje een ransoplossing

Kan je es kijken wat er op je Nextcloud server gebeurt als je aan het wachten bent? Is apache wel al bezig? Of duurt het daadwerkelijk zolang voordat het request aankomt? Oh, en, kan je ook kijken of je verbinding over ipv4 of ipv6 loopt (zowel bij trage als snelle requests)?

Ik heb een vergelijkbare setup (self-hosted Nextcloud, volledig dual-stack netwerk), en hier geen problemen met vertragingen, anders dan dat Nextcloud soms gewoon langzaam is.

[Snow_King]

PhilipsFan schreef op zaterdag 2 april 2022 @ 12:59:
[...]
Daar lijkt het inderdaad op, mijn router lijkt dat ook te doen. Ik geloof het pas als ik het zelf geprobeerd heb, maar ik heb op dit moment geen methode om het te proberen. Dan moet je namelijk een 2e IPv6 adres hebben buiten je eigen netwerk. Mijn mobiele telefoon krijgt op dit moment alleen een IPv4 adres. Ook de service die ik normaal gebruik om te controleren of ik helemaal dicht sta (grc.com) doet op dit moment alleen IPv4.

Test eens met: http://www.ipv6scanner.com/cgi-bin/main.py

Of huur bij een partij ergens even een Linux VPS waar je vervolgens met nmap kan scannen.

In Nederland zou je terecht kunnen bij Versio, TransIP, PCextreme, Yourhosting, CloudVPS, noem maar op. Allemaal IPv6 op die VPS'en daar.

PhilipsFan schreef op zaterdag 2 april 2022 @ 12:59:
[...]
Goed punt, maar hoe kan dit? Waarom is het met IPv6 niet meer mogelijk om het internet te scannen? Je kunt toch gewoon alle IPv6 nummers proberen? Het zijn er wel veel meer, dus je bent veel langer bezig, maar het kan toch nog steeds?

Alleen jouw LAN is al 64-bits lang. Het huidige internet is 32-bits. Je hebt dus alleen in jouw LAN al een kwadraat aantal adressen dan het gehele internet nu al heeft.

Simpelweg: Er zijn zo, ontzettend veel, maar echt, ontzettend, super, super, super veel adressen dat het gewoon niet haalbaar is om een portscan te doen over het gehele internet heen.

PhilipsFan schreef op zaterdag 2 april 2022 @ 12:59:
[...]
Ja, dat klopt ook wel. Misschien moet ik er gewoon aan wennen. Voor veel mensen die geen ingewikkelde dingen met internet doen is het ook geen probleem, alle devices blijven normaal werken. Alleen als je zelf servers draait, moet je opeens beter gaan opletten.

Je kan iig niet je kop in het zand steken en IPv6 maar uit laten staan of bewust uitzetten. IPv4 begint in volume aan bandbreedte al steeds minder de overhand te hebben. IPv6 is er en blijft.

PhilipsFan schreef op zaterdag 2 april 2022 @ 12:59:
[...]
Ik ben gewoon bang dat die firewall op de router niet voldoende is. Als iemand die per ongeluk uitzet, of er komt een firmware update voor de router met een bug erin, dan moet je maar weer afwachten of alles nog dicht staat. Bij NAT had je gewoon een extra laagje dat ervoor zorgde dat zelfs bij een verkeerd geconfigureerde (of zelfs helemaal afwezige firewall) de meeste inkomende verzoeken alsnog de bietenbak in gingen. Het voelt minder veilig met IPv6.

Het 'voelt', maar dat is echt puur een ervaringskwestie. Ik draai nu al 10 jaar met IPv6 thuis en op het werk. Duizenden servers aan het internet en thuis gewoon mijn standaard dingen.

Echt nooit een probleem mee gehad. Gewoon de firewall die aan staat op de router en klaar.

nero355 schreef op zondag 3 april 2022 @ 14:20:
[...]

Ik begrijp ze wel, maar ik begrijp @PhilipsFan ook : Ik wil ook niet terug naar de jaren '90 waarbij mijn inbelmodem mijn PC een IP geeft dat direct aan het Internet hangt!
Of nog erger : Mijn Printer die aan het netwerk hangt en daar 0,0 behoefte aan heeft...

Wel of geen ZoneAlarm Firewall : IK WIL dat gewoon NIET!

Mijn printer thuis heeft gewoon een IPv6 adres evenals mijn NAS (Synology).

Inbound drop ik gewoon de connecties en alleen related,established mag naar binnen. Gaat gewoon prima :-)

nero355 schreef op zondag 3 april 2022 @ 14:20:
[...]

Niet zo dramatisch doen

NAT is gewoon echt een hel. Ga maar eens bedrijfsnetwerken aan elkaar knopen die allemaal het zelfde RFC1918 subnetje lokaal gebruiken...

nero355 schreef op zondag 3 april 2022 @ 14:20:
[...]

Zoveel mensen, zoveel wensen!

Maar IPv6 gaat niet weg. Doe ervaring op, leer het, accepteer het, omarm het. Niet verzetten.

nero355 schreef op zondag 3 april 2022 @ 14:20:
[...]

Moeilijker/langdraadiger maakt het niet meteen onmogelijk!


[...]

Laten we niet doen alsof een Firewall meteen alles oplost...

Een portscan van het hele internet gaat met IPv6 gewoon niet. Te veel adresen. Een lokale /48 scannen gaat al niet.

Je hebt al snel een latency van een paar ms naar een verbinding van iemand thuis. Ga alle adressen uit die /48 maar eens scannen. Onmogelijk zonder dat het iemand op valt of dat je het binnen een fatsoenlijke time window voor elkaar krijgt.

Een firewall lost gewoon op wat NAT nu via een pleister fixed. Namelijk: Unrelated inbound connecties droppen. Klaar.

[nero355]

CeesBak schreef op maandag 4 april 2022 @ 11:08:
Mijn certificaat van Letsencrypt was vernieuwd

Tijdens het vernieuwen van het certificaat vroeg Certbot of er twee sites noesten worden aangemaakt. Nu heb ik alleen "www.mijnsite.nl" alleen in het certificaat. Moet je voor "mijnsite.nl" ook een certificaat aanvragen? Poeh dat wordt verder zoeken over de consequenties hiervan voor Apache.

Als je geen SSL Certificaat aanmaakt die voor je hele domein bruikbaar is (mijnsite.nl) dan moet je inderdaad per sub-domein een SSL Certificaat aanmaken!

Er bestaat namelijk ook zoiets als een Wildcard Certificate : https://knowledge.digicer...linformation/INFO900.html
Je maakt dan een SSL Certificaat aan die zich presenteert als *.mijnsite.nl en dus voor alle sub-domeinen onder dat domein geldt!

Ik heb alleen geen idee of Let's Encrypt zoiets aanbiedt zonder ervoor te moeten betalen...

[ericafterdark]

nero355 schreef op maandag 4 april 2022 @ 16:40:
[...]

Als je geen SSL Certificaat aanmaakt die voor je hele domein bruikbaar is (mijnsite.nl) dan moet je inderdaad per sub-domein een SSL Certificaat aanmaken!

Er bestaat namelijk ook zoiets als een Wildcard Certificate : https://knowledge.digicer...linformation/INFO900.html
Je maakt dan een SSL Certificaat aan die zich presenteert als *.mijnsite.nl en dus voor alle sub-domeinen onder dat domein geldt!

Ik heb alleen geen idee of Let's Encrypt zoiets aanbiedt zonder ervoor te moeten betalen...

Ja, dat is mogelijk.

https://letsencrypt.org/docs/faq/

Does Let’s Encrypt issue wildcard certificates?

"Yes. Wildcard issuance must be done via ACMEv2 using the DNS-01 challenge."

Zie ook:

https://letsencrypt.org/d...e-types/#dns-01-challenge

https://community.letsenc...vironment-wildcards/55578

[mrdemc]

nero355 schreef op maandag 4 april 2022 @ 16:40:
[...]

Als je geen SSL Certificaat aanmaakt die voor je hele domein bruikbaar is (mijnsite.nl) dan moet je inderdaad per sub-domein een SSL Certificaat aanmaken!

Er bestaat namelijk ook zoiets als een Wildcard Certificate : https://knowledge.digicer...linformation/INFO900.html
Je maakt dan een SSL Certificaat aan die zich presenteert als *.mijnsite.nl en dus voor alle sub-domeinen onder dat domein geldt!

Ik heb alleen geen idee of Let's Encrypt zoiets aanbiedt zonder ervoor te moeten betalen...

Letsencrypt ondersteund zowel wildcard-certificaten (met een andere vorm van authenticatie dan voor de 'normale' certificaten) als certificaten met meerdere alternatieve domeinnamen (SANs). In dat laatste geval heb je ook maar 1 certificaat nodig voor meerdere domeinnamen en dat is over het algemeen wel de standaard om dat te doen.

Zover ik weet doet letsencrypt dat via de commandline trouwens automatisch als je je Apache/nginx server correct hebt geconfigureerd met meerdere domein aliassen.

[ericafterdark]

mrdemc schreef op maandag 4 april 2022 @ 16:46:
[...]


Letsencrypt ondersteund zowel wildcard-certificaten (met een andere vorm van authenticatie dan voor de 'normale' certificaten) als certificaten met meerdere alternatieve domeinnamen (SANs). In dat laatste geval heb je ook maar 1 certificaat nodig voor meerdere domeinnamen en dat is over het algemeen wel de standaard om dat te doen.

Zover ik weet doet letsencrypt dat via de commandline trouwens automatisch als je je Apache/nginx server correct hebt geconfigureerd met meerdere domein aliassen.

Certbot vind ik persoonlijk ideaal: https://certbot.eff.org/

[Raven]

nero355 schreef op maandag 4 april 2022 @ 16:40:
[...]

Als je geen SSL Certificaat aanmaakt die voor je hele domein bruikbaar is (mijnsite.nl) dan moet je inderdaad per sub-domein een SSL Certificaat aanmaken!

Er bestaat namelijk ook zoiets als een Wildcard Certificate : https://knowledge.digicer...linformation/INFO900.html
Je maakt dan een SSL Certificaat aan die zich presenteert als *.mijnsite.nl en dus voor alle sub-domeinen onder dat domein geldt!

Ik heb alleen geen idee of Let's Encrypt zoiets aanbiedt zonder ervoor te moeten betalen...

* Raven gebruikt al jaren een gratis Let's Encrypt wildcard certificaat in het lokale netwerk
Alleen wel ff prutsen om de DNS verificatie werkend te krijgen.

De DNS verificatie wordt met behulp van certbot, een paar bash-scripts en een extern gehost PHP-script dat via Direct Admin API TXT records kan aanmaken/verwijderen, geregeld.

[mrdemc]

Raven schreef op maandag 4 april 2022 @ 17:49:
[...]

* Raven gebruikt al jaren een gratis Let's Encrypt wildcard certificaat in het lokale netwerk
Alleen wel ff prutsen om de DNS verificatie werkend te krijgen.

De DNS verificatie wordt met behulp van certbot, een paar bash-scripts en een extern gehost PHP-script dat via Direct Admin API TXT records kan aanmaken/verwijderen, geregeld.

Voor intern, mits je eigen servers kan draaien, kan het ook "leuk" zijn om een eigen ACME CA op te zetten met step-ca
https://smallstep.com/blog/private-acme-server/

[Raven]

mrdemc schreef op maandag 4 april 2022 @ 18:29:
[...]


Voor intern, mits je eigen servers kan draaien, kan het ook "leuk" zijn om een eigen ACME CA op te zetten met step-ca
https://smallstep.com/blog/private-acme-server/

Hmm, interessant

[duvekot]

Raven schreef op maandag 4 april 2022 @ 18:46:
[...]

Hmm, interessant

In eerste instantie lijkt het interessant om een eigen CA op te zetten ... Maar als je je er verder in verdiept dan zitten er toch wel een boel kanttekeningen bij .. zeker als het steeds groter wordt. Dan is de veiligheid van je eigen servers "in eens" afhankelijk van je eigen masterkey die je ergens veilig moet gaan houden.

Ik zou niemand aanraden een eigen CA te gaan proberen te beheren.

(Maar als onderdeel van "hobby" , "uitzoeken", "leren" etc .. altijd interessant om er in te duiken .. ter lering en vermaak)

[CeesBak]

Fijn dat je reageerde!

borft schreef op maandag 4 april 2022 @ 12:56:
[...]
Dat klopt niet helemaal. Voor ipv6 is het sowieso niet nodig, omdat je niet over de router naar je server verbindt. Voor ipv4 is het alleen nodig als je hostname resolved naar iets buiten je subnet (en de connectie dus over de router/gateway gaat). Dat kan je ook oplossen door op je interne DNS het internet IP adres terug te geven. NAT + hairpin is, imho, een beetje een ransoplossing

Tja, interne DNS? Ik was blij dat ik een oplossing had gevonden waardoor apps weer goed werkten.

Kan je es kijken wat er op je Nextcloud server gebeurt als je aan het wachten bent? Is apache wel al bezig? Of duurt het daadwerkelijk zolang voordat het request aankomt? Oh, en, kan je ook kijken of je verbinding over ipv4 of ipv6 loopt (zowel bij trage als snelle requests)?

Ik heb een vergelijkbare setup (self-hosted Nextcloud, volledig dual-stack netwerk), en hier geen problemen met vertragingen, anders dan dat Nextcloud soms gewoon langzaam is.

De vertragingen zijn nu grotendeels onder de knie. Kijken wat er gebeurd als ik aan het wachten ben? Daar ben ik nieuwsgierig naar. Hoe doe je dat?

[borft]

CeesBak schreef op dinsdag 5 april 2022 @ 09:28:

De vertragingen zijn nu grotendeels onder de knie. Kijken wat er gebeurd als ik aan het wachten ben? Daar ben ik nieuwsgierig naar. Hoe doe je dat?

Je kunt op de nextcloud server kijken (in een shell), of het apache process veel cpu gebruikt of niet (bv met top oid) en bv naar disk activiteit (bv met iotop of iostat). En in je browser kan je kijken in de developer tools, om te zien wat het request aan het doen is.

Wat betreft DNS, als ik mijn nextcloud server resolve, op mijn eigen netwerk, krijg ik dus het interne IP terug. Dat regelt dnsmasq, dat afgezien van DHCP ook de internet DNS doet. Buiten mijn netwerk, geeft ie het externe IP terug. Voor ipv6 geen verschil natuurlijk. Zo heb ik geen hairpin NAT nodig. Maakt overigens ook de verbinding sneller, want zo verbind ik direct met de Nextcloud server, en loopt de verbinding niet over mijn router. (in het geval van ipv4. bij ipv6 is de verbinding sowieso direct, want dat IP zit in hetzelfde subnet)

[downtime]

duvekot schreef op maandag 4 april 2022 @ 20:41:
[...]

In eerste instantie lijkt het interessant om een eigen CA op te zetten ... Maar als je je er verder in verdiept dan zitten er toch wel een boel kanttekeningen bij .. zeker als het steeds groter wordt. Dan is de veiligheid van je eigen servers "in eens" afhankelijk van je eigen masterkey die je ergens veilig moet gaan houden.

Ik zou niemand aanraden een eigen CA te gaan proberen te beheren.

(Maar als onderdeel van "hobby" , "uitzoeken", "leren" etc .. altijd interessant om er in te duiken .. ter lering en vermaak)

Ik zou niet weten waarom niet. Ik heb 10 jaar geleden ofzo een workshop AD Certificate Services gedaan en heb daarna thuis zelf een CA opgetuigd (die het nog steeds doet). Het hoeft helemaal niet vreselijk complex te zijn.

[Brahiewahiewa]

PhilipsFan schreef op vrijdag 1 april 2022 @ 16:47:
... ik zou mijn server moeten beheren alsof het een produktiemachine is die permanent aan het internet hangt, terwijl het dat niet is. Hij is alleen voor intern gebruik en moet niet toegankelijk zijn vanuit het internet. Dat scheelt een pak beheerwerk, daar zou je anders een dagtaak aan hebben...

Jouw server wordt al beheerd alsof hij aan het internet hangt. Elke Windows, Linux, *BSD en MAC komen uit de doos met een default firewall die binnenkomende connecties van een ander dan het locale subnet, blokkeert. Het grootste manco in deze beveiliging is dat mensen met te weinig netwerkkennis hem helemaal open zetten of - nog erger - hem uitzetten

[Snow_King]

Brahiewahiewa schreef op woensdag 6 april 2022 @ 00:54:
[...]

Jouw server wordt al beheerd alsof hij aan het internet hangt. Elke Windows, Linux, *BSD en MAC komen uit de doos met een default firewall die binnenkomende connecties van een ander dan het locale subnet, blokkeert. Het grootste manco in deze beveiliging is dat mensen met te weinig netwerkkennis hem helemaal open zetten of - nog erger - hem uitzetten

Exact! Dat lijkt @PhilipsFan niet helemaal te begrijpen.

Een Windows machine heeft standaard zijn firewall aan. Een Linux systeem ook, enkel SSH wordt vaak nog toegestaan, maar de rest zit allemaal dicht.

Firewalls wil je JUIST ook in je LAN, je moet je LAN niet zo maar vertrouwen. Want zo gaan juist ransomware wormen rond, omdat ze in een lokaal LAN vrij spel hebben omdat men daar niets filtert.

Mijn Linux laptop, MacOS desktop, ik durf het allemaal gewoon direct aan het internet te hangen. Ook als het gewoon een publiek IPv4 adres zou zijn.

Het grote boze internet is helemaal niet zo gevaarlijk zoals veel mensen het doen voor komen.

[PhilipsFan]

Snow_King schreef op woensdag 6 april 2022 @ 08:56:
[...]

Exact! Dat lijkt @PhilipsFan niet helemaal te begrijpen.

Een Windows machine heeft standaard zijn firewall aan. Een Linux systeem ook, enkel SSH wordt vaak nog toegestaan, maar de rest zit allemaal dicht.

Firewalls wil je JUIST ook in je LAN, je moet je LAN niet zo maar vertrouwen. Want zo gaan juist ransomware wormen rond, omdat ze in een lokaal LAN vrij spel hebben omdat men daar niets filtert.

Mijn Linux laptop, MacOS desktop, ik durf het allemaal gewoon direct aan het internet te hangen. Ook als het gewoon een publiek IPv4 adres zou zijn.

Het grote boze internet is helemaal niet zo gevaarlijk zoals veel mensen het doen voor komen.

Ik begrijp het wel en heb ook zeker wel een firewall draaien op mijn server, ook al is die niet vanuit het internet toegankelijk.

Maar wat jullie niet lijken te begrijpen, is dat je daarmee wel vertrouwt op een stuk software. Natuurlijk heb ik de firewall aan staan, maar die kan een bug bevatten en daardoor per ongeluk een connectie doorlaten. Al die updates hebben het nadeel dat je nooit weet welke nieuwe kwetsbaarheden worden geintroduceerd. Aangezien de data op m'n server nogal kostbaar is, wil ik daar niet te licht mee omgaan en dan zijn 3 dijkjes beter dan 2. Met IPv6 heb ik dus alleen de firewalls in m'n router en op de pc, met IPv4 zat daar nog NAT tussen wat het voordeel heeft dat het niks kan beginnen met loze verbindingsverzoeken.

De configuratie van een firewall is bovendien foutgevoelig. Je kunt 'm uitzetten (gebeurt vaak als je even iets wilt uitproberen, en daarna vergeet om 'm weer aan te zetten) of (per ongeluk) een rule aanmaken waardoor alle verzoeken toch worden doorgelaten. Natuurlijk zijn dat allemaal menselijke fouten en zou je die niet moeten maken, maar het kan wel eens gebeuren. NAT voelt dan als een extra laagje veiligheid. Als ik (per ongeluk) de firewall verkeerd configureer of uitschakel, dan kan er nog steeds niemand bij m'n server. Bij IPv6 kan dat wel.

Als voorbeeld van hoe makkelijk je een firewall verkeerd kunt configureren: ik heb een eigen VPN servertje met Wireguard, waarmee ik verbinding maak vanaf m'n telefoon als ik niet thuis ben. Wireguard heeft ingebouwd dat er geen antwoord wordt gegeven als het eerste verzoek niet de juiste key bevat. Daardoor lijkt het voor een aanvaller (die de key niet heeft) alsof er geen service staat te luisteren naar die poort, zodat het geen zin heeft om verder aan te vallen.

Nu bleek dat een aanvaller in dat geval toch een 'poort gesloten' antwoord kreeg. Dat kan een incentive zijn om verder te zoeken naar kwetsbaarheden. Wat bleek: (na lang uitzoeken) dat op mijn router de betreffende poort open stond voor zowel TCP als UDP. Wireguard gebruikt echter alleen UDP, dus als er een TCP verzoek kwam, gaf de server 'poort gesloten' terug. Aangepast in de router dat alleen UDP wordt doorgegeven en toen was alles weer stealth.

[nero355]

Brahiewahiewa schreef op woensdag 6 april 2022 @ 00:54:
Jouw server wordt al beheerd alsof hij aan het internet hangt. Elke Windows, Linux, *BSD en MAC komen uit de doos met een default firewall die binnenkomende connecties van een ander dan het locale subnet, blokkeert.

Dat is dus niet waar : Alleen Windows gaat je standaard zitten vervelen met zijn Firewall en een Linux of FreeBSD installatie absoluut niet!

Het grootste manco in deze beveiliging is dat mensen met te weinig netwerkkennis hem helemaal open zetten of - nog erger - hem uitzetten

Ik zet al jarenlang mijn Windows Firewall gewoon UIT om daar verder geen last van te hebben i.c.m. verschillende soorten communicatie/software

Snow_King schreef op woensdag 6 april 2022 @ 08:56:
Een Windows machine heeft standaard zijn firewall aan. Een Linux systeem ook, enkel SSH wordt vaak nog toegestaan, maar de rest zit allemaal dicht.

Dat klopt dus niet!

Doe maar eens een default installatie van RaspBian/Raspberry Pi OS of een willekeurig Ubuntu smaakje of FreeBSD

Firewalls wil je JUIST ook in je LAN, je moet je LAN niet zo maar vertrouwen. Want zo gaan juist ransomware wormen rond, omdat ze in een lokaal LAN vrij spel hebben omdat men daar niets filtert.

Ransomware is een PEBCAK probleem en wordt vaak via Samba/SMB a.k.a. Windows File Sharing verspreid dus zolang je niet alles voor iedereen zomaar open zet dan heb je nergens last van!

Sterker nog : Sinds een bepaalde versie/update/patch kan je niet eens alles met Everyone zonder een wachtwoord delen!

Mijn Linux laptop, MacOS desktop, ik durf het allemaal gewoon direct aan het internet te hangen. Ook als het gewoon een publiek IPv4 adres zou zijn.

Het grote boze internet is helemaal niet zo gevaarlijk zoals veel mensen het doen voor komen.

Ja, echt super veilig en niks aan de hand en zo : ernstoud in "[Caiway Glasvezel] Ervaringen & Discussie - Deel 2"

[Roetzen]

PhilipsFan schreef op woensdag 6 april 2022 @ 12:19:
[...]

Ik begrijp het wel en heb ook zeker wel een firewall draaien op mijn server, ook al is die niet vanuit het internet toegankelijk.

Maar wat jullie niet lijken te begrijpen, is dat je daarmee wel vertrouwt op een stuk software. Natuurlijk heb ik de firewall aan staan, maar die kan een bug bevatten en daardoor per ongeluk een connectie doorlaten

En die NAT in je router is geen stukje software die een bug kan bevatten waardoor er per ongeluk toch een connectie wordt doorgelaten?

Aangezien de data op m'n server nogal kostbaar is, wil ik daar niet te licht mee omgaan en dan zijn 3 dijkjes beter dan 2. Met IPv6 heb ik dus alleen de firewalls in m'n router en op de pc, met IPv4 zat daar nog NAT tussen wat het voordeel heeft dat het niks kan beginnen met loze verbindingsverzoeken.

In het IPv4 only tijdperk had ik ook maar twee dijkjes tussen het Internet en mijn PC. Want in de router zat geen firewall, er was alleen de NAT.

De configuratie van een firewall is bovendien foutgevoelig. Je kunt 'm uitzetten (gebeurt vaak als je even iets wilt uitproberen, en daarna vergeet om 'm weer aan te zetten) of (per ongeluk) een rule aanmaken waardoor alle verzoeken toch worden doorgelaten.

Ook dat kan met NAT net zo goed. Je kunt per ongeluk de "demilitairized zone" aanzetten. Of een port forwarding aanzetten voor een test en die vergeten weer uit te zetten.

Als voorbeeld van hoe makkelijk je een firewall verkeerd kunt configureren: ik heb een eigen VPN servertje met Wireguard, waarmee ik verbinding maak vanaf m'n telefoon als ik niet thuis ben.
[..]
Nu bleek dat een aanvaller in dat geval toch een 'poort gesloten' antwoord kreeg. Dat kan een incentive zijn om verder te zoeken naar kwetsbaarheden. Wat bleek: (na lang uitzoeken) dat op mijn router de betreffende poort open stond voor zowel TCP als UDP. Wireguard gebruikt echter alleen UDP, dus als er een TCP verzoek kwam, gaf de server 'poort gesloten' terug. Aangepast in de router dat alleen UDP wordt doorgegeven en toen was alles weer stealth.

En ook dat kan met IPv4 net zo goed. Je kunt een forward configureren voor zowel TCP als UDP terwijl alleen TCP bedoeld was.

En dan hebben we het nog niet eens over truken als plug and play die NAT omzeilen...

NAT is schijnveiligheid. Hoe sneller je tot dat besef komt hoe eerder je je systeem veilig kunt maken.

[nero355]

Roetzen schreef op woensdag 6 april 2022 @ 15:23:
En dan hebben we het nog niet eens over truken als plug and play die NAT omzeilen...

Dat zet je natuurlijk UIT op zowel je Router als de Windows Clients

En als je van die stomme PlayStation/X-Box Consoles hebt dan dump je die in een apart VLAN waarvoor die troep wel AAN staat

[mrdemc]

nero355 schreef op woensdag 6 april 2022 @ 17:04:
[...]

Dat zet je natuurlijk UIT op zowel je Router als de Windows Clients

En als je van die stomme PlayStation/X-Box Consoles hebt dan dump je die in een apart VLAN waarvoor die troep wel AAN staat

In het geval van een Xbox hoef je dat ook niet aan te zetten, hooguit handmatig wat poorten configureren in de firewall. Multiplayer werkt bij mij prima op die manier en de Xbox is tevreden zegt ie

[nero355]

mrdemc schreef op woensdag 6 april 2022 @ 18:06:
In het geval van een Xbox hoef je dat ook niet aan te zetten, hooguit handmatig wat poorten configureren in de firewall. Multiplayer werkt bij mij prima op die manier en de Xbox is tevreden zegt ie

Als je maar één Console hebt staan dan is dat uiteraard ook een prima oplossing, maar sommige mensen hebben beiden of meerdere modellen in ieder geval en dan wordt het een ander verhaal...

[Maasluip]

Met de move van XS4ALL naar KPN heb ik nu ook een nieuw IP-adres gekregen. Ik krijg alleen IPv6 niet op mijn Unbuntu doos geconfigureerd. Ik denk dat het alleen de gateway is die ik goed moet instellen want als ik die fout instel dan hebben sommige website problemen (waarschijnlijk IPv6 als primary connection en IPv4 fallback) en als ik die niet instel heb ik gewoon geen IPv6.
IPv6 op mijn lokaal netwerk werkt wel.

Het is Ubuntu 18.04.5 en ik heb een FritzBox 7490.
Het IPv6 adres van FritzBox had ik voor de vorige verbinding ergens op de configpagina's gevonden (ergens stond een Unique Local Address), maar dat lijkt nu weg te zijn.

In de online monitor staat

Internet, IPv6	
connected since 30.03.2022, 02:22, XS4ALL FTTH,
IPv6 Address: 2a02:a465:9c40::1, Valid for: 236270/149870s,
IPv6 prefix: 2a02:a465:9c40::/48, Valid for: 236270/149870s

Dan dacht ik dat de gateway 2a02:a465:9c40::1 is, dus zet ik dit in mijn /etc/network/interfaces:

code:

#ipv6 configuration
iface eth0 inet6 static
address 2a02:a465:9c40:1::64
netmask 48
gateway 2a02:a465:9c40::1
post-up ip -6 addr add 2a02:a465:9c40:1::80 dev eth0

Maar daarmee krijg ik geen IPv6 verbinding.
Zowel op 2a02:a465:9c40:1::64 als 2a02:a465:9c40:1::80 kan ik lokaal de webserver die op die doos draait benaderen en ook telnet werkt gewoon op IPv6.

[Snow_King]

Maasluip schreef op donderdag 7 april 2022 @ 08:52:
Met de move van XS4ALL naar KPN heb ik nu ook een nieuw IP-adres gekregen. Ik krijg alleen IPv6 niet op mijn Unbuntu doos geconfigureerd. Ik denk dat het alleen de gateway is die ik goed moet instellen want als ik die fout instel dan hebben sommige website problemen (waarschijnlijk IPv6 als primary connection en IPv4 fallback) en als ik die niet instel heb ik gewoon geen IPv6.
IPv6 op mijn lokaal netwerk werkt wel.

Het is Ubuntu 18.04.5 en ik heb een FritzBox 7490.
Het IPv6 adres van FritzBox had ik voor de vorige verbinding ergens op de configpagina's gevonden (ergens stond een Unique Local Address), maar dat lijkt nu weg te zijn.

In de online monitor staat

Internet, IPv6	
connected since 30.03.2022, 02:22, XS4ALL FTTH,
IPv6 Address: 2a02:a465:9c40::1, Valid for: 236270/149870s,
IPv6 prefix: 2a02:a465:9c40::/48, Valid for: 236270/149870s

Dan dacht ik dat de gateway 2a02:a465:9c40::1 is, dus zet ik dit in mijn /etc/network/interfaces:

code:

#ipv6 configuration
iface eth0 inet6 static
address 2a02:a465:9c40:1::64
netmask 48
gateway 2a02:a465:9c40::1
post-up ip -6 addr add 2a02:a465:9c40:1::80 dev eth0

Maar daarmee krijg ik geen IPv6 verbinding.
Zowel op 2a02:a465:9c40:1::64 als 2a02:a465:9c40:1::80 kan ik lokaal de webserver die op die doos draait benaderen en ook telnet werkt gewoon op IPv6.

Je FritzBox is toch gewoon je router? Die deelt toch via SLAAC gewoon IPv6 adressen uit in je LAN?

Of hangt de Ubuntu doos in bridge modus aan het internet en is dat je router?

[Maasluip]

@Snow_King De Ubuntu doos is zeker niet de router. Maar om via de Fritzbox naar het internet te komen moet ik die toch als gateway instellen?
De Unbutu doos heb ik op een fixed IP gezet (o.a. omdat het mijn webserver is en ik wil daar een domeinnaam aan verbonden hebben).

code:

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.151.64  netmask 255.255.255.0  broadcast 192.168.151.255
        inet6 2a02:a465:9c40:1::80  prefixlen 128  scopeid 0x0<global>
        inet6 2a02:a465:9c40:1::64  prefixlen 48  scopeid 0x0<global>
        inet6 fe80::21f:c6ff:fe52:7fb4  prefixlen 64  scopeid 0x20<link>
        ether 00:1f:c6:52:7f:b4  txqueuelen 1000  (Ethernet)
        RX packets 130051521054  bytes 9719608604133 (9.7 TB)
        RX errors 0  dropped 72219757  overruns 0  frame 0
        TX packets 239616188484  bytes 318683236456502 (318.6 TB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[RobertMe]

Maasluip schreef op donderdag 7 april 2022 @ 11:49:
@Snow_King De Ubuntu doos is zeker niet de router. Maar om via de Fritzbox naar het internet te komen moet ik die toch als gateway instellen?
De Unbutu doos heb ik op een fixed IP gezet (o.a. omdat het mijn webserver is en ik wil daar een domeinnaam aan verbonden hebben).

code:

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.151.64  netmask 255.255.255.0  broadcast 192.168.151.255
        inet6 2a02:a465:9c40:1::80  prefixlen 128  scopeid 0x0<global>
        inet6 2a02:a465:9c40:1::64  prefixlen 48  scopeid 0x0<global>
        inet6 fe80::21f:c6ff:fe52:7fb4  prefixlen 64  scopeid 0x20<link>
        ether 00:1f:c6:52:7f:b4  txqueuelen 1000  (Ethernet)
        RX packets 130051521054  bytes 9719608604133 (9.7 TB)
        RX errors 0  dropped 72219757  overruns 0  frame 0
        TX packets 239616188484  bytes 318683236456502 (318.6 TB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Kun je i.p.v. een static IP niet beter voor automatisch gaan in combinatie met een vaste suffix? Geen idee hoe dat met Debian interfaces config file kan, maar ik heb zelf zoiets in ieder geval in de systemd-networkd config opties zien langs komen.

[Snow_King]

Maasluip schreef op donderdag 7 april 2022 @ 11:49:
@Snow_King De Ubuntu doos is zeker niet de router. Maar om via de Fritzbox naar het internet te komen moet ik die toch als gateway instellen?
De Unbutu doos heb ik op een fixed IP gezet (o.a. omdat het mijn webserver is en ik wil daar een domeinnaam aan verbonden hebben).

code:

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.151.64  netmask 255.255.255.0  broadcast 192.168.151.255
        inet6 2a02:a465:9c40:1::80  prefixlen 128  scopeid 0x0<global>
        inet6 2a02:a465:9c40:1::64  prefixlen 48  scopeid 0x0<global>
        inet6 fe80::21f:c6ff:fe52:7fb4  prefixlen 64  scopeid 0x20<link>
        ether 00:1f:c6:52:7f:b4  txqueuelen 1000  (Ethernet)
        RX packets 130051521054  bytes 9719608604133 (9.7 TB)
        RX errors 0  dropped 72219757  overruns 0  frame 0
        TX packets 239616188484  bytes 318683236456502 (318.6 TB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Je kan een static IPv6 adres instellen, maar de gateway kan je server gewoon leren van de Fritzbox.

Draai op de Ubuntu machine eens het commando:

code:

rdisc6 eth0

Je krijgt dan iets terug als:

code:

Hop limit                 :           64 (      0x40)
Stateful address conf.    :           No
Stateful other conf.      :           No
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :           60 (0x0000003c) seconds
Reachable time            :         3600 (0x00000e10) milliseconds
Retransmit time           :         1000 (0x000003e8) milliseconds
 Source link-layer address: 00:1C:73:3D:79:3D
 MTU                      :         1500 bytes (valid)
 Prefix                   : 2a0b:XXXX:200:100::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :      2592000 (0x00278d00) seconds
  Pref. time              :       604800 (0x00093a80) seconds
 Recursive DNS server     : 2a00:XXXX:ff04:153::53
 Recursive DNS server     : 2a00:XXXX:ff04:253::53
  DNS servers lifetime    :           15 (0x0000000f) seconds
 from fe80::21c:73ff:fe3d:793d

Vervolgens moet je zorgen dat aan staat:

code:

net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.accept_ra_defrtr = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 0

In dit geval zal je Ubuntu server wel via de RA zijn gateway leren, maar geen prefix gebruiken voor een adres genereren. Al kan dat 2e IPv6 adres geen kwaad. Ik gebruik gewoon de dynamische adressen gebaseerd op het MAC adres. Die veranderd toch nooit.

[Maasluip]

rdisc6 eth0:

Soliciting ff02::2 (ff02::2) on eth0...

Hop limit                 :          255 (      0xff)
Stateful address conf.    :           No
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 Prefix                   : 2a02:a465:9c40:1::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :         7200 (0x00001c20) seconds
  Pref. time              :         3600 (0x00000e10) seconds
 Recursive DNS server     : fd00::3631:c4ff:fe8f:ea6
  DNS server lifetime     :         1200 (0x000004b0) seconds
 MTU                      :         1492 bytes (valid)
 Route                    : ::/0
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Route                    : 2a02:a465:9c40::/48
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Source link-layer address: 34:31:C4:8F:0E:A6
 from fe80::3631:c4ff:fe8f:ea6

Die net.ipv6.conf regels heb ik toegevoegd aan /etc/sysctl.conf en daarna de networking service geherstart. Gaf allemaal geen effect.

Mijn windows machine zegt dit:

   Default Gateway . . . . . . . . . : fe80::3631:c4ff:fe8f:ea6%10
                                       192.168.151.220

Ooit een keer het advies gehad om de rechtse 4 hextets van dat global adres aan de linkse 4 van de IPv6 te hangen, dus 2a02:a465:9c40:1:3631:c4ff:fe8f:ea6 als gateway in te stellen.
En daarna kan ik de netwerk service niet meer herstarten. service networking restart geeft

Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.

systemctl status networking.service zegt dit:

code:

● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2022-04-07 13:53:34 CEST; 1min 0s ago
     Docs: man:interfaces(5)
  Process: 10774 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo (code=exited, status=0/SUCCESS)
  Process: 13584 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 13581 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-enviro
 Main PID: 13584 (code=exited, status=1/FAILURE)

apr 07 13:53:34 watcheye systemd[1]: Starting Raise network interfaces...
apr 07 13:53:34 watcheye ifup[13584]: RTNETLINK answers: File exists
apr 07 13:53:34 watcheye ifup[13584]: Failed to bring up eth0.
apr 07 13:53:34 watcheye systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
apr 07 13:53:34 watcheye systemd[1]: networking.service: Failed with result 'exit-code'.
apr 07 13:53:34 watcheye systemd[1]: Failed to start Raise network interfaces.

Ook als ik de gateway weer uit het interfaces file haal blijf ik deze melding houden. IPv6 werkt lokaal nog altijd.
Schiet mij maar lek.

[borft]

Maasluip schreef op donderdag 7 april 2022 @ 13:57:
rdisc6 eth0:

Soliciting ff02::2 (ff02::2) on eth0...

Hop limit                 :          255 (      0xff)
Stateful address conf.    :           No
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 Prefix                   : 2a02:a465:9c40:1::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :         7200 (0x00001c20) seconds
  Pref. time              :         3600 (0x00000e10) seconds
 Recursive DNS server     : fd00::3631:c4ff:fe8f:ea6
  DNS server lifetime     :         1200 (0x000004b0) seconds
 MTU                      :         1492 bytes (valid)
 Route                    : ::/0
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Route                    : 2a02:a465:9c40::/48
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Source link-layer address: 34:31:C4:8F:0E:A6
 from fe80::3631:c4ff:fe8f:ea6

Die net.ipv6.conf regels heb ik toegevoegd aan /etc/sysctl.conf en daarna de networking service geherstart. Gaf allemaal geen effect.

Mijn windows machine zegt dit:

   Default Gateway . . . . . . . . . : fe80::3631:c4ff:fe8f:ea6%10
                                       192.168.151.220

Ooit een keer het advies gehad om de rechtse 4 hextets van dat global adres aan de linkse 4 van de IPv6 te hangen, dus 2a02:a465:9c40:1:3631:c4ff:fe8f:ea6 als gateway in te stellen.
En daarna kan ik de netwerk service niet meer herstarten. service networking restart geeft

Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.

systemctl status networking.service zegt dit:

code:

● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2022-04-07 13:53:34 CEST; 1min 0s ago
     Docs: man:interfaces(5)
  Process: 10774 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo (code=exited, status=0/SUCCESS)
  Process: 13584 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 13581 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-enviro
 Main PID: 13584 (code=exited, status=1/FAILURE)

apr 07 13:53:34 watcheye systemd[1]: Starting Raise network interfaces...
apr 07 13:53:34 watcheye ifup[13584]: RTNETLINK answers: File exists
apr 07 13:53:34 watcheye ifup[13584]: Failed to bring up eth0.
apr 07 13:53:34 watcheye systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
apr 07 13:53:34 watcheye systemd[1]: networking.service: Failed with result 'exit-code'.
apr 07 13:53:34 watcheye systemd[1]: Failed to start Raise network interfaces.

Ook als ik de gateway weer uit het interfaces file haal blijf ik deze melding houden. IPv6 werkt lokaal nog altijd.
Schiet mij maar lek.

Wat gebeurt er als je de interface gewoon op auto zet?

daarnaast, ik denk dat je gateway fe80::3631:c4ff:fe8f:ea6 moet zijn

[Maasluip]

Op dit moment, alles wat ik doe geeft een error bij het herstarten van de networking service. Ook als ik iface eth0 inet6 auto zet.
Ik ben even helemaal kaal gegaan met /etc/network/interfaces. Als ik dit doe dan kan ik het netwerk restarten maar ik heb geen ipv6:

auto lo
iface lo inet loopback

#ipv4 configuration
iface eth0 inet static
address 192.168.151.64
netmask 255.255.255.0
network 192.168.151.0
broadcast 192.168.151.255
gateway 192.168.151.220

#ipv6 configuration
iface eth0 inet6 auto

Maar hier hoort auto eth0 bij. Als ik dat erbij zet krijg ik een foutmelding bij het herstarten van de networking service:

code:

apr 07 15:10:03 watcheye systemd[1]: Starting Raise network interfaces...
apr 07 15:10:03 watcheye ifup[20247]: RTNETLINK answers: File exists
apr 07 15:10:03 watcheye ifup[20247]: Failed to bring up eth0.

code:

$ ping ipv6.google.com
connect: Network is unreachable

[ Voor 3% gewijzigd door Maasluip op 07-04-2022 15:12 ]

[borft]

Maasluip schreef op donderdag 7 april 2022 @ 15:11:
Op dit moment, alles wat ik doe geeft een error bij het herstarten van de networking service. Ook als ik iface eth0 inet6 auto zet.
Ik ben even helemaal kaal gegaan met /etc/network/interfaces. Als ik dit doe dan kan ik het netwerk restarten maar ik heb geen ipv6:

auto lo
iface lo inet loopback

#ipv4 configuration
iface eth0 inet static
address 192.168.151.64
netmask 255.255.255.0
network 192.168.151.0
broadcast 192.168.151.255
gateway 192.168.151.220

#ipv6 configuration
iface eth0 inet6 auto

Maar hier hoort auto eth0 bij. Als ik dat erbij zet krijg ik een foutmelding bij het herstarten van de networking service:

code:

apr 07 15:10:03 watcheye systemd[1]: Starting Raise network interfaces...
apr 07 15:10:03 watcheye ifup[20247]: RTNETLINK answers: File exists
apr 07 15:10:03 watcheye ifup[20247]: Failed to bring up eth0.

code:

$ ping ipv6.google.com
connect: Network is unreachable

Lijkt zo te zien een duidelijke error te geven toch? `File exists` dus blijkbaar is de interface niet down als je hem probeert te starten. kan je niet een ifdown eth0; ifup eth0 doen ofzo?

[nero355]

borft schreef op donderdag 7 april 2022 @ 15:34:
Lijkt zo te zien een duidelijke error te geven toch? `File exists` dus blijkbaar is de interface niet down als je hem probeert te starten. kan je niet een ifdown eth0; ifup eth0 doen ofzo?

Wil ik net posten!

Dit :

RTNETLINK answers: File exists

Betekent dat je de boel DOWN moet brengen, config aanpassen, de boel weer UP brengen!

Irritant, maar helaas veel te vaak mee te maken gehad!

@Maasluip

Verder zou ik denken dat je ping6 of ping -6 moet gebruiken voor IPv6 dingen

/EDIT :

Maasluip schreef op donderdag 7 april 2022 @ 13:57:
Die net.ipv6.conf regels heb ik toegevoegd aan /etc/sysctl.conf en daarna de networking service geherstart. Gaf allemaal geen effect.

Dat doe je trouwens zo :

# sysctl -p 

[ Voor 20% gewijzigd door nero355 op 07-04-2022 15:46 ]

[Snow_King]

Maasluip schreef op donderdag 7 april 2022 @ 15:11:
Op dit moment, alles wat ik doe geeft een error bij het herstarten van de networking service. Ook als ik iface eth0 inet6 auto zet.
Ik ben even helemaal kaal gegaan met /etc/network/interfaces. Als ik dit doe dan kan ik het netwerk restarten maar ik heb geen ipv6:

auto lo
iface lo inet loopback

#ipv4 configuration
iface eth0 inet static
address 192.168.151.64
netmask 255.255.255.0
network 192.168.151.0
broadcast 192.168.151.255
gateway 192.168.151.220

#ipv6 configuration
iface eth0 inet6 auto

Maar hier hoort auto eth0 bij. Als ik dat erbij zet krijg ik een foutmelding bij het herstarten van de networking service:

code:

apr 07 15:10:03 watcheye systemd[1]: Starting Raise network interfaces...
apr 07 15:10:03 watcheye ifup[20247]: RTNETLINK answers: File exists
apr 07 15:10:03 watcheye ifup[20247]: Failed to bring up eth0.

code:

$ ping ipv6.google.com
connect: Network is unreachable

Ik zou de machine even rebooten voor de zekerheid, maar in principe moet dat voldoende zijn.

code:

sysctl -a|grep ipv6|grep eth0|grep accept_

Zie je daar oa accept_ra=1 dan wel staan?

Want je moet dan vervolgens een IPv6 adres krijgen en ook een default gateway zien met:

code:

ip -6 route show

[Maasluip]

borft schreef op donderdag 7 april 2022 @ 15:34:
[...]


kan je niet een ifdown eth0; ifup eth0 doen ofzo?

code:

# ifdown eth0
ifdown: interface eth0 not configured

ifup eth0 geeft ook die melding RTNETLINK answers: File exists

[ Voor 12% gewijzigd door Maasluip op 07-04-2022 15:54 ]

[borft]

Maasluip schreef op donderdag 7 april 2022 @ 15:54:
[...]

code:

# ifdown eth0
ifdown: interface eth0 not configured

ifup eth0 geeft ook die melding RTNETLINK answers: File exists

Ah, dan is eth0 dus door iets ander geconfigureerd, want hij kan hem niet down brengen.

[Snow_King]

borft schreef op donderdag 7 april 2022 @ 16:00:
[...]


Ah, dan is eth0 dus door iets ander geconfigureerd, want hij kan hem niet down brengen.

Dan kan je ook doen:

code:

ip addr show dev eth0
ip link set down dev eth0

Uiteindelijk kan je met het 'ip' commando ongeveer alles rondom network in Linux :-)

[borft]

Snow_King schreef op donderdag 7 april 2022 @ 16:05:
[...]

Dan kan je ook doen:

code:

ip addr show dev eth0
ip link set down dev eth0

Uiteindelijk kan je met het 'ip' commando ongeveer alles rondom network in Linux :-)

Jep, en gelijk ook een stuk moderner dan ifconfig

[Maasluip]

Snow_King schreef op donderdag 7 april 2022 @ 16:05:
[...]

code:

ip addr show dev eth0
ip link set down dev eth0

Nou, in combinatie met sysctl -p deed dat wel wat, maar niet alles...
Ik heb tenminste een route via IPv6

code:

$ ip -6 route show
fe80::/64 dev eth0 proto kernel metric 256 pref medium

Maar geen IPv6 IP adres:

code:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.151.64  netmask 255.255.255.0  broadcast 192.168.151.255
        inet6 fe80::21f:c6ff:fe52:7fb4  prefixlen 64  scopeid 0x20<link>

Een IPv6 host pingen geeft geen network unreachable maar gaat ook niet goed.

code:

$ ping ipv6.google.com
PING ipv6.google.com(ams15s48-in-x0e.1e100.net (2a00:1450:400e:811::200e)) 56 data bytes
From _gateway (fe80::3631:c4ff:fe8f:ea6%eth0) icmp_seq=1 Destination unreachable: Beyond scope of source address
From _gateway (fe80::3631:c4ff:fe8f:ea6%eth0) icmp_seq=2 Destination unreachable: Beyond scope of source address
From _gateway (fe80::3631:c4ff:fe8f:ea6%eth0) icmp_seq=3 Destination unreachable: Beyond scope of source address

Toch nog eens proberen om een static IPv6 adres te zetten?

[Snow_King]

Maasluip schreef op donderdag 7 april 2022 @ 16:15:
[...]

Nou, in combinatie met sysctl -p deed dat wel wat, maar niet alles...
Ik heb tenminste een route via IPv6

code:

$ ip -6 route show
fe80::/64 dev eth0 proto kernel metric 256 pref medium

Maar geen IPv6 IP adres:

code:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.151.64  netmask 255.255.255.0  broadcast 192.168.151.255
        inet6 fe80::21f:c6ff:fe52:7fb4  prefixlen 64  scopeid 0x20<link>

Een IPv6 host pingen geeft geen network unreachable maar gaat ook niet goed.

code:

$ ping ipv6.google.com
PING ipv6.google.com(ams15s48-in-x0e.1e100.net (2a00:1450:400e:811::200e)) 56 data bytes
From _gateway (fe80::3631:c4ff:fe8f:ea6%eth0) icmp_seq=1 Destination unreachable: Beyond scope of source address
From _gateway (fe80::3631:c4ff:fe8f:ea6%eth0) icmp_seq=2 Destination unreachable: Beyond scope of source address
From _gateway (fe80::3631:c4ff:fe8f:ea6%eth0) icmp_seq=3 Destination unreachable: Beyond scope of source address

Toch nog eens proberen om een static IPv6 adres te zetten?

Je hebt enkel een link-local IPv6 adres, welke je standaard al hebt.

Je zou gewoon een IPv6 adres in je Ubuntu (VM?) moeten krijgen. Ik vind het wel raar, want alle settings staan gewoon goed.

rdisc6 geeft aan dat er een router zou moeten zijn.

[Maasluip]

Wat nog vervelender is: er is nu totaal geen verbinding met het internet meer. ping 8.8.8.8 geeft connect: Network is unreachable.


Statisch adres zetten werkt ook niet.
En de Ubuntu machine is geen virtual machine.

[ Voor 24% gewijzigd door Maasluip op 07-04-2022 16:22 ]

[Snow_King]

Maasluip schreef op donderdag 7 april 2022 @ 16:20:
Wat nog vervelender is: er is nu totaal geen verbinding met het internet meer. ping 8.8.8.8 geeft connect: Network is unreachable.


Statisch adres zetten werkt ook niet.
En de Ubuntu machine is geen virtual machine.

Welke Ubuntu versie is het? Zou je niet netplan moeten gebruiken?

De interfaces file is in Ubuntu deprecated.

Met netplan alles op auto zetten zou voldoende moeten zijn.

[Maasluip]

@Snow_King 18.04.5
Ik dacht dat netplan pas later kwam, ik heb ook niets in /etc/netplan

[mrdemc]

Maasluip schreef op donderdag 7 april 2022 @ 16:20:
Wat nog vervelender is: er is nu totaal geen verbinding met het internet meer. ping 8.8.8.8 geeft connect: Network is unreachable.


Statisch adres zetten werkt ook niet.
En de Ubuntu machine is geen virtual machine.

hoe ziet je routing tabel eruit dan voor 4 en 6?

[Maasluip]

Halleluja, het is gelukt.

Ik heb een RPi met 21.04 en ik weet dat die wel via netplan geconfigureerd wordt. Dus dat netplan gekopieerd en aangepast en direkt werken.

code:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      dhcp6: no
      addresses:
        - 192.168.151.64/24
        - 2a02:a465:9c40:1::64/48
        - 2a02:a465:9c40:1::80/48
      gateway4: 192.168.151.220
      gateway6: 2a02:a465:9c40:1:3631:c4ff:fe8f:ea6 
      nameservers:
        addresses: [194.109.6.66, 194.109.9.99, 194.109.104.104]

netplan apply
systemctl restart network-manager

Zo te zien is er verbinding vanaf buiten, ik kan met de browser naar mijn hostname, ik krijg weer traffic binnen.

Weer twee grijze haren erbij

[nero355]

@Maasluip

Dit wilde ik ook nog posten :

Snow_King schreef op donderdag 7 april 2022 @ 16:38:
Zou je niet netplan moeten gebruiken?

Helemaal vergeten...

Maasluip schreef op donderdag 7 april 2022 @ 16:54:
Weer twee grijze haren erbij

Sorry!

[Snow_King]

Maasluip schreef op donderdag 7 april 2022 @ 16:54:
Halleluja, het is gelukt.

Ik heb een RPi met 21.04 en ik weet dat die wel via netplan geconfigureerd wordt. Dus dat netplan gekopieerd en aangepast en direkt werken.

code:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      dhcp6: no
      addresses:
        - 192.168.151.64/24
        - 2a02:a465:9c40:1::64/48
        - 2a02:a465:9c40:1::80/48
      gateway4: 192.168.151.220
      gateway6: 2a02:a465:9c40:1:3631:c4ff:fe8f:ea6 
      nameservers:
        addresses: [194.109.6.66, 194.109.9.99, 194.109.104.104]

netplan apply
systemctl restart network-manager

Zo te zien is er verbinding vanaf buiten, ik kan met de browser naar mijn hostname, ik krijg weer traffic binnen.

Weer twee grijze haren erbij

Top! Maar die gateway6 zou niet hoeven. Die moet je RPi gewoon via de Router Advertisement leren.

Dat is nog een kleine change die je kan maken.

Maar, onder Ubuntu 18.04 moet het ook kunnen werken. IPv6 werkt al jaaaaaaaren onder Linux.

Je kan ook systemd-networkd gebruiken, maar de standaard interfaces file moet ook afdoende zijn.

[aawe mwan]

Ubuntu 21.10 (64 bits) op de Pi400 heb ik een paar weken geleden geupgrade naar 22.04, omdat het kon (want deze versie is officieel nog niet gereleased).

Bij het upgradeproces werd de vaste IPv6 adres instelling spontaan geconverteerd naar privacy adressen. Gelukkig lijken die nu eindelijk goed te werken: de Pi is altijd bereikbaar op alle IPv6 adressen die hij heeft volgens zijn eigen landscape-sysinfo en dat zijn dezelfde IPv6 adressen als die hij heeft volgens de FRITZ!Box. Hij is ook gewoon bereikbaar onder zijn netwerknaam op het wisselende IPv6 privacy adres.

Kernel release: 5.15.0-1004-raspi

[jvhaarst]

jvhaarst schreef op donderdag 31 maart 2022 @ 20:45:
Het lijkt er op dat Ziggo aan het testen is om hier (fUPC) gebied IPv6 uit te rollen (of iemand heeft een foutje gemaakt).
Mijn Fritz!Box (achter een bridged modem) kreeg vanmorgen een IPv6 adres, en ook een paar hosts kregen een adres :[Afbeelding]

Nu is alles weer alleen IPv4, ik heb alleen een ander IPv4 adres dan voorheen.

En sinds gisternacht lijk ik een stabiele IPv6 verbinding te hebben, zijn er meer mensen in fUPC gebied die nu dualstack hebben ?

[CeesBak]

@borft @nero355 @valkenier

Na veel zoeken naar de vertragingen in NextCloud denk ik dat ik het probleem heb gevonden. Wanneer je een certificaat aanvraag met Certbot wordt mij de vraag gesteld of ik www.mydomain.com of mydomain.com moet worden gecertificeerd. Ik heb steeds gekozen voor alleen www.mydomain.com. Na wat experimenteren door de www weg te laten heb ik eens gekozen voor allebei, dus zowel met www en zonder www. Het zou volgens velen niet in IPv6 zitten wat hiermee ook aangetoond is.

En zie voila, het probleem is over. Dank voor de suggesties.

[ Voor 3% gewijzigd door CeesBak op 10-04-2022 17:24 ]

[borft]

CeesBak schreef op zondag 10 april 2022 @ 17:23:
@borft @nero355 @valkenier

Na veel zoeken naar de vertragingen in NextCloud denk ik dat ik het probleem heb gevonden. Wanneer je een certificaat aanvraag met Certbot wordt mij de vraag gesteld of ik www.mydomain.com of mydomain.com moet worden gecertificeerd. Ik heb steeds gekozen voor alleen www.mydomain.com. Na wat experimenteren door de www weg te laten heb ik eens gekozen voor allebei, dus zowel met www en zonder www. Het zou volgens velen niet in IPv6 zitten wat hiermee ook aangetoond is.

En zie voila, het probleem is over. Dank voor de suggesties.

Wat bedoel je met "het zou niet in ipv6 zitten" en wat is er aangetoond? het wel of niet ondersteunen van je domain apex is een eigenschap van DNS, niet zozeer van ipv6 lijkt me. De vraag is natuurlijk waar je siet op draait, met of zonder www, en hoe je webserver geconfigureerd is.

[Snow_King]

jvhaarst schreef op donderdag 31 maart 2022 @ 20:45:
Het lijkt er op dat Ziggo aan het testen is om hier (fUPC) gebied IPv6 uit te rollen (of iemand heeft een foutje gemaakt).
Mijn Fritz!Box (achter een bridged modem) kreeg vanmorgen een IPv6 adres, en ook een paar hosts kregen een adres :[Afbeelding]

Nu is alles weer alleen IPv4, ik heb alleen een ander IPv4 adres dan voorheen.

Ik had uit goede bronnen ook al vernomen dat Ziggo hier druk mee bezig is. Het verbaasd mij dan ook niet.

[Dreamvoid]

IPv6 Prefix Delegation maakt eigenlijk die hele vrije routerkeuze discussie overbodig. Iedereen lekker een /56 en een providerbox (die de provider kan beheren, updaten, IPTV en VOIP eraan hangen, etc), en dan kan iedereen die dat wil daarachter welke knutselrouter ook zetten met een /57. Iedereen blij.

[CeesBak]

Helemaal duidelijk is het ook niet voor mij. Mijn domein van mijn hosting provider is laten we aannemen me.nl. toch blijkt het goed te werken met www.me.nl. Op een of andere manier wordt het heel traag als je www wel of niet gebruikt.

Vervolgens pas ik mijn certificaat aan zodat het zowel www.me.nl als me.nl certificeert.Na veel testen blijkt het nu allemaal niet te vertragen. Dus lijkt het te werken. Heb ik dit goed begrepen? tja dat weet ik niet.

Nu nog maar één probleem over. Hoe ga je om met wisselende prefixes in IPv6, Komt ook wel weer goed.

borft schreef op maandag 11 april 2022 @ 09:27:
[...]
Wat bedoel je met "het zou niet in ipv6 zitten" en wat is er aangetoond? het wel of niet ondersteunen van je domain apex is een eigenschap van DNS, niet zozeer van ipv6 lijkt me. De vraag is natuurlijk waar je siet op draait, met of zonder www, en hoe je webserver geconfigureerd is.

[Roetzen]

Dreamvoid schreef op woensdag 13 april 2022 @ 17:36:
IPv6 Prefix Delegation maakt eigenlijk die hele vrije routerkeuze discussie overbodig. Iedereen lekker een /56 en een providerbox (die de provider kan beheren, updaten, IPTV en VOIP eraan hangen, etc), en dan kan iedereen die dat wil daarachter welke knutselrouter ook zetten met een /57. Iedereen blij.

In een IPv6 only wereld zou dat werken ja....

[RobertMe]

Dreamvoid schreef op woensdag 13 april 2022 @ 17:36:
IPv6 Prefix Delegation maakt eigenlijk die hele vrije routerkeuze discussie overbodig. Iedereen lekker een /56 en een providerbox (die de provider kan beheren, updaten, IPTV en VOIP eraan hangen, etc), en dan kan iedereen die dat wil daarachter welke knutselrouter ook zetten met een /57. Iedereen blij.

Voor internet, wellicht, als je ook telefonie afneemt moet dat dan alsnog via het modem blijven verlopen aangezien je zonder vrije modemkeuze de SIP gegevens niet krijgt. Daarnaast is het v.w.b. energierekening waarschijnlijk ook fijner als je één apparaat minder nodig hebt of bv de energieslurpende Gigabox kunt vervangen door een zuiniger model.

[Dreamvoid]

CeesBak schreef op woensdag 13 april 2022 @ 17:41:
Nu nog maar één probleem over. Hoe ga je om met wisselende prefixes in IPv6, Komt ook wel weer goed.

Zelfde als met wisselende IPv4 adressen: Dynamic DNS.

[Snow_King]

Dreamvoid schreef op woensdag 13 april 2022 @ 17:36:
IPv6 Prefix Delegation maakt eigenlijk die hele vrije routerkeuze discussie overbodig. Iedereen lekker een /56 en een providerbox (die de provider kan beheren, updaten, IPTV en VOIP eraan hangen, etc), en dan kan iedereen die dat wil daarachter welke knutselrouter ook zetten met een /57. Iedereen blij.

Soort van, maar niet helemaal. Want die router van de ISP is niet altijd even stabiel. Zo was/is de Horizonbox van Ziggo een drama. Ik had echt allemaal rare uitval en drops er mee.

Sinds ik mijn modem in bridge heb (Ziggo Zakelijk Pro) en daar een Mikrotik router achter heb zijn echt al die problemen verleden tijd.

Je weet nooit wat die ISP routers eigenlijk allemaal uitspoken en daarom heb je die niet altijd graag in de keten zitten.

[ReBr]

Sinds enige tijd ben ik overgestapt naar een glasvezelaanbieder, waar momenteel alleen ipv4 beschikbaar is, terwijl ik voorheen op mn DSL aansluiting wel native ipv6 beschikbaar had. (schijnbaar zijn ze wel ipv6 ready, maar nog niet geactiveerd voor de eindgebruikers)

Maar enkele apparaten in huis wil ik wel graag extern benaderen via ipv6, dus maar weer een 6in4 tunnel van Hurricane Electric ingesteld.
Dit werkte wel goed, maar toch wel beetje de bekende problemen, zoals traag, en niet stabiel, en soms blokkades.

Op zoek naar een alternatief, uitgekomen bij route48.org
Hier iets meer info, website van route48.org zelf staat nog niet zo heel veel informatie op : https://lowendspirit.com/...bled-tunnelbroker-service

Iemand hiermee ook al ervaringen?

Zelf heb ik het momenteel in gebruik, een tunnel via Steenbergen NL.
Tot nu toe, zeer tevreden, alles werkt goed, en snel

[zx9r_mario]

ReBr schreef op donderdag 21 april 2022 @ 22:16:
Sinds enige tijd ben ik overgestapt naar een glasvezelaanbieder, waar momenteel alleen ipv4 beschikbaar is, terwijl ik voorheen op mn DSL aansluiting wel native ipv6 beschikbaar had. (schijnbaar zijn ze wel ipv6 ready, maar nog niet geactiveerd voor de eindgebruikers)

Maar enkele apparaten in huis wil ik wel graag extern benaderen via ipv6, dus maar weer een 6in4 tunnel van Hurricane Electric ingesteld.
Dit werkte wel goed, maar toch wel beetje de bekende problemen, zoals traag, en niet stabiel, en soms blokkades.

Op zoek naar een alternatief, uitgekomen bij route48.org
Hier iets meer info, website van route48.org zelf staat nog niet zo heel veel informatie op : https://lowendspirit.com/...bled-tunnelbroker-service

Iemand hiermee ook al ervaringen?

Zelf heb ik het momenteel in gebruik, een tunnel via Steenbergen NL.
Tot nu toe, zeer tevreden, alles werkt goed, en snel

Ik heb route48 getest met wireguard. Als je Steenbergen kiest, krijg je een subnet via NFORCE

[schroevendraaier480]

ReBr schreef op donderdag 21 april 2022 @ 22:16:
Sinds enige tijd ben ik overgestapt naar een glasvezelaanbieder, waar momenteel alleen ipv4 beschikbaar is, terwijl ik voorheen op mn DSL aansluiting wel native ipv6 beschikbaar had. (schijnbaar zijn ze wel ipv6 ready, maar nog niet geactiveerd voor de eindgebruikers)

Maar enkele apparaten in huis wil ik wel graag extern benaderen via ipv6, dus maar weer een 6in4 tunnel van Hurricane Electric ingesteld.
Dit werkte wel goed, maar toch wel beetje de bekende problemen, zoals traag, en niet stabiel, en soms blokkades.

Op zoek naar een alternatief, uitgekomen bij route48.org
Hier iets meer info, website van route48.org zelf staat nog niet zo heel veel informatie op : https://lowendspirit.com/...bled-tunnelbroker-service

Iemand hiermee ook al ervaringen?

Zelf heb ik het momenteel in gebruik, een tunnel via Steenbergen NL.
Tot nu toe, zeer tevreden, alles werkt goed, en snel

Ik was niet bekend met route48, en heb vandaag maar eens een tunnel aangeslingerd en de Tunnelbroker.net (HE) tunnel uitgezet.

Eerste indruk is inderdaad dat alles naar behoren werkt. Bandbreedte is beter dan bij HE, latency is iets minder (op mijn VDSL 9 ms voor HE en 12 ms voor Route48). Nog geen content blokkades op een aantal streaming diensten. Dus so far so good.
Ik ben met name benieuwd naar de werkdagen, Bij HE kakte de bandbreedte daar overdag echt in en was er ook iets meer latency te zien.

Voor nu postief en alles werkt redelijk snappy.

edit 13.22
nog vergeten, tunnel wordt getermineerd op een Mikrotik RB750GR3 (7.2.1) en ik heb cake QoS ingesteld om bufferbloat tegen te gaan.

[ Voor 4% gewijzigd door schroevendraaier480 op 24-04-2022 13:27 ]

[schroevendraaier480]

Voor nu postief en alles werkt redelijk snappy.

edit 13.22
nog vergeten, tunnel wordt getermineerd op een Mikrotik RB750GR3 (7.2.1) en ik heb cake QoS ingesteld om bufferbloat tegen te gaan.

toch weer terug naar HE. Route48 tunnel viel in 1 etmaal 6 keer weg (o.a. tijdens F1 race) plus latency die toch wel hoger bleek dan bij HE.

Maar het is goed om te weten dat er een alternatief is, mocht HE stoppen met het aanbieden van gratis tunnels.

[ericafterdark]

zx9r_mario schreef op donderdag 21 april 2022 @ 23:44:
[...]


Ik heb route48 getest met wireguard. Als je Steenbergen kiest, krijg je een subnet via NFORCE

Wat is er mis met NFOrce? Ik heb ontzettend goede ervaringen met die partij.

[Snow_King]

Gisteren verbond ik de MacBook van mijn vrouw via de hotspot van haar iPhone 13 om even iets te doen op internet.

Ik zag toen ineens dat de MacBook een native IPv6 adres had!

Ze heeft KPN als mobiele provider en dat die IPv6 op mobiel aanbied wist ik al. Wat nieuw was voor mij is dat de hotspot functie het ook doet.

De telefoon krijgt via 5G een /64 via Prefix Delegation en kan deze dus weer gebruiken voor zijn hotspot functie.

Mooi om te zien dat dit gewoon werkt!

Nu Vodafone nog…. Eerder al gehoord dat het technisch er allemaal klaar voor is, dat enkel de provisioning daar nog moet. Daar zit echter geen haast achter omdat het geen commercieel belang dient. De business case ontbreekt om er tijd in te steken…