aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorXe Iaso <me@xeiaso.net>2023-04-02 15:01:32 -0400
committerXe Iaso <me@xeiaso.net>2023-04-02 15:01:32 -0400
commite8347815f7b1bfce0d5db600cdffc60ba1b3531a (patch)
treedb3d0d992a91219c7787b3d2bfb8204bbe9f2f2e
parent2cc14d7e10b29decf3ef1e88550ec603a78322e2 (diff)
downloadxesite-e8347815f7b1bfce0d5db600cdffc60ba1b3531a.tar.xz
xesite-e8347815f7b1bfce0d5db600cdffc60ba1b3531a.zip
linkpost over my backlog on the tailscale blog
Signed-off-by: Xe Iaso <me@xeiaso.net>
-rw-r--r--blog/tailscale-auth-grafana.markdown7
-rw-r--r--blog/tailscale-auth-minecraft.markdown7
-rw-r--r--blog/tailscale-auth-nginx.markdown7
-rw-r--r--blog/tailscale-configuring-emacs-mdx.markdown7
-rw-r--r--blog/tailscale-funnel-101.markdown17
-rw-r--r--blog/tailscale-gitops-acls.markdown7
-rw-r--r--blog/tailscale-hamachi.markdown7
-rw-r--r--blog/tailscale-headscale-funnel.markdown19
-rw-r--r--blog/tailscale-nas-101.markdown178
-rw-r--r--blog/tailscale-social-proximity-networks.markdown53
-rw-r--r--blog/tailscale-steam-deck.markdown7
-rw-r--r--blog/tailscale-tsnet-101.markdown216
-rw-r--r--blog/tailscale-weaponizing-hyperfocus.markdown7
-rw-r--r--src/post/mod.rs6
-rw-r--r--src/tmpl/mod.rs2
15 files changed, 545 insertions, 2 deletions
diff --git a/blog/tailscale-auth-grafana.markdown b/blog/tailscale-auth-grafana.markdown
new file mode 100644
index 0000000..95276f4
--- /dev/null
+++ b/blog/tailscale-auth-grafana.markdown
@@ -0,0 +1,7 @@
+---
+title: "How To Seamlessly Authenticate to Grafana using Tailscale"
+date: 2022-04-06
+redirect_to: https://tailscale.com/blog/grafana-auth/
+---
+
+<xeblog-conv name="Mimi" mood="happy">This page demonstrates how to use Tailscale to simplify the authentication and access control for internal services such as Grafana. It shows how to use a local API server and a proxy to pass the Tailscale user information to Grafana via HTTP headers. It also explains how to configure Grafana and the proxy, and how to restrict access to Grafana only over Tailscale. The benefits of this approach are reduced provisioning work, improved security, and seamless integration with existing identity providers.</xeblog-conv>
diff --git a/blog/tailscale-auth-minecraft.markdown b/blog/tailscale-auth-minecraft.markdown
new file mode 100644
index 0000000..c38d036
--- /dev/null
+++ b/blog/tailscale-auth-minecraft.markdown
@@ -0,0 +1,7 @@
+---
+title: Tailscale Authentication for Minecraft
+date: 2023-04-13
+redirect_to: https://tailscale.com/blog/tailscale-auth-minecraft/
+---
+
+<xeblog-conv name="Mimi" mood="happy">This page describes how to use Tailscale for authenticating to a Minecraft server without relying on Mojang’s authentication servers. It explains how to set up a proxy with infrared that replaces the Minecraft username with the Tailscale identity information. It also lists some advantages and disadvantages of this approach, such as increased security, privacy, and control over who can access the server, but also limited compatibility with the Bedrock version of Minecraft and potential username issues.</xeblog-conv>
diff --git a/blog/tailscale-auth-nginx.markdown b/blog/tailscale-auth-nginx.markdown
new file mode 100644
index 0000000..cfb7b10
--- /dev/null
+++ b/blog/tailscale-auth-nginx.markdown
@@ -0,0 +1,7 @@
+---
+title: "Tailscale Authentication for NGINX"
+date: 2022-04-27
+redirect_to: https://tailscale.com/blog/tailscale-auth-nginx/
+---
+
+<xeblog-conv name="Mimi" mood="happy">This page shows how to use nginx-auth, a tool that implements the NGINX HTTP subrequest authentication protocol, to authenticate requests to internal services proxied behind NGINX with Tailscale. It also explains how to install and configure nginx-auth and NGINX, and how to use the response headers to pass authentication information to the applications. The benefits of this approach are similar to setting up a corporate SSO system without the installation and maintenance overhead.</xeblog-conv>
diff --git a/blog/tailscale-configuring-emacs-mdx.markdown b/blog/tailscale-configuring-emacs-mdx.markdown
new file mode 100644
index 0000000..83c013f
--- /dev/null
+++ b/blog/tailscale-configuring-emacs-mdx.markdown
@@ -0,0 +1,7 @@
+---
+title: "Configuring Emacs for MDX files"
+date: 2023-02-03
+redirect_to: https://tailscale.dev/blog/configuring-emacs-mdx
+---
+
+<xeblog-conv name="Mimi" mood="happy">The article Configuring Emacs for MDX files on tailscale.dev is a blog post by Xe, a Developer Advocate at Tailscale. It explains how Xe uses Emacs to edit posts on the blog, which uses MDX instead of normal Markdown. MDX is a format that combines Markdown with JSX, a syntax extension for JavaScript. The article shows how to use directory-local variables in Emacs to change the major mode for .mdx files to markdown-mode, and how to enable auto-formatting with prettier on save. The article also provides some examples of other directory-local variables that can be used to customize Emacs for different modes and files. The article is intended for Emacs users who want to edit MDX files or use directory-local variables for other purposes.</xeblog-conv>
diff --git a/blog/tailscale-funnel-101.markdown b/blog/tailscale-funnel-101.markdown
new file mode 100644
index 0000000..8728062
--- /dev/null
+++ b/blog/tailscale-funnel-101.markdown
@@ -0,0 +1,17 @@
+---
+title: "Funnel 101: sharing your local developer preview with the world"
+date: 2023-03-30
+redirect_to: https://tailscale.dev/blog/funnel-101
+---
+
+🚀 Do you want to share your web server with the world without exposing your computer to the world? 🚀
+
+If you’re like me, you love using Tailscale to create a secure and private network for your devices. But sometimes, you need to let the outside world access your web server, whether it’s for testing, hosting, or collaborating.
+
+That’s why I’m super excited about Tailscale Funnel, a new feature that lets you route traffic from the internet to your Tailscale node. You can think of it as publicly sharing a node for anyone to access, even if they don’t have Tailscale themselves.
+
+Tailscale Funnel is easy to set up and use. You just need to enable it in the admin console and on your node, and you’ll get a public DNS name for your node that points to Tailscale’s Funnel servers. These servers will proxy the incoming requests over Tailscale to your node, where you can terminate the TLS and serve your content.
+
+The best part is that Tailscale Funnel is secure and private. The Funnel servers don’t see any information about your traffic or what you’re serving. They only see the source IP and port, the SNI name, and the number of bytes passing through. And they can’t connect to your nodes directly. They only offer a TCP connection, which your nodes can accept or reject.
+
+Tailscale Funnel is currently in beta and available for all users. I’ve been using it for a while now and I’m blown away by how simple and powerful it is. It’s like having your own personal cloud service without any hassle or cost.
diff --git a/blog/tailscale-gitops-acls.markdown b/blog/tailscale-gitops-acls.markdown
new file mode 100644
index 0000000..5347baa
--- /dev/null
+++ b/blog/tailscale-gitops-acls.markdown
@@ -0,0 +1,7 @@
+---
+title: "GitOps for Tailscale ACLs"
+date: 2022-09-02
+redirect_to: https://tailscale.com/blog/gitops-acls/
+---
+
+<xeblog-conv name="Mimi" mood="happy">This page explains how to use a GitHub Action to automatically update Tailscale ACLs from a Git repository, following the GitOps pattern. It also shows how to prevent accidental changes to ACLs in the Tailscale admin console by adding a comment to the policy file. The benefits of this approach are better control, review, and testing of ACL changes.</xeblog-conv>
diff --git a/blog/tailscale-hamachi.markdown b/blog/tailscale-hamachi.markdown
new file mode 100644
index 0000000..6e091d9
--- /dev/null
+++ b/blog/tailscale-hamachi.markdown
@@ -0,0 +1,7 @@
+---
+title: "Tailscale: A modern replacement for Hamachi"
+date: 2022-09-27
+redirect_to: https://tailscale.com/blog/hamachi/
+---
+
+<xeblog-conv name="Mimi" mood="happy">This page is a blog post by Xe, a Developer Advocate at Tailscale. It compares and contrasts Tailscale with Hamachi, a tool that Xe used in college to play games with friends over a shared network. The article highlights how Tailscale is an evolution of the concepts that Hamachi introduced, such as firewall hole punching, relay servers, and private IP addresses. The article also shows how Tailscale adds more features and benefits than Hamachi, such as identity-based access control, HTTPS certificates, MagicDNS, Tailscale SSH, and support for more platforms and OSes. The article concludes with some examples of how Tailscale can be used to build the next generation of shared game worlds, internal applications, and more. The article is intended for people who are familiar with Hamachi or want to learn more about Tailscale.</xeblog-conv>
diff --git a/blog/tailscale-headscale-funnel.markdown b/blog/tailscale-headscale-funnel.markdown
new file mode 100644
index 0000000..1aa34f8
--- /dev/null
+++ b/blog/tailscale-headscale-funnel.markdown
@@ -0,0 +1,19 @@
+---
+title: "Using Tailscale without using Tailscale"
+date: 2023-04-01
+redirect_to: https://tailscale.dev/blog/headscale-funnel
+---
+
+I’m always amazed by the power of technology and the creativity of people who use it. Today I want to share with you a project that I did for fun and learning. It’s about how to use Tailscale Funnel to host a Headscale server from behind NAT. Sounds crazy, right? Let me explain.
+
+Tailscale Funnel is a tool that lets you share a web service on your private network with the public internet. It’s like having your own personal cloud without the hassle of setting up servers and domains. Headscale is a tool that lets you create your own Tailscale control plane. It’s like having your own private VPN without relying on a third-party service.
+
+Now, what if you could combine these two tools and create a network that uses Tailscale without using Tailscale? That’s exactly what I did. I used waifud, NixOS, and Funnel to create a virtual machine that runs Headscale and exposes it to the internet. Then I used Funnel to connect other devices to this network and enjoy the benefits of Tailscale.
+
+Why did I do this? Because I love learning new things and challenging myself. Because I believe in the power of open source and decentralized solutions. Because I wanted to have some fun and make some jokes along the way.
+
+This project taught me a lot about networking, security, and automation. It also showed me how much potential there is in tools like Tailscale and Headscale. And it made me laugh at the absurdity of using Tailscale without using Tailscale.
+
+If you’re curious about how I did this, you can check out my blog post where I explain everything in detail. It’s not a serious tutorial, but rather a playful experiment.
+
+I hope this post inspires you to try new things and have fun with technology. Remember, nothing is impossible if you put your mind to it. And don’t forget to laugh at yourself sometimes.
diff --git a/blog/tailscale-nas-101.markdown b/blog/tailscale-nas-101.markdown
new file mode 100644
index 0000000..ab8c497
--- /dev/null
+++ b/blog/tailscale-nas-101.markdown
@@ -0,0 +1,178 @@
+---
+title: "NAS 101: An intro chat about Network Attached Storage"
+date: 2021-06-04
+redirect_to: https://tailscale.com/blog/nas-101/
+---
+
+A lot of people use Tailscale with Network Attached Storage (NAS) devices. In an effort to make this technology more accessible we’re publishing this transcript of a conversation about the basics of Network Attached Storage between our past co-op student [Naman Sood](https://twitter.com/tendstofortytwo), and our Archmage of Infrastructure, [Xe Iaso](https://twitter.com/theprincessxena). Enjoy!
+
+---
+
+**Naman:**
+Okay, so what is a NAS?
+
+**Xe:**
+So, it is an acronym that is short for Network Attached Storage. Basically, it's a computer that has a whole bunch of disks, and is set up to share the contents of those disks over the network. So that machines don't have to store all that data.
+
+For an example of a NAS you can think of, like, a media server, where you have all of your legally acquired media in a folder so that other machines on your network can access it; or archives of family photos; or personal documents.
+
+**Naman:**
+What are the potential benefits of a NAS over say just using Dropbox or something like that?
+
+**Xe:**
+One big argument for having a NAS is that you don't have to upload the data to the cloud, and then download it later when you want to access it. Because it's locally on the network you can get gigabit speeds or if you have a slightly more fancy network, a 10 gigabit speed, so that you can access the data pretty much as fast as the hard drives will let you. One downside to having everything locally though is that Dropbox has a support system, and when you just have some hard drives in some machine, you don't necessarily have somebody to talk to for support, except for yourself.
+
+**Naman:**
+Yeah that's fair. Okay, so what does it look like if you don't have a NAS? What are your alternatives and how would you get by without it?
+
+**Xe:**
+If you don't have a NAS, then you just have to store the files locally and hope your drives don't die. One of the things that I've been wanting to set up a home NAS for is automated backups of my home folder, and all of our media — we have a bunch of photos — a bunch of important immigration documents that I want to have backed up in multiple places, and things like that. You can get by without it by just copying it multiple places manually and praying.
+
+Another really cool thing that you can do with a NAS that is harder to do without one is to have a dedicated Steam library, shared across multiple computers, so that you only need to download the games once.
+
+**Naman:**
+Wait, does that work? I assumed that the games would be encrypted or something.
+
+**Xe:**
+I have seen no reason that would specify that it doesn't work so until proven otherwise I'm going to assume that it works.
+
+**Naman:**
+All right, all right. That does something I honestly didn't even think about.
+
+So, what is a good way to get started with having your own NAS?
+
+**Xe:**
+Well, it really depends on how much time you're willing to put into it. Like getting something off the shelf, and just like plugging it in, turning it on, and then just having it available in your network. That's probably good enough for a lot of people.
+
+Other people may want to have more. They may have an extra computer laying around that they can just stuff full of drives, install something like FreeNAS on it. FreeNAS is a distribution of FreeBSD that is specially equipped to be a network-attached storage server and has a whole bunch of fancy UI clicky buttons that people like. If you're more hardcore like I am, what you do is you set up a Linux box as a NAS server and installed Samba, a whole bunch of other things to share the files.
+
+**Naman:**
+Okay, so what are these whole bunch of other things and why do you need them?
+
+**Xe:**
+The whole bunch of other things would be like management things connections to WireGuard or Tailscale networks, the ability to run virtual machines protocol support for things other than SMB — for some reason Linux likes NFS more than SMB, I'm not exactly sure why but that's just how it is.
+
+**Naman:**
+Okay, just to be clear, what are NFS and SMB?
+
+**Xe:**
+SMB is the file sharing protocol that Windows uses, and has used basically since like the dawn of time. It's a "server message block". I forget where exactly it came from, but it's basically the default in Windows.
+
+**Naman:**
+Okay, and NFS?
+
+**Xe:**
+NFS is "network file system" has a long storied history from the Unix-y side of Unix and the big deployments of servers so that you can have an entire data center of servers with the core system files on the same NFS machine, and it would just work, and you wouldn't have to install BSD everywhere. You could just boot the entire fleet off of the same install of BSD.
+
+**Xe:**
+Nowadays in Linux-land, it's more used for VM images.
+
+**Naman:**
+Okay. Is there any reason to prefer SMB over NFS or the other way around for any particular thing?
+
+**Xe:**
+You would prefer SMB when Windows are in the mix. SMB mounting does work in Linux, but if you need some more advanced file features like some extended attributes and weird file locking calls you're definitely going to need NFS to get this a lot lower level in the kernel.
+
+**Naman:**
+Okay. Yeah, that makes sense. So speaking of setting up your own NAS’s. What is the common mistake that people just getting started with setting up their own NAS make?
+
+**Xe:**
+One mistake that could be made pretty often would be over complicating things, and specifically over complicating things in a way that's not entirely documented so if your NAS decides that today is a good day to die, then you have to do a whole bunch of manual setup, again, to get it working the way it was not counting all of the data.
+
+**Naman:**
+Okay. So, once you have a NAS in place — so you talked about some uses, like, storing documents and media and a Steam library — are there any other uses that you're particularly excited about?
+
+**Xe:**
+Another big thing that I really want, that I'm kind of excited about is being able to do backups. The NAS I'm looking at setting up is going to use ZFS which is a file system that lets you do fancy things like some volumes, snapshots, and being able to send disk snapshots over the network.
+
+So my backups, in the future, are not going to be individual files, they're going to be disk volume.
+
+**Naman:**
+Oh, all right.
+
+**Xe:**
+Yeah, so that way if something goes incredibly sad, I can just reinstall a system, set up ZFS on that machine, and then pull the latest backup and just have the system, combined with configuration management with NixOS, I can have things backup, the way they were pretty darn quick.
+
+**Naman:**
+That makes sense. Right now my backup scheme is basically just to backup my home folder and get a list of installed packages from apt. And after that it's just hope for the best.
+
+**Xe:**
+Yeah, prayer does work, but prayer doesn't scale.
+
+**Naman:**
+Right.
+
+**Xe:**
+And in my case, I admit that what I'm planning for this NAS is definitely kind of over engineering at a level. However, when you get to that point where everything is over engineered it's really nice. You don't really have to think about things as much, you don't have to worry about, like, "Oh, where's the data being backed up to? How do I restore it?" because you can just use standard tools to do it for interfacing — interacting with the file system.
+
+**Naman:**
+Okay. Yeah, that makes sense. I remember that at one point I was working in a place where they had a common NAS, which hosted all of our home directories. I'm not sure if it was SMB or NFS or something else. But I remember a bunch of common file system operations just didn't work, and for certain things you had to use local storage. So is that something that's pretty common?
+
+**Xe:**
+It's something that used to be common. So when I was in college, way back and I think a decade ago, their Linux systems had all of a student's home folder set up over some network attached storage so that you could just log into any computer and things would roughly be about the same.
+
+**Naman:**
+Yeah.
+
+**Xe:**
+So if you make a vim configuration change, you could just pull that configuration on another machine and you could use that configuration on another machine, it would mostly work.
+
+**Naman:**
+Right.
+
+So, let's see, is there anything about having a NAS or building a NAS that really surprised you and you weren't expecting it?
+
+**Xe:**
+This is going to go into more of ZFS features, but I was really surprised that ZFS snapshot replication was as easy as it is. You basically—you can even do ZFS snapshot replication to a file so that you can backup your entire file system to a file. And if you have an encrypted ZFS volume, you can send it to a server — another server using ZFS — without that server having to know, what the password is to that volume.
+
+**Naman:**
+Okay, that's, that's pretty cool.
+
+**Xe:**
+Yeah.
+
+**Naman:**
+I was installing Ubuntu the other day and I think they're talking about making ZFS the default file system. Are there any benefits to that like outside of NAS?
+
+**Xe:**
+ZFS snapshots.
+
+ZFS is a file system that is basically a whole bunch of blocks of data. These blocks of data contain whatever. ZFS snapshots, allow you to say—they basically work like git tags — they tag like a set of blocks that occurred at a given version. And you can go back to that version if something goes bad. So in the case of Ubuntu, let's say that you install an update, and your entire system just goes haywire and nothing works. You can undo that update by rolling back with the ZFS snapshot. Not quite as nice as NixOS but yeah.
+
+Oh, another thing is that ZFS has compression support.
+
+**Naman:**
+Okay.
+
+**Xe:**
+If the file is a text file — ZFS will just automatically compress it.
+
+**Naman:**
+Oh, that's pretty sweet.
+
+**Xe:**
+Yeah! On one of my servers I've seen up to — saving like as much as — like I think I have a 1.5 times compression ratio, meaning that like, I'm saving about 25% of my disk space
+
+**Naman:**
+Right. Yeah that's pretty sweet. Huh.
+
+**Xe:**
+Yeah, compression support is something that basically every modern file system. It just gives you disk space for free. And given that they're using LZ4 for compression, it's basically really inexpensive to decompress it.
+
+**Naman:**
+Okay. Yeah. Oh yeah, one more thing about the snapshots that you were talking about, you were saying that you could restore a botched update or something. Is that like on a per volume basis like you have to restore the entire volume? Or can you just restore particular folders? Like I don't want to undo changes in my home folder for example.
+
+**Xe:**
+Yes to both. Although usually the way people set up ZFS is that their home folders are on a separate volume.
+
+So basically I have several volumes. I have one—this is a nixos machine—so I have one volume dedicated entirely to the Nix store. The compression saves a lot of storage because there's a lot of text files there that get easily compressed. And then I also have two hierarchies. Actually, I have local stuff that you know can get blown away and I don't care about it. The Nix store basically gets regenerated automatically by the deployment.
+
+**Naman:**
+Right. Yeah, this is pretty interesting. I might set up my next machine with ZFS, just check it out, even outside of the scope of a NAS.
+
+**Xe:**
+Yeah, it's pretty neat, it's something that not many people really know about. I only really know about it because of Dave Anderson.
+
+**Naman:** Okay. So, is there anything else that you think is worth sharing about in general just having a NAS or like building a NAS that you think wasn't covered, right now?
+
+**Xe:** It's really just a useful thing to have in general, putting or concentrating a whole bunch of storage somewhere on your network. And with things like Tailscale this means that you can connect to that storage from anywhere, at least when we're able to travel again.
diff --git a/blog/tailscale-social-proximity-networks.markdown b/blog/tailscale-social-proximity-networks.markdown
new file mode 100644
index 0000000..79bdfcc
--- /dev/null
+++ b/blog/tailscale-social-proximity-networks.markdown
@@ -0,0 +1,53 @@
+---
+title: "Philosophy of Tailscale: Social proximity networks"
+date: 2021-02-02
+redirect_to: https://tailscale.com/blog/social-proximity-networks/
+---
+
+Originally, computer networks mapped almost 1:1 to social networks.
+There has been a lot of development since then. We have added more and
+more devices to our networks thanks to mobile devices, remote work and
+Internet of Things. This has caused our home and office networks to
+not really be as trusted as they used to be. We have many more devices
+per person than we used to.
+
+Today, networks end up being a collection of devices that are in close
+physical proximity. Networks used to consist of devices that can all
+trust each other. However, you certainly wouldn’t trust random people
+at a coffee shop the same way you would trust your friends or family.
+You don’t know what they would want to do to your machine. You don’t
+have any social proximity to those people, even if they are sitting
+right next to you. You may not even trust your local network devices,
+such as the lightswitch that somehow needs internet access to turn
+your light on and off.
+
+Untrusted networks make it hard when you genuinely want to share
+things between your friends and family. You have to rely on third
+parties or peeling back layers of protection to communicate. Port
+forwarding, firewall rules, IP address allow listing, authentication
+proxies, permissions fatigue, and so much more get in the way of your
+communication.
+
+Here at Tailscale, we build networks to connect you, your family,
+friends, and coworkers together. Tailscale networks are built on the
+concept of identity, and let you build a network based on social
+proximity, or people that you are emotionally close to. Tailscale
+network members don’t need to be in the same room, building, city,
+province, country, or even continent. Physical proximity becomes
+irrelevant and you can focus on social proximity instead.
+
+Tailscale works to connect all of those devices so you can focus on
+communicating with each other like you were in that same room. You can
+focus on doing things that you want to do between each other, such as
+playing games, backing up important files and sharing your most
+precious moments: no port forwarding, firewall rules, allowlists,
+proxies or permissions fatigue. We hope to obsolete all of those.
+
+We want to turn your connections with people into connections between
+devices. Connecting people is the core of our business. Whether you
+need to connect between your friends to play minecraft, your family
+members to aid in backups, or sharing a prototype between your
+coworkers; Tailscale is there for you. We can’t wait to see what
+possibilities you unlock with our social proximity networks. What kind
+of things could you create if you and those close to you could
+directly connect to each other?
diff --git a/blog/tailscale-steam-deck.markdown b/blog/tailscale-steam-deck.markdown
new file mode 100644
index 0000000..64b542d
--- /dev/null
+++ b/blog/tailscale-steam-deck.markdown
@@ -0,0 +1,7 @@
+---
+title: Putting Tailscale on the Steam Deck
+date: 2022-07-18
+redirect_to: https://tailscale.com/blog/steam-deck/
+---
+
+<xeblog-conv name="Mimi" mood="happy">This page is a blog post by Xe, a Developer Advocate at Tailscale. It describes how to install Tailscale on a Steam Deck, a handheld Linux computer for playing PC games. The article explains the challenges and solutions of installing Tailscale on SteamOS, a variant of Arch Linux that runs on the Steam Deck. The article also demonstrates some of the use cases of Tailscale on the Steam Deck, such as remote-mounting a NAS, hosting game servers, and streaming games from another PC. The article concludes with some previews of a Steam Deck plugin that Xe is working on to automate the Tailscale setup. The article is intended for gamers and Linux enthusiasts who want to use Tailscale on their Steam Deck or other devices.</xeblog-conv>
diff --git a/blog/tailscale-tsnet-101.markdown b/blog/tailscale-tsnet-101.markdown
new file mode 100644
index 0000000..20a17ae
--- /dev/null
+++ b/blog/tailscale-tsnet-101.markdown
@@ -0,0 +1,216 @@
+---
+title: Virtual private services with tsnet
+date: 2022-11-04
+redirect_to: https://tailscale.com/blog/tsnet-virtual-private-services/
+---
+
+Tailscale lets you connect to your computers from anywhere in the world. We call
+this setup a virtual private network. Any device on the tailnet (our term for a
+Tailscale network) can connect directly to any other device on the tailnet. When
+you do this you can access your NAS from anywhere, RDP (Remote Desktop Protocol)
+into your gaming PC in Canada to check messages from the Canadian tax authority,
+or even SSH into production with [Tailscale
+SSH](https://tailscale.com/tailscale-ssh/). Everything will just work.
+
+This isn't limited to your computers, phones, and servers, though. You can use
+Tailscale as a library in Go programs to allow them to connect to your tailnet
+as though it were a separate computer. You can also use Tailscale to run
+multiple services with different confidentiality levels on the same machine.
+This will allow you to separate support tooling from data analytics without
+having to run them on multiple servers or virtual machines. The only way that
+the tools could be exposed is over Tailscale — meaning that there's no way to
+get into them from outside your tailnet.
+
+Today I'm going to explain more about how you can use `tsnet` to make your
+internal services easier to run, access, and secure by transforming them into
+virtual private services on your tailnet. By the end of this post you should
+have an understanding of what virtual private services are, how they benefit
+you, and how to write one using Tailscale as a library. Finally, I will give you
+some ideas for how you could take this one step further.
+
+## Virtual private services
+
+When you add a laptop or phone to your tailnet, Tailscale assigns it its own IP
+address and DNS name. This allows you to connect over Tailscale's encrypted
+tunnel so you can access your NAS from the coffee shop to grab whatever files
+you need. This also allows you to [request an HTTPS certificate from Let's
+Encrypt](https://tailscale.com/blog/tls-certs/) so you can run whatever services
+you want over HTTPS.
+
+However, this only lets you get one DNS name and IP address per system.
+Currently, running multiple services with separate domain names on the same
+system is impossible with Tailscale, but there is a workaround. Using
+[`tsnet`](https://pkg.go.dev/tailscale.com/tsnet), you can embed Tailscale as a
+library in an existing Go program. `tsnet` takes all of the goodness of
+Tailscale and lets you access it all from userspace instead of having to wade
+through the nightmare of configuring multiple VPN connections on the same
+machines.
+
+When you start a virtual private service with `tsnet`, your Go program will get
+its own IP address, DNS name, and the ability to grab its own HTTPS certificate.
+You can ping the service instead of the server it's on. You can listen on
+privileged ports like the HTTP and HTTPS ports without having to run your
+service as root. You can use ACL tags and groups to separate out access to that
+service individually. Finally, you can run multiple of these services on the
+same machine without having to have root permissions or do anything beyond
+running the programs on the machines. You don't even need to expose them
+anywhere else besides over Tailscale. All of this happens in the same OS
+process: All the magic of Tailscale becomes a library like any other, allowing
+you to create virtual private services for your team.
+
+## How to make your own hello server
+
+I'm going to show you how to create a minimal "hello" service that will let any
+connecting user know who Tailscale thinks they are. To start, install the latest
+version of the [Go programming language](https://go.dev/dl) and restart your
+terminal program. Next, create a folder for the code with a command such as
+this:
+
+```
+mkdir -p ~/code/whoami
+cd ~/code/whoami
+```
+
+Then create a new Go project with this command:
+
+```
+go mod init github.com/your-username/whoami
+```
+
+Install `tsnet` with this command:
+
+```
+go get tailscale.com/tsnet
+```
+
+Then make a `main.go` file with the following in it:
+
+```go
+
+package main
+
+import (
+ "flag"
+ "fmt"
+ "html"
+ "log"
+ "net/http"
+ "strings"
+
+ "tailscale.com/tsnet"
+)
+
+var (
+ hostname = flag.String("hostname", "hello", "hostname for the tailnet")
+)
+
+func main() {
+ flag.Parse()
+
+ s := &tsnet.Server{
+ Hostname: *hostname,
+ }
+
+ defer s.Close()
+
+ ln, err := s.Listen("tcp", ":80")
+ if err != nil {
+ log.Fatal(err)
+ }
+
+ defer ln.Close()
+
+ lc, err := s.LocalClient()
+ if err != nil {
+ log.Fatal(err)
+ }
+
+ log.Fatal(http.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+ who, err := lc.WhoIs(r.Context(), r.RemoteAddr)
+ if err != nil {
+ http.Error(w, err.Error(), 500)
+ return
+ }
+
+ fmt.Fprintf(w, "<html><body><h1>Hello, world!</h1>\n")
+ fmt.Fprintf(w, "<p>You are <b>%s</b> from <b>%s</b> (%s)</p>",
+ html.EscapeString(who.UserProfile.LoginName),
+ html.EscapeString(firstLabel(who.Node.ComputedName)),
+ r.RemoteAddr)
+ })))
+}
+
+func firstLabel(s string) string {
+ if hostname, _, ok := strings.Cut(s, "."); ok {
+ return hostname
+ }
+
+ return s
+}
+```
+
+Then generate a new auth key in the [admin
+panel](https://login.tailscale.com/admin/settings/keys) and set it as
+`TS_AUTHKEY=` in your environment:
+
+```
+export TS_AUTHKEY=tskey-auth-hunter2-hunter2hunter2hunter2
+```
+
+Then you can run it:
+
+```
+go run .
+```
+
+Once it shows up in your tailnet, you can open [http://hello](http://hello) and
+you'll get back a simple page that tells you who you are on Tailscale.
+
+You can use this as the basis for other services, too. Replace the
+`http.HandlerFunc` with a `http.ServeMux` and you can host an internal-facing
+service.
+
+## Other examples
+
+If you need inspiration, here are some ways that we've used `tsnet` for
+ourselves here at Tailscale.
+
+One of our first deployments of `tsnet` was aimed at helping our support team
+get context for incoming tickets. The support UI we used wasn't good at giving
+us information about users, and the process of having to manually look up
+everything we needed to know was time-consuming and tedious.
+
+We wanted to get the support team more information so they could do their job,
+but we also didn't want to open that tool up to the public internet (and risk
+catastrophic data breaches). We used `tsnet` to create a service named DAB (Data
+About Business) that would work _with_ our support tooling so that when support
+opened a ticket, they got all the information they needed from our control plane
+at a glance. DAB has been one of our most reliable services inside Tailscale,
+and it's hosted on a single AWS instance. HTTPS was seamless with Let's Encrypt.
+DAB has easily been the most successful internal project I have ever worked on.
+
+Creating new services is cool, but what's even cooler is that you can use
+`tsnet` to help bridge the gap between Tailscale's account model and the account
+model of internal tools like Grafana. We use a tool called
+[`proxy-to-grafana`](https://tailscale.com/blog/grafana-auth/) inside Tailscale
+to let us browse and even edit Grafana dashboards without having to have
+separate Grafana accounts or manage access permissions. We just visit
+`http://mon`, and we can do whatever we want.
+
+This isn't limited to web services like Grafana. You can even use [`tsnet` to
+authenticate to
+Minecraft](https://tailscale.com/blog/tailscale-auth-minecraft/), or as a [proxy
+for Postgres](https://tailscale.com/blog/introducing-pgproxy/) to lock down
+access to your sensitive databases.
+
+We've heard about people using `tsnet` to expose Prometheus metrics and REPL
+access exclusively over Tailscale. This has allowed those operators to be able
+to poke inside services _in production_ without having to worry about making
+custom authentication logic, deal with OAuth2 proxies or other setups to glue it
+into their identity providers. Access is controlled via Tailscale
+[ACLs](https://tailscale.com/kb/1018/acls/).
+
+What else could you do with this? How do you use `tsnet` in your tailnet? We'd
+love to hear more! Mention us on Twitter
+[@Tailscale](https://twitter.com/tailscale) or post on [/r/tailscale on
+Reddit](https://reddit.com/r/tailscale).
diff --git a/blog/tailscale-weaponizing-hyperfocus.markdown b/blog/tailscale-weaponizing-hyperfocus.markdown
new file mode 100644
index 0000000..b421f73
--- /dev/null
+++ b/blog/tailscale-weaponizing-hyperfocus.markdown
@@ -0,0 +1,7 @@
+---
+title: "Weaponizing hyperfocus: Becoming the first DevRel at Tailscale"
+date: 2023-01-30
+redirect_to: https://tailscale.dev/blog/weaponizing-hyperfocus
+---
+
+<xeblog-conv name="Mimi" mood="happy">The article Weaponizing hyperfocus: Becoming the first DevRel at Tailscale is a blog post by Xe, the first Developer Advocate at Tailscale. It describes how Xe started working on Developer Relations (DevRel) at Tailscale in Spring 2022 and how it helped them turn their hyperfocus from a hindrance to an advantage. The article also showcases some of the projects, tools, and ways to use Tailscale that Xe published in 2022, such as nginx-auth, GitOps for ACLs, and installing Tailscale on a Steam Deck. The article concludes with some reflections on what DevRel means for Xe and Tailscale, and how it aligns with their vision of Tailscale being everywhere with you so you can get back home.</xeblog-conv>
diff --git a/src/post/mod.rs b/src/post/mod.rs
index be3bf04..2338365 100644
--- a/src/post/mod.rs
+++ b/src/post/mod.rs
@@ -46,7 +46,11 @@ impl Into<xe_jsonfeed::Item> for Post {
.title(self.front_matter.title.clone())
.content_html(self.body_html)
.id(format!("https://xeiaso.net/{}", self.link))
- .url(format!("https://xeiaso.net/{}", self.link))
+ .url(if let Some(url) = self.front_matter.redirect_to.as_ref() {
+ url.clone()
+ } else {
+ format!("https://xeiaso.net/{}", self.link)