commit 1da2760be9fbaa96b188544d2db32a1458119c74 Author: faultables Date: Sat Jul 8 20:28:02 2023 +0000 deploy: a247c1bf9350b5c036a75f74ba81c13b9c2b3ba9 diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/CNAME b/CNAME new file mode 100644 index 0000000..1dc2acb --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +rizaldy.today diff --git a/assets/css/reset.css b/assets/css/reset.css new file mode 100644 index 0000000..45a05ec --- /dev/null +++ b/assets/css/reset.css @@ -0,0 +1,129 @@ +/* http://meyerweb.com/eric/tools/css/reset/ + v2.0 | 20110126 + License: none (public domain) +*/ + +html, +body, +div, +span, +applet, +object, +iframe, +h1, +h2, +h3, +h4, +h5, +h6, +p, +blockquote, +pre, +a, +abbr, +acronym, +address, +big, +cite, +code, +del, +dfn, +em, +img, +ins, +kbd, +q, +s, +samp, +small, +strike, +strong, +sub, +sup, +tt, +var, +b, +u, +i, +center, +dl, +dt, +dd, +ol, +ul, +li, +fieldset, +form, +label, +legend, +table, +caption, +tbody, +tfoot, +thead, +tr, +th, +td, +article, +aside, +canvas, +details, +embed, +figure, +figcaption, +footer, +header, +hgroup, +menu, +nav, +output, +ruby, +section, +summary, +time, +mark, +audio, +video { + margin: 0; + padding: 0; + border: 0; + font-size: 100%; + font: inherit; + vertical-align: baseline; +} +/* HTML5 display-role reset for older browsers */ +article, +aside, +details, +figcaption, +figure, +footer, +header, +hgroup, +menu, +nav, +section { + display: block; +} +body { + line-height: 1; +} +ol, +ul { + list-style: none; +} +blockquote, +q { + quotes: none; +} +blockquote:before, +blockquote:after, +q:before, +q:after { + content: ""; + content: none; +} +table { + border-collapse: collapse; + border-spacing: 0; +} diff --git a/assets/css/style.css b/assets/css/style.css new file mode 100644 index 0000000..a928d32 --- /dev/null +++ b/assets/css/style.css @@ -0,0 +1,349 @@ +:root { + --body-bg-color: #eee; + --footer-fg-color: #666; + + --base-font-size: 18px; + + --font-family-serif: "Sentient", serif; + --font-family-sans-serif: "Clash Display", sans-serif; + --font-family-monospace: "JetBrains Mono", monospace; + + --font-heading: var(--font-family-sans-serif); + --font-body: var(--font-family-serif); + + --img-border-radius: 5px; + --img-transform: rotate(-1.337deg); + --img-border: 2px solid #333; + + --layout-fragment-max-width: 666px; + --layout-fragment-padding: 4rem; + --layout-bg-color: #fff; + + --line-color: #eee; + --anchor-color: inherit; +} + +::selection { + background-color: #f8c8dc; +} + +body { + background-color: var(--body-bg-color); + font-size: 16px; + font-family: var(--font-body); + + text-rendering: optimizeLegibility; + -webkit-text-size-adjust: 100%; + -moz-text-size-adjust: 100%; + + text-size-adjust: 100%; + -webkit-font-smoothing: antialiased; + -moz-osx-font-smoothing: grayscale; + + text-align: left; +} + +h1, +h2, +h3, +h4, +h5, +h6 { + font-family: var(--font-heading); + font-weight: 600; +} + +a { + color: var(--anchor-color); +} + +img { + border-radius: var(--img-border-radius); + transform: var(--img-transform); + border: var(--img-border); + max-width: 100%; +} + +hr { + border: none; + border-top: 1px solid var(--line-color); +} + +ul { + margin-top: 1rem; + margin-bottom: 1rem; + padding-left: 1.5rem; +} + +li { + list-style: square; + line-height: 1.8rem; +} + +p { + line-height: 1.8rem; + margin-bottom: 0.5rem; +} + +p + p { + margin-top: 1.3rem; +} + +strong { + font-weight: bold; +} + +em { + font-style: italic; +} + +code[class*="language-"], +pre[class*="language-"], +code, +pre { + font-family: var(--font-family-monospace); + font-size: 14px; +} + +pre[class*="language-"] { + border-radius: 5px; + margin-top: 1.5rem; + margin-bottom: 1.5rem; + padding: 1rem; +} + +code { + background-color: #eee; + font-size: 14px; + padding: 2px 6px; + border-radius: 3px; +} + +pre[class*="language-"] code { + padding: 0; +} + +.l-container { + max-width: 1024px; + margin: 0; + background-color: var(--layout-bg-color); + padding-top: 0.8rem; + padding-bottom: 0.8rem; + border-radius: 5px; + border-bottom-left-radius: 0; + border-bottom-right-radius: 0; +} + +.l-fragment { + margin: auto; + padding: 1rem; + max-width: var(--layout-fragment-max-width); +} + +.l-fragment h2 { + font-size: 2rem; +} + +.l-fragment h3 { + font-size: 1.6rem; + margin-top: 2rem; + line-height: 2rem; + text-align: left; +} + +.l-fragment h2 + p { + margin-top: 0.5rem; +} + +.l-fragment--blog { + text-align: left; +} + +.l-fragment--blog h1 { + font-size: 2.3rem; + margin-bottom: 0.3rem; +} + +.l-fragment--blog h2 { + margin-top: 2rem; + line-height: 2.3rem; +} + +.l-fragment--blog img { + transform: rotate(0deg); + border: none; +} + +.l-fragment--blog li { + margin-bottom: 0.3rem; +} + +.c-bio { + margin-top: 1.8rem; +} + +.c-bio__avatar { + float: left; + width: 100%; +} + +.c-bio__info { + float: left; + width: 100%; +} + +.c-bio__info h2 { + margin-top: 1rem; +} + +.c-bio__info ul { + padding-left: 1.2rem; +} + +.c-bio__info li { + line-height: 1.5rem; +} + +.c-footer { + border-top: 1px solid var(--line-color); + color: var(--footer-fg-color); + font-size: 14px; + padding: 0 1.3rem; + padding-top: 1.5rem; +} + +.c-footer__copyleft { + float: left; + width: 100%; +} + +.c-footer__links { + float: left; + width: 100%; +} + +.c-footer__copyleft p { + line-height: 1.3rem; +} + +.c-footer ul { + margin-top: 1rem; + padding-left: 0; +} + +.c-footer li { + display: block; +} + +.c-article__meta-info { + font-size: 16px; + color: #666; +} + +.c-article__meta-info-tag { + margin-right: 0.3rem; +} + +/* https://nicolasgallagher.com/micro-clearfix-hack/ */ + +.u-clearfix { + zoom: 1; +} + +.u-clearfix:before, +.u-clearfix:after { + content: " "; + display: table; +} + +.u-clearfix:after { + clear: both; +} + +.u-no-underline { + text-decoration: none; +} + +.u-underline--hover:hover { + text-decoration: underline; +} + +.u-text-left { + text-align: left; +} + +.u-text-right { + text-align: right; +} + +@media screen and (min-width: 30em) { + body { + text-align: justify; + font-size: var(--base-font-size); + } + + .l-container { + margin: 8rem auto; + margin-bottom: 0; + } + + .l-fragment { + padding: var(--layout-fragment-padding); + } + + .l-fragment h1 { + font-size: 2.8rem; + } + + .l-fragment h2 { + font-size: 2.6rem; + } + + .l-fragment h3 { + font-size: 2rem; + margin-bottom: 0.3rem; + line-height: 2.5rem; + } + + .l-fragment--blog h2 { + line-height: 2.8rem; + } + + .l-fragment--blog li { + margin-bottom: 0.5rem; + } + + .c-bio__avatar { + width: 25%; + } + + .c-bio__info { + width: 75%; + } + + .c-bio__info h2 { + margin-top: -8px; + } + + .c-bio__info ul { + padding-left: 1.2rem; + } + + .c-footer__links { + width: 60%; + text-align: right; + } + + .c-footer__copyleft { + width: 40%; + } + + .c-footer ul { + margin-top: 0; + } + + .c-footer li { + display: inline-block; + padding-left: 1.5rem; + } +} diff --git a/assets/img/avatar.jpg b/assets/img/avatar.jpg new file mode 100644 index 0000000..e986e79 Binary files /dev/null and b/assets/img/avatar.jpg differ diff --git a/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-15-at-9.47.40-PM.png b/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-15-at-9.47.40-PM.png new file mode 100644 index 0000000..7eeb8c1 Binary files /dev/null and b/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-15-at-9.47.40-PM.png differ diff --git a/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-16-at-4.07.16-AM-2048x1305.png b/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-16-at-4.07.16-AM-2048x1305.png new file mode 100644 index 0000000..20258b0 Binary files /dev/null and b/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-16-at-4.07.16-AM-2048x1305.png differ diff --git a/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-16-at-5.43.20-AM.png b/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-16-at-5.43.20-AM.png new file mode 100644 index 0000000..e543679 Binary files /dev/null and b/blog/expose-web-service-at-home-via-tailscale-for-fun/Screen-Shot-2021-10-16-at-5.43.20-AM.png differ diff --git a/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-15-2135-2048x985.png b/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-15-2135-2048x985.png new file mode 100644 index 0000000..17a6bce Binary files /dev/null and b/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-15-2135-2048x985.png differ diff --git a/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-16-0110-2.png b/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-16-0110-2.png new file mode 100644 index 0000000..d454375 Binary files /dev/null and b/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-16-0110-2.png differ diff --git a/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-16-0110.png b/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-16-0110.png new file mode 100644 index 0000000..efa1b35 Binary files /dev/null and b/blog/expose-web-service-at-home-via-tailscale-for-fun/Untitled-2021-10-16-0110.png differ diff --git a/blog/expose-web-service-at-home-via-tailscale-for-fun/index.html b/blog/expose-web-service-at-home-via-tailscale-for-fun/index.html new file mode 100644 index 0000000..66ab3c6 --- /dev/null +++ b/blog/expose-web-service-at-home-via-tailscale-for-fun/index.html @@ -0,0 +1,155 @@ + + + + + + + + Expose Web Services at Home via Tailscale for Fun + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+
+

Expose Web Services at Home via Tailscale for Fun

+ +

+ • + + + + + TAILSCALE + + +

+ +

I have a small homelab server at home running TrueNAS Core. My home network sits behind NAT and there are probably 3 routers in front of me. +On the other hand I also have a small VM that has a static public IP address somewhere in Singapore. Some of my services need to be exposed to the internet for my friends to access—for example—this blog via DNS because remembering a domain address is more fun than a random number with 4 dots.

+

The problem is that this blog is running on my NAS and using a private IP address.

+

Also, my ISP assigns a public IP Address to my network dynamically. The simplest way to expose my services on my NAS to the Internet might be using Dynamic DNS but sometimes it's not as easy as it sounds.

+

So maybe I need to connect one of my VMs in Singapore with my NAS at home. Since it is not possible to connect ethernet cable from NAS to DigitalOcean data center in Singapore, so I have to connect it virtually.

+

And yes, by creating a VPN.

+

Tailscale VPN

+

Previously I used Wireguard with a hub-and-spoke network because managing the keys on each of my machines was quite a chore.

+

Then I found out Zerotier from a random page on Reddit. Zerotier uses a mesh network and it's cute how my machines can talk to each other on a peer-to-peer basis.

+

My problem with Zerotier is sometimes the network is somewhat unreliable and maybe it's my poor VM's fault. Also sometimes my machines just randomly can't talk to each other via the Zerotier assigned address and I believe it's a firewall issue.

+

So I found out Tailscale from one of my friends on Twitter (actually he is my boss at work). Tailscale is built on Wireguard and is a mesh network. Even though Wireguard has its own mesh network solution, it's still WIP and using alternative is quite difficult because, again, managing keys is a pain.

+

Then I give Tailscale a try. Installing and running Tailscale is easy enough that even my gf (who is non an IT person) can use it without wondering what public/private key means.

+

Our devices can talk to each other even though we're on different networks, and that's cool. In most cases, we can communicate peer-to-peer and that's really great.

+

Exposing web services on different private networks

+

We have a secret journal running on my NAS and only accessible over the local network. The domain address is 1460.rizaldy.club and resolves to a local IP address on the 192.168.1.0/24 subnet so maybe if you access it you will see a random web page (or none at all) rather than our secret journal.

+

My gf's private network uses the 10.26.0.0/24 while our journal lives in 192.168.1.242. The key is I use subnet routers and I have Tailscale on my router (and on my device as well) at home. While Tailscale for iOS (and others) has "accept routes" enabled by default, that means our secret journal is directly accessible out of the box because my router advertises the 192.168.1.0/24 subnet and we're on the same tailnet.

+

some diagram

+

And that's cool.

+

I never even touched Tailscale.app on her phone just to make sure everything was working fine, because it is. We can access it anywhere without having to expose the service to the internet, and that's it the point.

+

Exposing web services on a private network to the Internet

+

I have a minio instance on my NAS and sometimes I upload cat photos there. My minio is accessible at faultables-s3.lan address and since I'm using Magic DNS too, devices on my tailnet can resolve that domain (thanks to split tunnel) then anyone on my tailnet can see the cat photo I uploaded so maybe I can stop use imgur service as well.

+

But I also want my friends to know because my friends are nice and they deserve to see cats. To allow my friend to access it without doing anything, I need a static public IP address and my VM has it. Connecting my VM with my NAS via Tailscale was the answer and that's why you can see this cat right on your screen.

+

The setup is pretty simple, I just pointed s3.faultable.dev to my VM's IP, set up Caddy Web Server there, and told Caddy to proxy the request to 192.168.1.170:9000.

+

Here's another diagram:

+

I did my best to visualize it

+

Packets between my VM and my router are transmitted in an end-to-end encrypted using the Wireguard protocol so no one can see and/or modify the packets even if no one cares and that's cool.

+

Reverse Proxy as a Service for fun

+

So I just mentioned Tailscale on Twitter about my recent random thoughts:

+

https://static-tweet.vercel.app/1448966405391405056

+

@apenwarr's answer regarding my thoughts is perfectly understandable: it's not Tailscale's main business (nor focus) so why don't I create one?

+

Imagine you don't have to touch any server to just proxy web requests from the public internet to machines in your tailnet. Invite my machine to your tailnet, tell me the address of the domain you own, then tell me where to proxy requests for it.

+

In my mind is to setup an OpenResty instance with Redis as a data store, so let's make it official.

+

I'll be using a service from Fly.io (because I'm very interested in their service) to deploy OpenResty. For a high-level view of how it works, here's another cool diagram:

+

+

Actually I haven't deployed any instances to fly.io when creating this diagram, but if you can see this post it's very likely the diagram above is working.

+

Now let's try this out.

+

Minimum Viable RPaaS

+

We'll use openresty/openresty Docker's image as base image because we'll deploy it to fly.io plus we'll bring the Tailscale app on it later.

+

We'll be using the openresty/openresty docker image as the base image as we'll be deploying it to fly.io plus we'll be bringing the Tailscale app over later.

+

I'll be using a managed Redis solution from Upstash instead of Fly.io and we'll talk about it later. Now let's write the nginx.conf file:

+
worker_processes  2;
error_log logs/error.log info;

events {
  worker_connections 1024;
}

env REDIS_HOST;
env REDIS_PORT;
env REDIS_PASSWORD;

http {
  server {
    listen 80;

    location / {
      set $upstream '';

      access_by_lua '
        local redis = require "resty.redis"
        local redisc = redis:new()
        local target = ngx.var.host

        local redis_host = os.getenv("REDIS_HOST")
        local redis_port = os.getenv("REDIS_PORT")
        local redis_password = os.getenv("REDIS_PASSWORD")

        local connect, err = redisc:connect(redis_host, redis_port, {
          ssl = true
        })

        if not connect then
          ngx.log(ngx.ERR, "failed to connect to redis", err)
          return ngx.exit(500)
        end

        local auth, err = redisc:auth(redis_password)

        if not auth then
          ngx.say("failed to authenticate", err)
          return ngx.exit(500)
        end

        local get_upstream, err = redisc:get(target)

        if not get_upstream or get_upstream == ngx.null then
          ngx.log(ngx.ERR, "no host found for key", key)
          return ngx.exit(404)
        end

        ngx.var.upstream = get_upstream
      ';

      proxy_pass http://$upstream;
    }
  }
}
+

