I discovered this bash trick by chance when I was once trying to healthCheck the Envoy's official OCI image container which didn't include curl or wget while forcing the envoy admin interface to listen on localhost which breaks the traditional k8s httpGet checks.
Honestly I am happy that more remote access products are using QUIC, not WireGuard, for tunneling and realizing its technical benefits (e.g. AES hardware acceleration, dynamic endpoints, custom auth with JWT or mTLS, FIPS compliance, traffic masquerading as HTTP/3, etc.). I am a big fan of QUIC myself and I implemented it long ago in Octelium, which is a similar remote access product that's more centered around access control and zero trust rather than P2P connectivity. I believe QUIC should be the future of tunneling, especially when it comes to business and enterprise remote access use cases. Congrats on launching an I wish you the best of luck.
Yes, every resource that needs to be protected is represented by a "Service" that's implemented as a L7-aware identity-aware proxy in the Octelium Cluster, which is a distributed system that's running on top of a k8s cluster. Users simply access the protected resource/upstream through the Cluster, namely the Service, from a data-plane perspective, and the Service/identity-aware proxy does authentication/authorization/routing/visibility on a per-request basis. This upstream could be an internal resource directly accessible by the Cluster, or remotely behind NAT, or simply publicly protected SaaS resource (e.g. API protected by an access token, SaaS database protected by a password, etc.). You can read more about how Octelium works here https://octelium.com/docs/octelium/latest/overview/how-octel...
Thank you, I haven't accepted any contributions so far primarily because of this reason but things might change in the future. As mentioned in the README and docs, Octelium is designed specifically for self-hosting so the commercial side of the project is simply confined to commercial AGPLv3-alternative licensing, support, and other very enterprise-y/customized features such as SCIM, SIEM to specific providers, etc...
Well, yes, Octelium is technically a VPN from a layer-3 perspective since it uses WireGuard/QUIC tunneling, but the tunnel doesn't directly terminate to the destination like in VPNs but instead to an identity-aware proxy that does authentication and L7-aware authorization on a per-request basis with policy-as-code via CEL/OPA. From an architecture perspective, I assume it's closer to ZTNAs such as Cloudflare Access and Teleport than to traditional VPNs, even though it operates as one for the clien-based access mode. However, unlike VPNs, it does provide clientless/BeyondCorp access too as it's intended to operate as a more generic/unified access platform (e.g. API/AI/MCP gateway, ngrok-alternative, PaaS-like platform, etc.) rather than just a VPN.
(Shamless plug) I am also working on a similar FOSS, self-hosted project called Octelium https://github.com/octelium/octelium that you might find interesting if you are interested in this space. Octelium is, however, more of a generic/unified zero trust secure access platform that can operate as a remote access VPN, a ZTNA platform, API/AI/MCP gateway, a PaaS, an ngrok-alternative and a homelab infrastructure. It provides unified client-based as well as clientless access for both humans and workloads; dynamic identity-based secretless access (e.g. access to HTTP/gRPC/k8s upstreams without sharing API keys and access tokens, SSH without distributing passwords/private keys, postgres/MySQL databases without sharing passwords, etc.); dynamic L7-aware, identity-based access control ABAC via CEL and OPA as well as dynamic routing to upstreams via policy-as-code; native Passkey login/WebAuthn/TOTP MFA and support for OIDC/SAML IdPs, OpenTelemetry-native L7-aware visibility and auditing; clientless access via OAuth2 for workloads, WireGuard and QUIC tunneling with dual-stack and automatic private DNS, including in rootless mode; passwordless SSH'ing into containers and IoT without SSH servers; deploying and securing access to containers; declarative k8s-like management with horizontal scalability among other features. You can read more in the README if you're interested.
I wonder whether the current huge funding in AI will ever lead to a revolution in computer architecture. Modern PCIe/CXL is already starting to blur the difference between memory and I/O. Maybe the future is going to be that CPUs, RAM, storage devices, GPUs and other devices are going to directly address one another like a mesh network. Maybe the entire virtual memory model will change to include everything to be addressed via a unified virtual memory space from a process/CPU perspective with simple read/write syscalls that translate into network packets flowing between the CPU and the destination (e.g. RAM/GPU/NVMe) and vice versa.
Is it? I honestly kinda believe that etcd is probably the weakest point in vanilla k8s. It is simply unsuitable for heavy write environments and causes lots of consistency problems under heavy write loads, it's generally slow, it has value size constraints, it offers very primitive querying, etc... Why not replace etcd altogether with something like Postgres + Redis/NATS?
TCP over WireGuard is unavoidable because that's the whole point of tunneling. But TCP over WireGuard over QUIC just doesn't make any sense, neither from performance nor from security perspective. Not to mention that with every additional tunneling layer you need to reduce the MTU (which is already a very restricted sub-1500 value without tunneling) of all inner tunnels.
There is actually. A way more interesting re-implementation of a popular L7 is SSH over QUIC. SSH has to implement its own mutual authentication and transport embedded in the protocol implementation since it operates on top of plaintext TCP, but with QUIC you can just offload the authentication (e.g. JWT bearer tokens issued by IdPs verified at L7 or automatically via mTLS x509 certs) and transport parts to QUIC and therefore have a much more minimal implementation.
You can just do that by using QUIC-based tunneling directly instead of using WireGuard-over-QUIC and basically stacking 2 state machines on top of one another.
WireGuard-over-QUIC does not make any sense to me, this lowers performance and possibly the inner WireGuard MTUs. You can just replace WireGuard with QUIC altogether if you just want obfuscation.
While WireGuard makes every sense for an FPGA due to its minimal design, I wonder why there isn't much interest in using QUIC as a modern tunneling protocol, especially for corporate use cases. QUIC already provides an almost complete WireGuard-alternative via its datagrams that can be easily combined with TUN devices and custom authentication schemes (e.g. mTLS, bearer tokens obtained via OAuth2 and OIDC authentication, etc...) to build your own VPN. While I am not sure about performance, at least when compared to kernel-mode WireGuard, since QUIC is obviously a more complex state machine that's running in userspace and it depends on the implementation and optimizations offered by the OS (e.g. GRO/GSO), QUIC isn't just a yet another tunneling protocol, it actually offers lots of benefits such as working well with dynamic endpoints with DNS instead of just using static IP addrs, it uses modern TLSv1.3 and therefore it's compliant with FIPS for example, it uses AES which can be accelerated by the underlying hardware (e.g. AES-NI), it currently has implementations in almost every major programming language, it can work well in the future with proxies and load balancers, you can bring your own custom, more fine-grained authentication scheme (e.g. bearer tokens, mTLS, etc...), it masquerades as just another QUIC/HTTP3 traffic that's used by almost all major websites now and therefore less susceptible to dropping by any nodes in between, and other less obvious benefits such as congestion control and PMTUD.
I am working on Octelium https://github.com/octelium/octelium a FOSS unified zero trust secure access platform that is flexible enough to operate as a modern zero-config remote access VPN, a Zero Trust Network Access (ZTNA)/BeyondCorp platform, an API/AI/LLM gateway, an infrastructure for MCP gateways and agentic AI architectures/meshes, a PaaS-like platform, ngrok alternative, and even as a homelab infrastructure. It is basically a unified, generic, Kubernetes-like, zero trust architecture (ZTA) for secure access and deployment, that can operate in many human-to-workload, workload-to-workload, and hybrid environments.
I actually did a SHOW HN exactly 3 months ago and received lots of invaluable critique regarding how dense, overwhelming and unreadable the docs and repo README were. I've actually spent a lot of time trying to improve the quality of the docs and README since then. I'd love to receive any feedback, negative included, regarding the current overall quality of the docs and README from whoever is interest in that space.