Discovering Tailscale Through WebVM

My journey with Tailscale began when I came across WebVM, an impressive project that allows you to run a virtual machine directly in your browser. Intrigued by the possibilities, I delved deeper and discovered that Tailscale could help me create a seamless, private network across all my devices.

What is Tailscale?

Tailscale is a mesh VPN network built on top of WireGuard, specifically using the WireGuard-go implementation. It allows you to create a secure, encrypted network between your devices, no matter where they are located.

Key Features

• Free Plan Available: Tailscale offers a free plan that is sufficient for personal use, allowing up to 20 devices.
• Ease of Use: Setting up Tailscale is straightforward. With minimal configuration, you can have your own network up and running quickly.
• Cross-Platform Support: Tailscale works exceptionally well across the Apple ecosystem, including iOS, tvOS, and macOS.
• Magic DNS Service: It provides a built-in DNS service that makes it easy to address your devices by name.

Performance on Different Platforms

While Tailscale shines on Apple devices, in my experience, it hasn’t performed as well on Windows. I encountered some connectivity and stability issues on Windows machines, which may vary based on individual setups.

My Tailscale Setup

Here’s how I leveraged Tailscale to connect my devices and access my home network seamlessly.

Running Tailscale on Apple TV

I installed Tailscale on my Apple TV, which stays online 24/7. This makes it an excellent candidate for a consistently available node in my network.

• Enabling Subnet Routing: By enabling subnet routing on the Apple TV, I can access other devices on the same local network, such as my NAS and router, as if I were connected locally.
• Setting Up an Exit Node: I configured the Apple TV as an exit node, allowing me to route internet traffic through my home network. This is useful when I need to access geo-restricted content or ensure a secure connection.

Connecting Other Devices

I also installed Tailscale on my MacBook and iPhone, which allows all my personal devices to communicate over the secure network, no matter where I am.

Benefits I’ve Enjoyed

• Secure Remote Access: I can securely access my home network devices from anywhere.
• Consistent Environment: All my devices appear on the same network, simplifying file sharing and remote management.
• No Need for Complex VPN Setups: Tailscale eliminates the need for traditional VPN configurations, port forwarding, or dynamic DNS services.

Conclusion

Tailscale has transformed the way I interact with my devices across different locations. Its ease of use and robust feature set make it an excellent choice for anyone looking to create a personal, secure network.

If you’re interested in simplifying your network setup and want a hassle-free way to connect your devices, I highly recommend giving Tailscale a try.

Links:

• Tailscale Official Website
• WebVM Project on GitHub
• WireGuard-go on GitHub

Note: This post reflects my personal experiences with Tailscale. Performance may vary based on individual configurations and devices.

After moving house, there are many more devices at home that need internet access. However, I don’t want to configure a proxy on each device, so I thought of using a transparent gateway.

Transparent Gateway

After some research, I found that the easiest way is to use the premium version of Clash, although I didn’t know when Clash released a premium version. I mainly referred to this article. It’s much simpler than setting up iptables.

Network Topology

I have a 10-year-old Thinkpad x230 at home, which is perfect for this purpose. Here is a simple topology diagram.

Router1 is a fiber-optic modem with routing capabilities, Router2 is a regular router, with the gateway and DNS pointing to the Thinkpad, where Linux is running to act as a transparent gateway with Clash on top.

                                 +------------+
                                 |            |
                                 |  Internet  |
                                 |            |
                                 +-----+------+
                                       |
                                 +-----+------+
                                 |            |
                      +----------+  Router1   +-----------+
                      |          |            |           |
                      |          +------------+           |
                      |                                   |
                      |                                   |
                +-----+-----+                       +-----+------+
                |           |                       |            |
     +----------+  Router2  +----------+            |  Thinkpad  |
     |          |           |          |            |            |
     |          +-----+-----+          |            +------------+
     |                |                |
     |                |                |
     |                |                |
+----+-----+     +----+-----+    +-----+-----+
|          |     |          |    |           |
|   Mac    |     |  iPad    |    |  iPhone   |
|          |     |          |    |           |
+----------+     +----------+    +-----------+

Add DNS Section in Clash Configuration

dns:
enable: true
listen: 0.0.0.0:53
enhanced-mode: fake-ip
nameserver:
  - 114.114.114.114
fallback:
  - 8.8.8.8

Clash tun Feature Section

tun:
enable: true
stack: system # or gvisor
dns-hijack:
  - any:53
  - tcp://any:53
auto-route: true
auto-detect-interface: true

For traffic forwarding, simply edit /etc/sysctl.conf on the Thinkpad and add net.ipv4.ip_forward=1, then execute sysctl -p to apply it. After that, point the gateway and DNS of Router2 to the Thinkpad, and you’re done.

Network Protocols

Initially, I used native HTTP2 for unblocking, but it cannot proxy UDP. When only a few devices need unblocking, it doesn’t matter whether UDP is used, but with many devices at home, some of them can only use UDP. I considered socks + tls, but it didn’t feel secure and required opening odd ports like UDP 443. It felt like giving away my intentions. Eventually, I chose Trojan, which essentially mimics native HTTPS. Trojan has two versions; I used Trojan-go simply because I didn’t want to manage dependencies. Also, I’m more familiar with Go.

