Op avontuur: Mijn thuisnetwerk omnummeren

Zoals 99% van de rest van de wereld draaide ik mijn thuis netwerk op de IP-reeks 192.168.1.x. Normaliter geen probleem, het is er voor gemaakt. Deze reeks is op internet gemaakt om niet te conflicteren. Bij Always-on VPN op clients loop je er echter tegenaan dat dat niet routeert wanneer het gasten netwerk waar je mee verbindt dezelfde reeks heeft. Tijd om naar een willekeurige 10.x.x.x reeks te migreren dus. Iets wat ik al lang voor me uit aan het schuiven was omdat er vast dingen hard op IP adressen geconfigureerd zullen zijn. Dus overstappen van netwerkreeks betekent goed nadenken, goed voorbereiden en daarna onvermijdelijk puin ruimen. Afhankelijk van hoe goed je nagedacht hebt zal de hoeveelheid meer of minder zijn 😅.

• Dan maar beginnen: Dood of de gladiolen!
• Stap 0: Een overzicht maken
• Stap 1: Devices met vaste IPs omnummeren
• Stap 2: De gateway omnummeren
  • Probleem 1: Unifi staat geen omnummeren toe met vage foutmelding
• Stap 3: Inventariseren wat er allemaal is meegekomen
• Stap 4: Wat mist gaan we 1 voor 1 proberen te fixen
  • Probleem 2: Alle Docker services lijken onbereikbaar
  • Probleem 3: Docker-compose hangt bij sommige containers op unixHTTPConnectionPool timeout meldingen
• Probleem 4: Bad gateway op sommige eigen diensten
• Probleem 5: Lampen en stofzuiger missen in Home Assistant
• Probleem 6: Lametric in Node-RED
• Probleem 6: Telefoonbackups herstellen.
• Probleem 7: Screensaver op SHIELD werkt niet meer
• Dat was hem dan voor nu
• Booschappenlijst: Zaken op IP-basis die ik heb aangetroffen

Dan maar beginnen: Dood of de gladiolen!

Gisteren had ik dan eindelijk besloten dat ik het niet langer kon uitstellen en ben ik begonnen. Een spannend moment want het voelt altijd alsof je een lange eenrichtingsweg in gaat. Er is geen weg terug: hoe dieper de ellende, hoe meer werk je zal hebben aan het herstel. Op een bepaald moment is terugkeer gewoon geen optie meer! 🙈 ¹

Ook deze keer stelde niet teleur, het werd een spannende rit. Hier ongeveer de stappen die ik nam en de ontdekkingen die ik deed. Op het eind een boodschappenlijst van zaken die dus (blijkbaar of verwacht) hard op IP waren ingesteld in mijn netwerk. Die boodschappenlijst is bedoeld om mij (en iedereen die er wat aan heeft) de volgende keer een houvast te geven met een aantal te verwachten zaken en inspiratie om over na te denken.

Goed, let’s go!

Stap 0: Een overzicht maken

Eigenlijk wilde ik bij stap 1 beginnen, maar bedacht net op het laatste moment dat ik liever bij Stap 0 start:

• Wat heb ik nu;
• Waar ga ik heen;

Later terugkijken gaat niet, dus nú inventariseren. Ik heb besloten eerst een {PHP}IPAM omgeving op te bouwen. Een product dat bedoelt is om een administratie van IP adressen in je netwerk op te bouwen. Er zit een scan-functie in. Deze heb ik gebruikt en heb vervolgens alle gevonden IPs die me belangrijk leken opgenomen in de database. Dat is handig, want bij de volgende stap kan ik in mijn netwerk gewoon find and replace doen op 192.168.1. naar 10.x.x. en dan zou de oude omgeving ongeveer hersteld moeten zijn. Sowieso wilde ik dit al langer een keer fixen en dit was een goede reden om me er toe te zetten.

Stap 1: Devices met vaste IPs omnummeren

Stap 1 is the obvious eerste stap: de devices waar de IP adressen hard in staan zelf omnummeren naar de nieuwe reeks. Voor mij waren dit mijn Docker-host en mijn netwerk devices. De rest werkt via DHCP-reserveringen dus die krijg ik straks eenvoudig aangepast.

Stap 2: De gateway omnummeren

