TL;DR
Five weeks on the road out of six, and the laptop never noticed it left the house.
Identities and ACLs are your firewall now, and the change control discipline never followed them there.
Episode 057: the air gap that is not an air gap, and every hole you opened for a good reason just to manage the thing.
Claude Code running on a lab VM, driven from a phone over /rc, and the access questions worth settling first.
Tool of the Week: Headscale, for when you want the mesh without the coordination plane you do not own.
Quick Win: get off your own network and walk the path you would actually use at 2am.
From the Console
It hit me at a couple of different points over the last few weeks:
From an Airport gate in Michigan (literally 20 minutes from my house) where my flight was drip scheduled for 12 hours before being canceled
From a hotel room at New York, New York in Vegas with a literal rollercoaster in view out my hotel window.
From a bar at a PGA resort in Frisco, Texas.
From an Airbnb that reminded me of a Hobbit hole in Minneapolis.
From a floating hotel on the Thames in London.
From 20 thousand feet on an American Airlines flight to Dallas.
For the most part during all that travel my laptop never really thought that it existed anywhere other than my desk at home. The exception, of course, were the occasional captive portal (looking at you American Airlines) that required local-only routing. Other than that, my system blissfully thought it was sitting on my desk at home. I could access “local” systems, M365 saw me as connecting from the same GEO, and I could also troubleshoot family tech issues while not being in the room. At one point I looked up and thought to myself “This has been effortless for weeks….”. The tool had become so easy, transparent, and had just gotten out of the way to the point where I just STOPPED thinking about it…. which is what a good tool does. It enables you, without becoming all about itself.
Maybe this wouldn’t have been noteworthy for those SysAdmins that have entered the IT industry during the cloud era, but I remember a time where persistent, secure, and transparent remote access was a legit feat of engineering. Either:
The user would have to manually establish connectivity upon startup
3389 was just left open to a “jump box” in the target environment (YUCK!)
The user experience was impacted in some usability way
With modern hybrid cloud technologies, work from anywhere is easier than ever and completely transparent. Yes, we’ve had VPNs for a long time, but overlay networks, like Tailscale, are on a whole new level. Never has it been easier to connect multiple geographically separated systems / networks than it is now. For example, sitting at a gate at the airport… with an overlay network, I can securely access my home network, my production management network, lab resources, as well as a hosted web server that is locked behind the vendor providing it. All of it just effortless, and secured via ACLs, routing options, and filtration.
While I’m obviously a HUGE fan of this configuration, two things do come to mind.
Just because your current configuration has been in place and working for a period of time, it doesn’t mean that there isn’t a new solution out there that can do it better. Look up once in a while and see if the status quo is still the configuration that makes sense.
As good as new technologies are, don’t become OVER-dependent on them. You may not always have an overlay network available to abstract and automagically configure networking and routing. Those basic network skills are still important and will be needed when tools (like Tailscale) fail for any given number of reasons.
And now… back to our regularly scheduled programming
Recently on the SysAdmin Weekly Podcast
Episode: Is Your Air Gap Actually an Air Gap? Port 22 Says No (Episode 057) Topic: Almost nothing called an air gap is one. Eric and I walk the management plane hole by hole, and we land somewhere more useful than telling you that you are doing it wrong.
Why this one is a good listen:
We go through the holes in the order they get opened, and the list is uncomfortable because none of them were mistakes: SSH and RDP so somebody can patch the thing, SMB because files have to move, DNS and NTP because nothing works without them, then license activation and telemetry because a vendor said so. Every one of those was opened by a competent person with a good reason on an ordinary Tuesday.
The iDRAC, iLO, and IPMI stretch is the one to forward to your team. Those boards get parked on a management VLAN, keep whatever firmware shipped on them, and then nobody touches them again, which quietly makes the out-of-band path the least defended road into the most privileged place you own. There is also a detour about printers that we both stand behind.
The close is the part that changed how I use the word. A real air gap is possible and it costs a great deal, most of it in operational pain rather than dollars. What actually hurts people is the term: call something an air gap and the conversation ends, and nobody re-verifies a promise. Say what you have, then defend that.
Watch on YouTube
Listen on Spotify
The Take
While we’re speaking about painless remote network access in this issue I think it’s worth highlighting something I’ve noticed over the last few years in forum posts, conference conversations, and on social media. Identities (and ACLs) ARE your firewall now. It used to be we only had to worry about the 4 walls of our building. We’d put a firewall on the entry point and call it good, but with the cloud era and work from everywhere, that model doesn’t work so well anymore. So, that’s where ACLs, Conditional Access, Cloudflare Access rules…etc come in.
With that in mind then, I’ll pose a question: Do you remember the last time your ACLs were audited? Were those recent Conditional Access changes run through change control? As an industry we got REALLY good (mostly) at including even the simplest firewall changes in the change control process. I’ve found that the practice seems to be slipping for identity in the cloud era. Add on the fact that there are a myriad of ways SysAdmins can manage these various settings and change control becomes even MORE important in today’s world.
Why did this happen? I’m not convinced it’s laziness. It’s easy to include a firewall in that process as someone has to order that box, rack it, stack it, configure it…etc. The security model for cloud services doesn’t lend itself well to that mental model and as such, securing those services often becomes an afterthought and they get left out of change control processes.
Something to consider: Do you have any identity management workflows that go un-audited? Anything that is left out of change control? If there are, it’s time to take stock of them and start putting tools/processes in place to address those shortfalls.
None of it is exotic:
Put the policy in version control. Tailnet ACLs, Conditional Access exports, access rules for whatever tunnel you run. If it decides who reaches what, it belongs in a repo.
Put a reviewer on the pull request. You wouldn’t let a firewall rule go in unread, and this is the same thing wearing different clothes.
Let the diff be the change record. It’s already written, already timestamped, and it already says who approved it.
Write down every console that can change these settings. That myriad (there I go using that word again!) of management options is exactly why this slips, and let’s face it... you can’t audit a surface you don’t list.
What I Learned in AI this Week
A quick one here this week
If you haven’t looked at the /rc option in Claude Code, I HIGHLY recommend you take a look and determine ways you can incorporate it into your workflow. With all the travel I’ve been doing lately I made heavy use of this feature. My usage breaks down pretty simply:
I have a VM running in my lab that acts as an agent “worker” machine.
Said VM is also used to run Claude Code against locally synced git repos when I’m remote
I launch Claude Code using Screen so it survives ssh disconnections
Enabled /rc in the Claude Code Session
Connect using the Claude app on my phone
It seems a simple thing, but the ability to issue long running jobs and prompts remotely while I’m on the road is immensely valuable. If you also make sure that the bash session you launched code with is logged into GitHub’s CLI, Claude can even push/pull and open PRs.
That all said, there are security considerations here. Make sure your Claude account is not easily breached. Also consider the level of GitHub access you’re comfortable giving Claude. In my case, I don’t really have anything stored in GitHub that I would care about Anthropic seeing. Hardly an exhaustive list, but something to think about as you’re involving more AI tools in your standard workflow.
Community Signal
Brandon Lee - “This Made My Mini PC Home Lab Feel Enterprise Grade: Intel vPro with AMT” - Published February 23, 2026. Out-of-band management is the layer that decides whether “I can work from anywhere” survives contact with a node that has stopped answering, and Lee walks the whole thing on hardware normal people actually own: MEBx configuration on a Minisforum MS-01, MeshCommander in Docker, remote KVM and power control and BIOS access when the OS is gone. The part worth reading twice is the operational detail he did not have to include, like the AMT NIC not supporting VLAN tagging and the HDMI dummy plug trick for keeping video alive. He is also blunt about the risk: treat it like iDRAC in production, put it on a dedicated VLAN, and never let it see the internet. Honest scope, this is mini-PC specific, so the exact steps are for that class of hardware rather than your rack.
Tool of the Week
Headscale - An open source, BSD-3 licensed reimplementation of the Tailscale control server, so you can run the coordination plane for your own mesh instead of renting somebody else’s.
The tool I said got out of the way up top does that partly because somebody else runs the control plane. This is the version where that somebody is you.
The clients stay the official ones. What changes is who operates the piece that hands out keys, publishes the network map, and enforces your ACLs, which for a lot of shops is the exact objection that stopped the conversation the first time. It covers the features people actually use day to day, including MagicDNS, subnet routers, and exit nodes, and it is a single binary with a config file rather than a platform.
Honest scope, and this one matters more than usual. The project states its own goal plainly: a server suitable for self-hosters, hobbyists, and small open source organizations, built around a single tailnet. It is not trying to be a multi-tenant enterprise control plane, the maintainers explicitly say they do not support or encourage running it behind reverse proxies or in containers, and the project is not affiliated with Tailscale Inc. There is also a trade you should name out loud before you make it: the whole appeal of the managed service was that somebody else kept the coordination plane running, and self-hosting hands you that availability problem. Think through what happens to node enrollment and policy changes on the day your Headscale box is the thing that is down.
It is also still pre-1.0 and it means it. Version 0.29 changed what a wildcard resolves to in policy: * in ACL sources and destinations now covers the CGNAT and ULA ranges rather than every address. Upgrade without reading that line and your ACL file means something different than it did the day you wrote it, and nothing is going to tell you. That is this issue’s Take, delivered by the tool itself.
One more thing before you bolt a UI onto it. Headscale ships without one, so the docs point you at eleven community-built options, and the most popular of those is where this stack’s recent problem turned up: Headplane, CVE-2026-46484, scored 8.1 and patched in May 2026, which let an authenticated user rename or expire any node or user in the tailnet through a path traversal in the rename call. Headscale itself has had exactly one advisory in its entire history, back in 2023. The convenience layer is the part that needed the patch, which is worth remembering when you pick what else to bolt on.
Quick Win of the Week
Get off your own network and walk the path you would actually use at 2am.
Tether to your phone. Not your home wifi, not the office, not the coffee shop you have used a hundred times. Pick one machine you would have to fix if it stopped answering tonight, and go all the way to a working console on it. Not SSH into a jump box you already trust, the actual box. If getting there requires out-of-band, use out-of-band, because that is the path the outage will force you onto anyway.
Write down every step that fails, prompts you for something you do not have on you, or needs a second device you left at home. Time-box the whole thing to an hour.
That list is your real remote capability. The one in the policy document is a different document.
Fun Retro SysAdmin Fact
SSH exists because somebody got sniffed: in 1995 Tatu Ylönen, then a researcher at Helsinki University of Technology, wrote the first version in response to a password-sniffing attack on the university network, released it as freeware that July, and watched it reach roughly 20,000 users across fifty countries before the year was out, which means the tool that eventually untethered every SysAdmin from the server room was built as incident response rather than as a convenience feature.
Until Next Week
Your estate does not care where you are sitting, right up until the one path you never tested is the only one left.
Stay Frosty,
Andy
SysAdmin Weekly
I checked out the document for Claude Remote Control. This is a great thing to use, especially for a home lab environment.