The configuration above in short is to tell OpenResty to handle the request based on its Host header and forward the request based on the existing values. When the host is not listed in our Redis record, we will return a 404 Not Found page because it is.

+

The very simple data we're storing for now is just like this:

+
<target_host>:<upstream_ip>:<upstream_port>
+

So if I want to handle every incoming request from nginx.init8.lol to 100.73.204.66:42069, the operation is as simple as SET nginx.init8.lol 100.73.204.66:42069.

+

+

Please keep in mind that since packets are end-to-end encrypted means that target upstream need to be directly to be the Tailscale IP. For example, port forwarding from your WAN to your LAN on your router won't work because packets are encrypted unless you set reverse proxy on your router (and let the proxy do the job).

+

Making it more official

+

Now let's deploy our OpenResty to the fly.io platform. In order to connect Tailscale with Fly.io we can use this guide from Tailscale Docs. Our fly.io instance will only have Tailscale IPv6 so we need to point our domain to use Tailscale IPv6 so fly.io can route traffic to your machine.

+

So I'm going to create a frontend for this service so that it can interact with Redis via a REST API. It's still a WIP at the moment (I'm writing this post while creating the service lol) but I wanted to let my internet friends know I'm developing something fun (or at least for me).

+

The common setting than this is to set ngrok.io, tell ngrok.io which port you want to expose then you will get a unique URL. That's pretty cool but what if I'm dogfooding this? +So I point app.init8.lol to ts-proxy.fly.io, invite the machine to my tailnet, then tell the proxy to point that domain to [fd7a:115c:a1e0:ab12:4843:cd96:6258:9a11]:80 which is my Tailscale IPv6 address on my mac that running Next.js app on tmux.

+

+

Go visit this to try it out before my mac dies! (dead)

+

What's next?

+

My main point is to destroy my DigitalOcean droplet which only does one thing which is proxying requests. Every time I run new service, I need to SSH into my VM; update Caddyfile, systemctl reload caddy, and so on. Apart from that I need to manage & maintain the server and I'm too lazy for that.

+

In future I would like to add some nice functionality like:

+
    +
  • Issuing an SSL certificate from Let's Encrypt. In theory this is possible as long as your domain can complete HTTP-01 challenge.
    • +
  • GUI access to manage proxies so I don't have to use curl anymore when adding new service
    • +
  • Hardening the security
    • +
  • Make it work properly & correctly
    • +
+

This project is pretty fun and it took me 5-ish hours while I wrote this blog post to create a PoC.

+

If you have a web service at home and want to expose it to the public internet via the Fly.io network, mention me on Twitter @200GbE (updated) Mastodon @rizaldy@edgy.social and let's chat.

+

You can also check out this project on this repository to learn more, especially there's something I haven't attached here like the Dockerfile and fly.toml files.

+

Demo (dead)

+
    +
  • Demo 1 (machine with a static public IP address, my devbox)
    • +
  • Demo 2 (machine with a dynamic public IP address, my laptop)
    • +
  • Demo 3 (fly.io instance for this project)
    • +
+ +
+
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/blog/index.html b/blog/index.html new file mode 100644 index 0000000..449bfe5 --- /dev/null +++ b/blog/index.html @@ -0,0 +1,128 @@ + + + + + + + + Blog + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+

Blog

+

Technically a blog.

+ + +
+

+ Proxy Auto-Configuration (PAC) is actually useful +

+ • + + + + + TAILSCALE + + + + PROXY + + +

So I just got my new Mac machine last week. It's just a small machine with 8 CPUs and 8 GB of memory. I've been thinking about buying one for a long time and now the time has come!

+
+

+ Syncthing Anywhere With Tailscale +

+ • + + + + + TAILSCALE + + + + SYNCTHING + + +

I don't archive data very often but when I do it must be for a very important one. On the other hand, I somewhat don't trust "cloud" providers and would avoid them as much as I can since my paranoid level is kinda high.

+
+

+ Expose Web Services at Home via Tailscale for Fun +

+ • + + + + + TAILSCALE + + +

I have a small homelab server at home running TrueNAS Core. My home network sits behind NAT and there are probably 3 routers in front of me. +

+ +
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/blog/pac-is-actually-useful/1A5B132F-D2F9-4B1F-9923-434B045CFF60.jpg b/blog/pac-is-actually-useful/1A5B132F-D2F9-4B1F-9923-434B045CFF60.jpg new file mode 100644 index 0000000..99f2b1d Binary files /dev/null and b/blog/pac-is-actually-useful/1A5B132F-D2F9-4B1F-9923-434B045CFF60.jpg differ diff --git a/blog/pac-is-actually-useful/236D9096-4D0A-43A5-9827-6227230FB8FE.jpg b/blog/pac-is-actually-useful/236D9096-4D0A-43A5-9827-6227230FB8FE.jpg new file mode 100644 index 0000000..c16b950 Binary files /dev/null and b/blog/pac-is-actually-useful/236D9096-4D0A-43A5-9827-6227230FB8FE.jpg differ diff --git a/blog/pac-is-actually-useful/AF9155DC-0B3D-4A4C-9F64-7435D6F77738.jpg b/blog/pac-is-actually-useful/AF9155DC-0B3D-4A4C-9F64-7435D6F77738.jpg new file mode 100644 index 0000000..90fcce2 Binary files /dev/null and b/blog/pac-is-actually-useful/AF9155DC-0B3D-4A4C-9F64-7435D6F77738.jpg differ diff --git a/blog/pac-is-actually-useful/F89B89ED-50B6-4A0C-B6C2-078BFE35CCE6.jpg b/blog/pac-is-actually-useful/F89B89ED-50B6-4A0C-B6C2-078BFE35CCE6.jpg new file mode 100644 index 0000000..f057a6e Binary files /dev/null and b/blog/pac-is-actually-useful/F89B89ED-50B6-4A0C-B6C2-078BFE35CCE6.jpg differ diff --git a/blog/pac-is-actually-useful/index.html b/blog/pac-is-actually-useful/index.html new file mode 100644 index 0000000..87d8108 --- /dev/null +++ b/blog/pac-is-actually-useful/index.html @@ -0,0 +1,164 @@ + + + + + + + + Proxy Auto-Configuration (PAC) is actually useful + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+
+

Proxy Auto-Configuration (PAC) is actually useful

+ +

+ • + + + + + TAILSCALE + + + + PROXY + + +

+ +

So I just got my new Mac machine last week. It's just a small machine with 8 CPUs and 8 GB of memory. I've been thinking about buying one for a long time and now the time has come!

+

I'll be using this tiny PC as my main workstation, but unlike my previous approach of setting up development environments, I now have plans to isolate each existing environment into VMs, +like, one for private; one for side projects, one for community stuff, and one for work.

+

I want to keep this tiny PC as clean as possible.

+

The dumb way to use Tailscale

+

This is the main topic of this post, but I'm doing my best to make this post not feel like a shot tweet. On my laptop I use 4 different identities (accounts) in Tailscale, +and I used to use Tailscale's Fast user switching feature which was quite useful. Often I forget to switch back +to my personal account after I realize I can't SSH into my server at home via its hostname.

+

So here's the story: I don't want to "switch" anymore so I don't forget one more time.

+

I create every VM I need and use different identities for Tailscale there. The OS is NixOS and I'm using OrbStack to provision VMs on my tiny PC. +When I'm not working from home, I can SSH into the VM with this tiny PC as a jumphost while hoping my internet at home is working fine.

+

First, it was DNS

+

Every Tailnet has its own unique name with ts.net as root domains. My tiny PC's hostname +is mac-mini (sounds boring) so I can access it via mac-mini.duck-map.ts.net, and yes, duck-map.ts.net is my real Tailnet name.

+

The first problem is that ts.net can only be resolved by the "MagicDNS server" which resides on your own device accessed via 100.100.100.100. This means that +when you try to query names for a machine that is outside your tailnet, you will get a bogus NXDOMAIN — which is good.

+

The second problem is that you can't route packets to machines outside your tailnet, of course.

+

Maybe I could use Subnet Routers to advertise subnets of the bridge interface used by my VM but that only solves half of the problem (excluding DNS queries).

+

And what about the Exit Node option? Of course not the answer.

+

Then, it was routing tables

+

In certain cases I had to access an internal application that was only accessible through Tailscale to troubleshoot (#sysadminlife). I don't use proxies much but when I do my favorite +is to ssh -D 6669 somewhere and use 127.0.0.1:6669 as SOCKS5 proxy servers.

+

236D9096-4D0A-43A5-9827-6227230FB8FE.jpg

+

From the screenshot above, kudxxx.tailnet-xxxxx12.ts.net is the machine that resides on the tailnet where I work. I can't resolve the name, because, well, I'm using my own personal tailnet.

+

Then I can use ssh -D 6669 delman@orb where delman is the name of the VM to the tailnet at work. socks5h indicates that the DNS query is made on SOCKS5 proxy servers.

+

If referring to the screenshot above, I think it works.

+

Proxy Auto-Configuration

+

What if I need to access different machines on different tailnets like heavy-rotation.duck-map.ts.net and kudxxx.tailnet-xxxxx12.ts.net at the same time?

+

On MacOS (or maybe other OS too) you can only use 1 proxy server on your machine at a time. So ssh -D 6669 delman@orb and ssh -D 4848 heavy-rotation@orb require extra work when +you need to use either one.

+

./AF9155DC-0B3D-4A4C-9F64-7435D6F77738.jpg

+

And no, using transparent proxies doesn't help.

+

And then I just came across an old technology called Proxy Auto-Configuration +which is the title of this post. The concept is actually simple: a PAC is just a JavaScript file that calls a FindProxyForURL function that returns a single string. The minimal +script is something like this:

+
function FindProxyForURL (url, host) {
  alert('url ' + url)
  alert('host ' + host)

  return 'DIRECT'
}
+

You don't need to save it using .js extensions by the way.

+

As far as I know that alert function doesn't work in Safari but it works fine in Firefox and Chrome. This is how it looks when "debugging the PAC" using Firefox:

+

./1A5B132F-D2F9-4B1F-9923-434B045CFF60.jpg

+

In many cases, you don't need to do that just to verify if your PAC is working — checking the access.log where you hosted the pac file must be enough.

+

Making it official

+

Now, here is the strategy:

+
    +
  • If I access .duck-map.ts.net, proxy the requests to 127.0.0.1:4848
    • +
  • If I access .tailnet-xxxxx12.ts.net, proxy the requests to 127.0.0.1:6669
    • +
  • Other than that don't proxy the requests to anywhere
    • +
+

Actually I can use mac-mini instead of 127.0.0.1 as the hostname so I can use the PAC file everywhere using the same URL.

+

In every VM I use gost as SOCKS5 server. I can create a simple systemd service for gost like this:

+
systemd.services.gost = {
  description = "gost";

  after = ["network.target"];
  wantedBy = ["multi-user.target"];

  serviceConfig = {
    ExecStart = "${pkgs.gost}/bin/gost -L=:6669";
    Restart = "always";
    RestartSec = 1;
  };
};
+

And then nixos-rebuild switch as usual, then check:

+
$ systemctl status gost

● gost.service - gost
     Loaded: loaded (/etc/systemd/system/gost.service; enabled; preset: enabled)
    Drop-In: /nix/store/rmhm2f4izkfxkpaix0ca2pxnvyswkxfi-system-units/service.d
             └─zzz-lxc-service.conf
     Active: active (running) since Wed 2023-07-05 15:57:51 WIB; 8h ago
   Main PID: 43857 (gost)
         IP: 16.1M in, 15.8M out
         IO: 0B read, 0B written
      Tasks: 11 (limit: 7106)
     Memory: 10.5M
        CPU: 4.504s
     CGroup: /system.slice/gost.service
             └─43857 /nix/store/q34c64p4cnxh67yxsqxjpjsgdmg8ilpq-gost-2.11.5/bin/gost -L=:6669
+

For the contents of the PAC file, it could be like this:

+
function FindProxyForURL (url, host) {
  work = "SOCKS5 mac-mini:6669"
  community = "SOCKS5 mac-mini:4848"

  if (shExpMatch(host, "*.tailnet-xxxxx12.ts.net")) {
    return work
  }

  if (shExpMatch(host, "*.duck-map.ts.net")) {
    return community
  }

  return "DIRECT"
}
+

shExpMatch is a function to check if the string +matches a specified shell glob expression. When one of the conditions is met, it tells the client how to connect to the target.

+

./F89B89ED-50B6-4A0C-B6C2-078BFE35CCE6.jpg

+

*click image above to enlarge*

+

As you may see I can access *.duck-map.ts.net and *.tailnet-xxxxx12.ts.net at the same time without switching accounts. If you check (1) and (2) in the screenshot above, the value in "remote address" is where the proxy server is running.

+

But why not share nodes?

+

I can share my mac-mini devices to every tailnet I want, but why not? I don't know, maybe the answer is the same as why I installed and used a different account on Tailscale, in different VMs.

+

Also, "shared devices" are quarantined by default. Which means my mac-mini can't initiate connections to devices on the "shared network" until they talk to it first — although it's not a big deal.

+

Why not Tailscale Funnel?

+

It's a different story. Tailscale Funnel is all about exposing devices to the wider internet. This means that even anyone with no Tailscale installed can access +(usually a web service) via the boring HTTPS protocol. No MagicDNS. No CGNAT IPs. Just the internet we are used to.

+

Conclusion

+

There is no way to verify the integrity of the PAC file especially if you load it via a remote address using an insecure procotol. Which means MiTM attacks are by no means impossible. Maybe someone +is snooping on your network especially if you are on a public network that uses a captive portal. There's nothing to stop anyone from modifying a PAC file if they want and can.

+

But it's worth noting that almost all traffic in 2023 uses end-to-end encryption via HTTPS protocols. If you're installing a "CA certificate" because someone out of nowhere +asked you to do so, don't do it. If it's too late, maybe consider stopping receiving candy from random people at the bar as well, if that happens to you.

+

A simple python -m http.server or caddy:alpine web server can help serve your PAC files on the machine you control. And since you're in control, you probably already have Tailscale installed on the device and can +use a secure transport (such as Wireguard protocols) to load the PAC file.

+

The Proxy Auto-Configuration was introduced into Netscape Navigator 2.0 in the late 1990s +at the same time when JavaScript was introduced. For years I have wondered why my machine has "Automatic proxy configuration" options and why I would ever need it.

+

And now I know.

+ +
+
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/blog/syncthing-anywhere-with-tailscale/CleanShot-2022-01-04-at-9.18.04@2x.png b/blog/syncthing-anywhere-with-tailscale/CleanShot-2022-01-04-at-9.18.04@2x.png new file mode 100644 index 0000000..6414a9d Binary files /dev/null and b/blog/syncthing-anywhere-with-tailscale/CleanShot-2022-01-04-at-9.18.04@2x.png differ diff --git a/blog/syncthing-anywhere-with-tailscale/index.html b/blog/syncthing-anywhere-with-tailscale/index.html new file mode 100644 index 0000000..29243d3 --- /dev/null +++ b/blog/syncthing-anywhere-with-tailscale/index.html @@ -0,0 +1,123 @@ + + + + + + + + Syncthing Anywhere With Tailscale + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+
+

Syncthing Anywhere With Tailscale

+ +

+ • + + + + + TAILSCALE + + + + SYNCTHING + + +

+ +

I don't archive data very often but when I do it must be for a very important one. On the other hand, I somewhat don't trust "cloud" providers and would avoid them as much as I can since my paranoid level is kinda high.

+

And just like everyone else, I run servers at home. The servers are not that powerful but sufficient for my needs. I have two servers run but the most important (and data-heavy) is the box with TrueNAS OS. +Previously I use NextCloud to store my data plus I could access it anywhere. NextCloud is a powerful platform with rich features, I even can run an ActivityPub-based social network there. But the client app is somewhat heavy and the server consumes more resources than I thought, plus the caching system on the client app is somewhat buggy. I can't depend my life on NextCloud, or maybe someday will.

+

I know I can use rsync(1) or even rclone(1) on my computer but they both do different jobs. I need a system to pull-and-push data not just push.

+

And don't ask me why I'm not using BTSync.

+

Then I found Syncthing somewhere. It only does one thing and probably does it well: sync data. Its tagline is "Syncthing is a continuous file synchronization program. It synchronizes files between two or more computers in real time, safely protected from prying eyes. Your data is your data alone and you deserve to choose where it is stored, whether it is shared with some third party, and how it's transmitted over the internet." and it really took my heart.

+

And then I installed Syncthing, used it for some time (until now), and that's why we are here.

+

Syncing concepts

+

Syncthing will establish direct connections between clients (peer-to-peer) as much as possible, and as we know, p2p connection is never easy. And if that's not possible, traffic is bounced through the "relay" until both computers figured out how to establish a direct connection — once again, if possible.

+

Syncthing uses "Device ID" as an identifier so that neither party needs to know each other's IP address thanks to Global Discovery. I just used the Local Discovery feature and turned the 'Enable Relaying' option off so I know the only connection made to .syncthing.net should be just sending an (anonymous) usage report, and I'm fine with that.

+

While this approach only makes my life harder, at least I know what I know even though all packets are encrypted in transit (via TLS) and are every device is authenticated by a cryptographic thing.

+

LAN anywhere

+

All my servers at home are almost locked-down. Only traffic to port 80 is allowed in on my WAN. Not even port forwarding because I don't know much about computer and networking security. +So I designed my home network to be limited to working only on LAN. I don't know exactly how but I just made TCP listen only to the private network. Like, If I can only visit Syncthing GUI via 192.168.1.56 then I can only visit Syncthing GUI over 192.168.1.0/24 network, on my network.

+

Speaking of my Syncthing, it's running on FreeBSD jail with a dedicated IP address from my DHCP server.

+

And as always, the only way to connect a private network over public networks is by establishing a VPN, assuming I'm not interested yet in a commercial "Zero Trust Network" solution that maybe tunnels any TCP/UDP packets through a commercial reverse proxy because the packets are not end-to-end encrypted.

+

Anyways, I use Tailscale and am a huge fan of both the team and the product. Tailscale is built on top Wireguard, and I used to use direct Wireguard until I was overwhelmed with mesh networking.

+

Using Tailscale is pretty straight forward, I don't have to manage keys; know each peer's IP address and public key, define DNS and even perform key rotation. It just works.

+

The problem is that my Syncthing is running on the FreeBSD jail and can't dial devd(8) in the jail whereas Tailscale needs to monitor network state changes (they have a workaround for this! but I haven't tried it yet). Since I'm also running Tailscale on my TrueNAS, I can use "subnet router" which in short acts as a gateway of my physical subnet.

+
tailscale up --advertise-routes=192.168.1.0/24
+

With the above command, I can access my Syncthing (and other jails too) wherever I am!

+

Throughput

+

Although the average latency in transmitting ICMP packets is unnoticeable, in the real world we mostly deal with TCP packets.

+

Syncthing transmits packets over TLS on top of TCP (which is great!) but in my needs it adds overhead as packets are already transmitted over secure protocol (Wireguard).

+

When I'm on my home network, the throughput is about 44 Mbits/s to my Syncthing jail since my laptop is connected over a WiFi network and on a different subnet. Ideally if on the same subnet (and over wired connection) my router and server can reach up to 900MiB/s.

+

What if I'm out of the house?

+

On a 50 Mbps network, using iperf3, I get around 6.49 MiB/s to my Syncthing jail and 8.56 MiB/s to direct host (depending on your network) which is… acceptable, kinda. +How about transferring 1.2GB files to my Syncthing jail over Tailscale?

+

+

2.02 MiB/s is not bad enough, I guess?

+

Conclusion

+

Tailscale here is optional as Syncthing does the NAT traversal for you and also uses a secure protocol. Syncthing will do its best to establish a peer to peer connection and that's great!

+

However, with Tailscale I can access my "shared directory" via SAMBA on my other devices, anywhere. And also don't need any "Relay Server" only if my device can't talk peer-to-peer as Tailscale will do it for me :))