Trojan-go has a requirement for a genuinely accessible HTTP server, so I used the simplest Python http.server. Back in Python 2, it was called simplehttp. You can simply use python3 -m http.server 80 and optionally add --directory to specify a directory.

Additionally, Trojan-go requires the client to fill in the SNI, which means using the domain used during key application. Therefore, prerequisites like applying for the domain, applying for Let’s Encrypt certificates, and configuring crontab must all be completed. There’s a learning curve, but I had done it before, so I just skipped that part.

For the client part, you can use Clash directly, and refer to here for guidance.

Bridging highly simulates a network card, making the router believe that the virtual machine’s network card truly exists. Personally, I feel it’s similar to resistors connected in parallel, whereas NAT (another common virtual machine network connection method) is more like parasitizing on the host’s network card.

Why Use Bridging

It allows you to treat the virtual machine as a completely independent machine, enabling mutual access with the external network (which is not possible with NAT).

How to Configure Bridging

In CentOS 6, refer to the command-line method in this article.

We don’t use the GUI method because:

• We’re unsure which options to fill in on the last screen.
• We don’t know how to reset if we make a wrong selection.

Command-line steps:

1. Check if bridge-utils is installed:

   rpm -q bridge-utils
   

   Usually, it’s already installed. If not, install it:

   su -
   yum install bridge-utils
   

2. Verify your network interfaces:

   Run ifconfig to ensure you have at least three network interfaces:

   eth0      Link encap:Ethernet  HWaddr 00:18:E7:16:DA:65
             inet addr:192.168.0.117  Bcast:192.168.0.255  Mask:255.255.255.0
             inet6 addr: fe80::218:e7ff:fe16:da65/64 Scope:Link
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:556 errors:0 dropped:0 overruns:0 frame:0
             TX packets:414 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:1000
             RX bytes:222834 (217.6 KiB)  TX bytes:48430 (47.2 KiB)
             Interrupt:16 Base address:0x4f00
   
   lo        Link encap:Local Loopback
             inet addr:127.0.0.1  Mask:255.0.0.0
             inet6 addr: ::1/128 Scope:Host
             UP LOOPBACK RUNNING  MTU:16436  Metric:1
             RX packets:8 errors:0 dropped:0 overruns:0 frame:0
             TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:480 (480.0 b)  TX bytes:480 (480.0 b)
   
   virbr0    Link encap:Ethernet  HWaddr 52:54:00:2A:C1:7E
             inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:0 errors:0 dropped:0 overruns:0 frame:0
             TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:0 (0.0 b)  TX bytes:2793 (2.7 KiB)
   

3. Navigate to the network scripts directory:

   su –
   cd /etc/sysconfig/network-scripts
   

4. Bring down the eth0 interface:

   ifdown eth0
   

   This step is crucial and must be performed locally. When I first configured this, I didn’t shut down the network (since I was working remotely). I didn’t realize that updating the ifcfg-eth0 configuration without restarting the network would immediately apply changes, resulting in loss of network connectivity.

5. Edit ifcfg-eth0:

   In the ifcfg-eth0 file, include:

   DEVICE=eth0
   ONBOOT=yes
   BRIDGE=br0
   

   Keep only these three lines in the file. There’s no need to configure an IP address here. Bridging seems to replace the original network card with the bridge, so you can delegate the configuration to the bridge.

6. Create a new file ifcfg-br0:

   DEVICE=br0
   ONBOOT=yes
   TYPE=Bridge
   BOOTPROTO=static
   IPADDR=xxx.xxx.xxx.xxx   # Use the IP you originally had in ifcfg-eth0
   GATEWAY=xxx.xxx.xxx.xxx  # Your gateway address
   NETMASK=255.255.255.0    # Your netmask
   DNS1=xxx.xxx.xxx.xxx     # Your primary DNS server
   DNS2=xxx.xxx.xxx.xxx     # Your secondary DNS server (if any)
   STP=on
   DELAY=0
   

   Note: Replace xxx.xxx.xxx.xxx with your actual network settings.

7. Bring up the interfaces:

   ifup br0
   ifup eth0
   

8. Verify the bridge interface:

   Check ifconfig to ensure that br0 is now present.

9. Update firewall rules:

   Edit /etc/sysconfig/iptables and add:

   -A INPUT -i br0 -j ACCEPT
   

   (This is a general example; you may need to adjust it based on your specific firewall configuration.)

10. Restart the firewall:

    service iptables restart
    

11. Configure bridging in virt-manager:

    When creating a new virtual machine using virt-manager, you can now select br0 for the network interface. Without this bridge, the bridging option would not be available.

Note: When configuring the IP inside the virtual machine, be sure to specify the GATEWAY. Otherwise, the virtual machine will only be able to access the internal network and not the external network. At this point, the virtual machine won’t automatically discover the gateway.