Dit is natuurlijk eigenlijk de laatste stap van stap 1, maargoed. Dit is het punt dat je je router of gateway om gooit, je neemt je DHCP reeksen etc mee. Dit is het moment dat dingen spannend beginnen te worden. Bij fouten is je internet weg en moet je echt aan de bak.

Probleem 1: Unifi staat geen omnummeren toe met vage foutmelding

Het begon bij mij op de Unifi omgeving dat ik mijn eerste echte probleem vond:
There was an error saving the LAN network. "192.168.x.x" is an invalid fixed IP.
Dat is vaag, als ik mijn LAN wil omnummeren krijg ik echt een vreemde melding met een oud IP erin en hij wil de wijzigingen dan ook niet bewaren of doorvoeren?

Wat googlewerk brengt veel vage oplossingen, maar ook 1 die bij mij succesvol blijkt: Je moet de IP reserveringen in de DHCP scope verwijderen. Met reserveringen kan je niet omnummeren 🤨.

Na deze fix lukte het dus wel. Daar gaan we, de infra gaat om: We’re not in Kansas anymore!

Stap 3: Inventariseren wat er allemaal is meegekomen

Daar gaat de bliksemse bende dan. Mijn IP renewen op mijn werkplek en ik zit op de nieuwe reeks. Snel op de router inloggen en ik zie dat de AP en Switch ook weer gezien worden. In het overzicht mis ik nog een flink aantal machines, maar dat zal langzaam goedkomen wanneer de leases verstrijken, of eerder wanneer ik reboots forceer 😇.

Een vlot rondje door het huis zorgt voor een goed gevulde DCHP-scope. We komen ergens. Zorgelijk is dat ik merk dat mijn Docker host goed mee is gekomen, maar alle diensten erop blijken onbereikbaar.

Hier begint de volgende stap:

Stap 4: Wat mist gaan we 1 voor 1 proberen te fixen

Probleem 2: Alle Docker services lijken onbereikbaar

Ik kan bij geen enkele op Docker gehoste dienst bij lijkt initieel het geval te zijn. Na verloop van tijd wordt me echter duidelijk dat ik alleen niet bij dingen die door Traefik heen moeten kan. Als ik bijvoorbeeld de backend van Traefik benader als poort-nummer op de Docker-host kan ik er wel bij. Hmm…

Eerst maar eens naar mijn Traefik container kijken dan. Die moppert bij het opstarten over issues met het netwerk. Ik besluit om mijn externe netwerk in Docker weg te gooien. Aanmaken kost een paar seconden en wellicht zit er ergens een nummer of reeks in (achteraf is het twijfelachtig of dit een wijze stap was). Met wat rommelen krijg ik Traefik goed aan de gang, maar mijn docker-compose up -d run levert niet veel extra machines op. Meteen wordt er geklaagd dat de containers hun specifieke netwerk niet meer kunnen vinden.

Dit kan ik oplossen door de containers een geforceerde rebuild te geven (docker-compose up -d --force-rebuild).

Probleem 3: Docker-compose hangt bij sommige containers op unixHTTPConnectionPool timeout meldingen

Dan stuit ik op het volgende probleem, en deze blijkt naar! Als ik sommige containers probeer op te starten krijg ik deze melding:
unixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

En soms deze:
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

Deze zijn een flink stuk serieuzer. Allereerst voelt het bijzonder random aan: sommige containers werken, bij andere gaat het dus serieus heftig mis. Bij googlen naar dit probleem vind ik eigenlijk maar 2 stromingen.

De eerste lijkt te suggereren dat je machine te dun in zijn hardware zit. Eerste advies is minder containers tegelijk opstarten en tweede advies om de timeouts op te hogen.
Dat lijkt me dus niets. Ook als ik ze 1 voor 1 start gebeurt het en het is consequent gedrag…

De tweede lijkt te suggereren dat het issues in het Docker systeem zijn geweest, met name op Mac. Veelal staat hierbij de status op fixed omdat het in latere versies is gefixt. Ook dit lijkt hem niet te zijn: Ik draai de “latest and greatest” en ook dit verklaart het grillige gedrag niet…