+

As closing, using both Tailscale and Syncthing is the best combination if you don't want to depend on a (cloud) storage providers.

+ +
+
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/blog/unboxing-the-cloud-intro/index.html b/blog/unboxing-the-cloud-intro/index.html new file mode 100644 index 0000000..2cf3551 --- /dev/null +++ b/blog/unboxing-the-cloud-intro/index.html @@ -0,0 +1,84 @@ + + + + + + + + Unboxing The Cloud (UTC): Intro + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+
+

Unboxing The Cloud (UTC): Intro

+ +

+ • + + + + + UTC + + +

+ +

WIP

+ +
+
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/blog/unboxing-the-cloud-utc-vms/index.html b/blog/unboxing-the-cloud-utc-vms/index.html new file mode 100644 index 0000000..87039d2 --- /dev/null +++ b/blog/unboxing-the-cloud-utc-vms/index.html @@ -0,0 +1,84 @@ + + + + + + + + Unboxing The Cloud (UTC): VMs + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+
+

Unboxing The Cloud (UTC): VMs

+ +

+ • + + + + + UTC + + +

+ +

WIP

+ +
+
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/colophon/index.html b/colophon/index.html new file mode 100644 index 0000000..dda86c1 --- /dev/null +++ b/colophon/index.html @@ -0,0 +1,82 @@ + + + + + + + + Colophon + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+

