A note so that if anyone ever haves this same bit of weirdness, hopefully they might stumble across this. I had a heck of a time searching for this…

So, I have Wireguard set up on my home server along with various services that are designed to only be accessible locally.

If I want to use my home connection/Wireguard from my phone (iOS), this is easy enough to deal with:

Everything works just fine.

However, I found that this connection was sometimes not working, especially if I was on a cellular connection or switching connections. The connection would just hang until I either switched to the full tunnel or turned it off entirely (and made it home).

I tried all manner of switching around the Allowed IPs, adding 10. ranges (for the Wireguard IPs), other private ranges, leaving off specific IPs, all of it.

But what did it take in the end?

Note the difference?

I had to tunnel the DNS.

I believe that this is an iOS specific security behavior–I have public DNS addresses that resolve to a private IP range. It works fine for me and won’t work for anyone else–they’ll go to whatever their local private network is. But iOS (rightfully) thinks that might be a security hole and wouldn’t let the DNS resolve for me–unless I also tunnelled the DNS server (for now I’m using 1.1.1.1 for that; I’m hoping to self host that as well some day).

So if you have: an on-demand wireguard tunnel on iOS with a limited Allowed IPs range and a custom DNS set up, you may just need to tunnel the DNS.

Oy that was a fun one.

But it’s been working absolutely fine for a month now, so all is well. Onward!

Another quick post in a list of CTF techniques: filtering streams with tshark. tshark is the command line half of the packet capture tool Wireshark. The advantage here is it let’s you do all manner of filtering on the command line.

read more...

Another Redis in Rust series. It’s really starting to come together now!

In this post, updating the state to store expiration times + a thread to handle said eviction + the implementation of a small pile more of the general Redis functions.

read more...

And I’m back. It’s been a busy month with the Genuary 2023 series and life in general, but I’m still thinking about Redis in general 😄.

Up this time, let’s see what the official redis-cli app does when talking to our client and actually start handling some commands. Specifically, the very basic commands: SET and GET. With that, we would actually have a (very very basic) keystore up and running!

read more...

Okay, we’ve got a server and we can ping it. Let’s actually make a simple client, so I don’t have to do funny things with echo any more. Specifically, let’s make a REPL!

read more...

Following up from Cloning Redis in Rust: RESP [Part 1], we can parse the protocol. So now… let’s do something with it.

The obvious(ish) next step, in my mind? Make a server. It’s all going to be over the network eventually, so it’s either here or storing data. Here it is!

Specifically, my goal is not to build the networking and data structures for this project from scratch. Where there are primitives or libraries that will do something like networking for me, I’m going to use them.

Ergo:

• tokio for networking (+ async)
• tracing for logging

So, how do I write a simple server in Tokio?

read more...