Hier droogt Google een beetje op. De container welke alfabetisch de eerste was heeft veel nuts & bolts, dus er valt aardig wat mee te experimenteren. Het levert alleen niet veel resultaat op.
Ik geef het een beetje op en tref een hele eenvoudige container aan zonder veel mogelijkheden en parameters: deze is heel erg rechttoe rechtaan. Dat experimenteert een stuk lekkerder maar het mag niet baten, ik krijg er geen leven in.

Ineens besef ik me dat de container waar ik mee bezig ben gebruikt maakt van een NFS mapping van de host met mijn storage. Bij controle blijkt deze mapping er niet te zijn! Vreemd, want ik heb specifiek op voorhand wel de NFS permissies op mijn storage aangepast…
Wacht eens, hebbes! De fstab moet dan natuurlijk wel aangepast worden, die mount op IP nummer nu 🤓.
En ja hoor! Na de aanpassing krijg ik de container gestart. Wat nog meer is: De rest van de niet werkende containers ook!

De foutmeldingen hierboven kwamen dus doordat de containers probeerden een NFS mapping van de host te gebruiken, bij herstel was het meteen opgelost.

Probleem 4: Bad gateway op sommige eigen diensten

Na deze doorbraak zijn we meteen een heel eind verder! Ik start mijn bookmark verzameling naar mijn interne diensten op en komt tot een redelijk aantal, toch zijn er ook een stel met Bad gateway. Daar zie ik wel direct wat de overeenkomst is: Het zijn diensten die ik op basis van IP Whitelisting beschikbaar stel. Jup, daar moet ik mijn whitelists aanpassen naar mijn nieuwe eigen netwerk reeks. Helaas blijkt dit niet afdoende te zijn.

Een docker network inspect levert hier de oplossing. Het opnieuw aanmaken van het externe netwerk bij probleem 2 heeft er voor gezorgd dat deze nieuwe IPs hebben, deze zijn van 172.20.x.x naar 172.18.x.x gegaan.

Met die wijzigingen meegenomen ben ik er wel. Verreweg het meeste in huis blijkt te werken!

Probleem 5: Lampen en stofzuiger missen in Home Assistant

In Home Assistant waren koppelingen weg. Deze was lekker simpel: Hiervoor moest ik harde ip adressen in de config files aanpassen en de Hue bridge een keer echt herstarten.

Probleem 6: Lametric in Node-RED

In Node-RED is de Lametric koppeling de enige die op basis van IP plaats vindt. Deze moest ik dus ook aanpassen.

Probleem 6: Telefoonbackups herstellen.

Ik draai een automatische backup van de foto’s en files op onze mobiele telefoons, in dat backup pakket zitten harde SMB connecties. Omnummeren en klaar. De tool die ik gebruik op Android is overigens geweldig, dit was ooit een tip van Andries en gaat al vele jaren mee: FolderSync

Probleem 7: Screensaver op SHIELD werkt niet meer

Op de NVIDIA SHIELD gebruik ik PhotoGuru Media Player om onze foto’s als screensaver te gebruiker. Dit pakket heeft een CIFS koppeling op basis van IP.

Dat was hem dan voor nu

Voorlopig denk ik dat ik de issues nu wel gehad heb, alhoewel ik er niet van op zou kijken als ik nog wat kleine dingetjes aantref. Ik blijf nog even waakzaam dus 😉.

Al met al ben ik hier wel een uur of 4 mee bezig geweest. Meestal voelde het allemaal wel okay, maar met die docker-compose ellende heb ik het na een tijd wel benauwd gekregen. Het is naar om op vage schijnbaar onoverkomelijke problemen te stuiten. Maar wat ben je dan blij als je het opgelost hebt! 🥳

Zoals aangekondigd sluit ik af met een referentielijstje voor als ik in de toekomst weer eens hetzelfde in mijn hoofd zou halen.

Booschappenlijst: Zaken op IP-basis die ik heb aangetroffen

• NFS permissies op mijn storage (voor Docker host en voor Shield);
• Om een ipreeks in UniFi aan te passen mag deze geen IP reserveringen meer hebben;
• NFS Mappings op mijn Docker host (fstab);
• NFS Mappings op SHIELD (mediafiles vanaf de storage);
• IP Whitelist bij externe en interne diensten in Traefik;
• De verbindingen met de stofzuiger en verlichting vanuit Home Assistant;
• Lametric connectie in Node-RED;
• De backups van de telefoons zijn naar het IP van de storage;