Website colophon

+

This page outlines technical details about this website. You can learn more about the purpose and content of the website, as well as the author on the About page.

+

This site was built using a boring static site generator, written in a boring template language and served by boring S3 compatible storage behind a boring reverse proxy.

+

The three primary fonts I use are:

+ +

Syntax highlighting is done by the great Prism.js, statically generated of course.

+

Every request to this site is handled by Bunny CDNs exclusively in the APAC region for a reason. Nothing here is dynamic, so, maybe stop scanning config.php, ../../etc/passwd, .git or something like that.

+

I'm experimenting with stale-while-revalidate in Bunny by keeping track of the latest commit id under this site to maximize the cache-hit ratio, so apologies if you run into any inconsistency issues.

+

And please don't poison the cache, I guess.

+

If you enjoy the site, consider to giving me a word or some love (my love language is words of affirmation and github sponsors btw).

+
+

You may notice that I use self-hosted, open source privacy-focused web analytics. I respect your DNT preferences (despite its depreciation) and it's likely that your uBlock Origin rule is blocking the umami.js just like mine.

+

Otherwise, no personal information is stored unless you treat your user agent as your own unique identity (sorry).

+
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/index.html b/index.html new file mode 100644 index 0000000..bcabc8d --- /dev/null +++ b/index.html @@ -0,0 +1,141 @@ + + + + + + + + About + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+
+
+ Rizaldy +
+
+

