Hairpin NAT (or "NAT hairpinning") is the term for "...connecting from inside local network the router recognize that by connecting to public IP, he has to route it back onto some local IP address", and the Linux NAT implementation supports it.
For a homelab situation split-horizon DNS is just fine. You're going to have minimal duplication of records from the public DNS into the private DNS.
The canonical frustrating "bad split-horizon DNS" world I've seen, time and again, is a corporate network with a MSFT Active Directory named the same as the company's public-facing web property (e.g. "example.com" rather than "ad.example.com"). This creates the need to duplicate all the public-hosted resources into the internal "example.com" zone (and keep them updated when records inevitably change on the public Internet). It's make-work for no practical upside in that example.
> Use DNS validation to allow these internal services to pull ACME certs...
The major ACME clients support DNS validation. If your DNS host doesn't have an API that your ACME client supports either get a new ACME client or a new DNS host.
> Writing the email is part of the thinking process for me...
Same here.
> Responses should always be inline between relevant quotes rather than the default of hiding the original at the bottom.
This is highly polarizing. As you can tell I also like inline replies. I grew up using BBSs and inline replies were common. It seemed so natural. Then Outlook came around and top-posting became the norm.
I have gotten some scathing criticism from higher-ups for inline responses (along with some scant praise). I have been told, repeatedly, that inline responses are confusing.
Personally, I think anybody confused by inline responses (particularly if they're formatted distinctly) probably shouldn't be using email as part of their job because they lack the necessary mental faculties.
(I've given up with my strongly-held beliefs about plain text email. I still send plain text by default but I grudgingly reply with HTML / rich text if an email started that way.)
I get antsy about a private key being in lots of places. You've also got to worry about renewal so you might as well just have "consumer" of the wildcard just provision its own non-wildcard certificate.
The relative proximity of the words "done right" and "split-horizon DNS" makes my insides hurt a little bit.
Use DNS validation to allow these internal services to pull ACME certs. There's so much less headache, long-term.
Split-horizon DNS (and the tedious make-work it can create when you start needing to mirror public-accessibly records in the private DNS) has always been something to aspire to move away from in my experience.
Shuffle would certainly help with that. I felt like I was expending a ton of energy and time shuffling mentally (but I'll concede that if I did it enough I'd get faster at it).
The best model of the WRT54G line. I would snag them at thrift stores for cheap to use for silly utility functions. I always referred to that particular model as "The highly-coveted WRT54GL."
I used a pair to provide Internet access at a Customer's construction site back in 2010. Cell phone hotspot wasn't a thing for me yet. We took a pair of WRT54Gs, configured one as a WiFi client, the other as a bog-standard router/AP, connected the LAN from the client to the WAN on the router/AP, pur a directional antenna onto the "client", and pointed it down the road toward a big business who offered free WiFi for Customers. We leeched off that until the real Internet service got installed. (It was a restaurant and we ate there at least once so we were Customers, right? >smile<)
How is an overlay network "much better" (or meaningfully different) than a device-based certificate and 802.1x when the user is accessing an application delivered over HTTPS using a publicly-verifiable certificate authenticating via SAML w/ MFA (Entra ID)? The source subnet attests successful device authentication in the 802.1x example but that's irrelevant beyond, perhaps, a firewall granting access for the device to terminate a TCP connection to the server's TCP port 443. That's no different than the request coming to the server from an authenticated overlay network, to my eye.
I guess if you want to tie the network layer authentication to the user make it 802.1x with a user certificate. Either way you know the request is coming from authenticated endpoint and the user still authenticates to the application independent of the network layer. In all cases HTTPS protects the traffic from MiTM end-to-end.
That's great when you have control of your applications. For most corporate IT you're stuck with COTS applications and whatever their built-in auth functionality is. Sure, you can probably bolt a reverse proxy in front (if you're lucky enough for it to be a web app and not a thick native code client) but you get to argue with the vendor when they refuse support because you're not using their recommended configuration.
802.1x certificate-based authentication at layer 2 is a good defense in depth strategy.
I've flown some 172s. When the DA40 came out I thought it seemed like a really, really neat airplane. I got some marketing lit and talked to people about it from Diamond at Sun 'n Fun (in 2004, I think). It's nothing I could have even remotely approach buying then (or now, unless I wanted to live in it, I guess) but I just wanted to soak up some of the aura of the thing.
The linked article makes mention of some of the questionable stuff in the last paragraph, at least.
Mr. Plummer seems to be really good at semi-sensational and click-baity marketing. I want to watch his videos because I like the subject matter but I can't stomach the spin.
It's so bizarre to me that this works and I can't say I believed it until I tried. I shouldn't be surprised that it's so easy to trick our brains.
I assume the phenomenon where I write 90% of an email, save it as a draft to finish later, never remember to finish it, get asked about it and have irrefutable certainty I sent it, then finally discover it as an unfinished draft is a facet of the same trickery. Stupid brain... Grrr.
A very similar experience here. Reading comment threads over the years has absolutely turned me on to perspectives I never even conceived of previously. I've reconsidered my positions (on political and technical matters, mainly) by reading the discourse in comment threads.
I feel crushing sadness when I think about how humans made these wonderful deterministic machines that we can understand and manipulate to do our bidding. Within a scant few generations, though, we've managed to effectively turn them into "magic boxes" that, soon, we'll only be able to poke and prod at when they don't do what we want.
I hadn't heard this take before but I find it very compelling. The supply of raw materials for their product pipeline has become contaminated and they need to weed out the adulterant.
No shady agenda about killing public discourse is necessary if you view the push for identify verification in that light. (That doesn't mean it won't kill public discourse, but that's an unintended consequence.)
http://serverfault.com/users/7200/evan-anderson