Networking / Automation

One Source of Truth for a Dynamic Home IP, Because All Five Copies Break at Once

A residential IP address is not contractually static, and mine had quietly accumulated five independent hardcoded copies across the fleet. That is not a tidiness problem. It is an outage waiting for an ISP to renumber, because all five break at the same moment and produce symptoms that look completely unrelated to each other and to the cause.

What the failure actually looks like

Here is the real list, and the point is how little these have in common:

Where the address was hardcoded	Symptom when it goes stale
Firewall rule, SSH	You cannot log into a public host
Firewall rule, monitoring agent port	Monitoring goes CRIT, the host looks down
Reverse proxy backend for one API path	A website's contact form starts returning 502
Analytics dashboard client-IP allowlist	The dashboard 404s from your own LAN
Cloud provider API key ACL	API calls fail with an auth error
A DNS-only A record	Inbound mail or a service stops resolving correctly

Nobody debugging "the contact form is down" naturally connects it to "the analytics dashboard 404s". You end up diagnosing six unrelated incidents that share one cause, on the day your ISP happened to renumber you.

The design decision that matters

The source of truth is the live egress IP, not a file. The tempting design is a config file holding the current address, with everything else generated from it. That is worse than it looks. A file someone has to remember to edit is just a sixth copy that can drift, and it drifts silently because nothing validates it against reality.

Detect the real current address every run, compare it to what was last propagated, and reconcile the difference. Keep a state file if you like, but it records what you did, not what is true. That distinction is what lets you report a change rather than silently apply one.

Fail closed, with a resolver quorum

This automation writes firewall rules on public hosts. A wrong value locks you out of your own infrastructure, so it has to be safer than the problem it solves:

# three independent resolvers, at least two must agree
for r in https://api.ipify.org https://ifconfig.me https://icanhazip.com; do
  curl -fsS --max-time 5 "$r"; echo
done | sort | uniq -c | sort -rn | head -1

If two of three do not agree on the same address, log it and exit without changing anything. A stale rule is strictly better than a wrong one. Then sanity-check the winner before using it: syntactically valid IPv4, not private, not loopback, not link-local. A resolver that returns an error page instead of an address should never make it into a firewall rule.

The rule that makes this safe to automate at all

This is the part worth stealing even if you automate nothing else.

Keep one access path that a home-IP change cannot affect, and never let the automation touch it. A jump host, a bastion, a relay on a fixed address. It gets its own permanent firewall entry, written by hand, excluded from the script.

Now consider the worst case. The script gets the address wrong, or the ISP renumbers, or the quorum is fooled. Every home-IP rule on the host is now incorrect. You can still get in, because the path you came in on was never in scope. That single exclusion converts "this automation can lock me out of a machine I cannot physically reach" into "this automation can be wrong and I fix it".

Test that claim rather than believing it. Inject a deliberately wrong address from a documentation range, let the reconcile run, and confirm you can still reach the host by the untouched path.

Add before delete, validate before reload

Two ordering rules, both cheap:

Add the new firewall rule before removing the stale one. There is then never a moment with no rule at all, which is the window an interrupted script leaves you in.
Validate a generated config before reloading the service. Run the config checker, and leave the previous file in place if it fails. A proxy that refuses to start because your script wrote broken config is a self-inflicted outage on a machine you may have just firewalled yourself away from.

Be honest about what cannot be automated

Two of the six locations here are deliberately reported by email and never touched, for two different reasons, and both are worth recognising in your own setup:

A credential that is itself allowlisted to the old address. The cloud API key is scoped to the home IP, so the moment that IP changes the key is already rejected and cannot be used to fix itself. That is a genuine chicken-and-egg. The fix is the same trick as the jump host: give the key a second permitted source that a home change cannot affect, and it becomes automatable.
A credential that does not exist. No DNS API token, so the DNS record is a dashboard job. Pretending otherwise would mean a script that silently does nothing.

An automation that quietly skips two of six locations is worse than one that emails you about them.

Give it an audit mode

The single most useful thing this grew was a read-only flag:

home-ip-sync.sh --audit    # report drift everywhere, change nothing
home-ip-sync.sh            # reconcile, which is what the timer runs

One command that prints the truth across every location is the thing you actually wanted the whole time. It is also how you check the automation is working without waiting for an ISP to renumber you.

When this isn't your problem

You have a static IP. Then the copies are harmless, though an audit command is still a nice thing to own.
Only one thing references it. Automating one location is not worth a timer and a quorum. Write it down instead.
You can use a hostname. Dynamic DNS plus a rule that accepts a name is simpler than all of this, where the software supports it. Plenty of firewalls resolve names only at rule-creation time, so check before relying on it.