Rizaldy

+

Senior DevOps Engineer

+

+
+
+

Hi, I'm Rizaldy. I am currently a Senior DevOps Engineer at a Data Infrastructure Company based in Jakarta, ID. There have been so many changes in my life, but a few things that have remained unchanged are my interests in:

+
    +
  • Infrastructure Management
    • +
  • System Administration
    • +
  • Developer Experience
    • +
+

I used to do software development profesionally since 2015, mostly web application development. Since the 2020s my deep interests has been in making software developers more productive & happy while keeping systems up & running, securely.

+

I will be happy to help solve problems in any organization in any industry with my expertise.

+
+
+
+

Writings

+

I love writing. Here are the 3 most recent posts:

+
+

+ Proxy Auto-Configuration (PAC) is actually useful +

So I just got my new Mac machine last week. It's just a small machine with 8 CPUs and 8 GB of memory. I've been thinking about buying one for a long time and now the time has come!

+
+

+ Syncthing Anywhere With Tailscale +

I don't archive data very often but when I do it must be for a very important one. On the other hand, I somewhat don't trust "cloud" providers and would avoid them as much as I can since my paranoid level is kinda high.

+
+

+ Expose Web Services at Home via Tailscale for Fun +

I have a small homelab server at home running TrueNAS Core. My home network sits behind NAT and there are probably 3 routers in front of me. +

+
+

View all posts

+
+
+
+

Services

+

I am currently unavailable for consulting work (expected until May 2023).

+
+

+ + DevOps Engineering + +

+

I can help organizations move fast and break less thing by adopting best practices from system administration; release engineering, infrastructure provisioning and management, security, to DevOps advocacy.

+
+
+

+ + R&D Engineer + +

+

Reduce time to market without compromising quality and stability by choosing the right tools for the job. I can help you to choose the right one.

+
+
+

+ + Site Reliability Engineering + +

+

"Hope is not a strategy" as traditional SRE would say. I can help scale from availability; latency, performance, efficiency, change management, monitoring, emergency response, to capacity planning.

+
+
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/services/devops/index.html b/services/devops/index.html new file mode 100644 index 0000000..99be49e --- /dev/null +++ b/services/devops/index.html @@ -0,0 +1,69 @@ + + + + + + + + DevOps Engineering + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+

Still WIP

+

Thank you for stopping by.

+
+ Back to home +
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/services/devrel/index.html b/services/devrel/index.html new file mode 100644 index 0000000..d9a9990 --- /dev/null +++ b/services/devrel/index.html @@ -0,0 +1,69 @@ + + + + + + + + DevRel + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+

Still WIP

+

Thank you for stopping by.

+
+ Back to home +
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/services/rnd/index.html b/services/rnd/index.html new file mode 100644 index 0000000..f002be4 --- /dev/null +++ b/services/rnd/index.html @@ -0,0 +1,69 @@ + + + + + + + + R&D Engineer + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+

Still WIP

+

Thank you for stopping by.

+
+ Back to home +
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/services/sre/index.html b/services/sre/index.html new file mode 100644 index 0000000..98f1961 --- /dev/null +++ b/services/sre/index.html @@ -0,0 +1,69 @@ + + + + + + + + Site Reliability Engineering + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+

Still WIP

+

Thank you for stopping by.

+
+ Back to home +
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + + diff --git a/services/webapp/index.html b/services/webapp/index.html new file mode 100644 index 0000000..64847ec --- /dev/null +++ b/services/webapp/index.html @@ -0,0 +1,69 @@ + + + + + + + + Web App Development + - rizaldy.today + + + + + + + + + + + + + + + + + + +
+
+

Still WIP

+

Thank you for stopping by.

+
+ Back to home +
+ + +
+
+

+ © MMXXIII Rizaldy. Any and all opinions listed here are my own and not representative of my + employers; future, past and present. +

+
+
+ +
+
+ +
+ + + + +