##VERIFIED## Download Tailscale
Collipal Cabello
I actually tried it today and was hoping that moving /var/lib/tailscale/ to the new machine would be sufficient. Unfortunately it did not work. Running tailscale up still asked me to authenticate (and actually overwrote the files I had moved to /var/lib/tailscale/ I think), and it was seen as a new device. Since it was not that big a deal, I set it up as a new machine and removed the old one.
Moving the data to a new machine is not recommended because /var/lib/tailscale contains private keys and those should generally not be copied or moved between machines because it is hard to do so securely and since those keys are proof of identity, the client can not operate correctly if its keys have been duplicated.
Having said that, shutting down tailscale on the old device, moving the contents of /var/lib/tailscale and starting it on the new device should currently work as long as the permissions are preserved.
I have a machine called backup on my tailnet. It used to have a local IP so when I would ping "backup" the DNS would resolve correctly using 192.168.0.50. However, I've now moved the machine off the local network and when I try to ping backp it still tries to ping 192.168.0.50 which fails instead of the resolving via the tailscale IP 100.116.23.88 instead.
I have a laptop with windows 11 thats connected to tailscale and uses the exit node server at home, and i'm getting dns leaks. I use the same exit node on my android phone and i'm getting no dns leaks.
I've sent a user an invite to my tailscale network using an invite link, they signed in with google, and accepted the link. I can see the user on tailscale admin console, but I can't see their machine, and they can't see any of mine. Here are my ACL's
Hi I have installed this version -tailscale-enabler (Tailscale to low powered OpenWRT devices) in my Archer C7 V5 and this work perfect when I want to comunnnicate to remote LAN and Vice versa. When I execute this command attached bellow you can see that there is no any problem.
ROUTER A (Asus RT-AC68U (BCM4708)) - I could install Tailscale without any problem following this. -user/services/vpn/tailscale/start
ROUTER B (TP-Link Archer C7 v5) - instead in this device I just could install this version ( -tailscale-enabler)
Alright, so at this point I have things working pretty well for the basics, and the next task is settingup their private go links service.I followed along with the instructions in the tailscale/golink repository.
Recap: the system binary works fine with "normal" ssh, but not with ssh-via-tailscale. However a manually compiled (same) version of Openssh works fine with both regular ssh, and ssh-over-tailsale. Does anyone know what might be causing this?
I don't think it's any obvious problem with the tailscale network: i.e if I probe via tailscale IP then nmap scan shows correct ports are open, and I can netcat directly to tailscale_ip:22, it is receving and responding.
In order to use the URL of your public vps to access the tailscale one, you could, if the public vps has tailscale installed too, you can use a redirect app on the public one to the tailscale one. I suspect you might have some side effects in some cases, and it might be slower as the traffic would always go through the public vps, but it should work (this I have tried and it worked ).
The first step is to get the tailscale domain of your machine. In the admin console, you can retrieve it simply by clicking on its name in the list of machines: Tailscale. It should be in the format [NAME OF THE MACHINE].[YOUR OWN TAILNET NAME].ts.net
I based this on the manual of tailscale cert and the doc page: Custom certificates Yunohost Documentation
Basically, we move in the folder where the certificates are stored, we move the self-signed certificates of the domain in a dedicated folder, we call tailscale cert with the proper names for the certificate and the key, we set the proper permissions and reload nginx!
From my laptop with the tailscale client installed I can connect to anything within the 192.168.3.0 subnet as expected however I cannot access this subnet from devices behind my firewall at site A. Is there some special routing that is needed to accomplish this? From the setup video for this it looks to be pretty set and forget.
I gave it another try un-commenting preauthkey in openhabian.conf (before the first boot at the same time I set the DEBUG to maximum). Same result. I think this is the full log of the tailscale install is given below:
I just tried a new lxd vm completely from scratch and am happy to report that things work perfectly out of the box with tailscale. I just setup nginx and was immediately able to reach it using the tailscale ip. No configuration changes are required at all and the steps I listed above are completely unnecessary.
ubuntu@vmi971095:$ lxc list
--------------------------------------------------------------------------------------------------------------------------+
NAME STATE IPV4 IPV6 TYPE SNAPSHOTS
--------------------------------------------------------------------------------------------------------------------------+
juju-4f918e-0 RUNNING 100.x.x.17 (tailscale0) fd7a:115c:a1e0:ab12:4843:cd96:625f:9011 (tailscale0) CONTAINER 0
10.105.137.177 (eth0) fd42:a4b5:77b7:d273:216:3eff:fe12:de65 (eth0)
--------------------------------------------------------------------------------------------------------------------------+
What is the problem?
When connecting locally it works fine, the camera image shows up on the controls page .
But when I'm connecting remotely trough tailscale(vpn), it does not work.
Long story short ,I have a separate raspberry that runs pihole, octopi and my ip phone camera is configured trought pihole (It has a local dns entry), in octopi the Stream URL is:
:8080/video
OK, I got to the bottom of this. The IP range 100.64.0.0/10 was blocked by one of the lists downloaded by the ipset blacklist.sh script. This range is reserved for CG Nat, and so effectively is private, but its also the range used by tailscale.
This is a pretty bad idea, but luckily even the web browser has its limits. Ifmy code asks, for example, to perform an HTTP request to/var/run/tailscale/tailscaled.sock, I will be laughed out of the V8 enginebefore I can so much as connect(3).
Applying this technique, our malicious website can make arbitrary requests tothe LocalAPI. Since the API does not apply any additional authentication, apartfrom checking that our browser is running as the same Windows user as theTailscale GUI, we have full privileges, and can introspect and reconfiguretailscaled to taste.
tailscaled is constantly long-polling the control plane, waiting for updatesto the layout of your network. Sometimes, when you want to perform a privilegedaction, like SSHing to a locked-down server, Tailscale will ask you tore-authenticate yourself, by including a PopBrowserURL field in the response.
Exploiting this XSS issue in practice requires some trickery. As part ofhandling the LocalAPI GET request, tailscaled will delete the file from thetemporary directory, since it has now been moved to its final location. Thishappens automatically, so we would need to win a race against the GUI to loadour HTML before it is destroyed.
The path to RCE from here is the same as earlier, but with an extra little bitof polish now available. On the very same day we discovered the XSSvulnerability, the first commits of a new feature were trickling into the mainbranch of the Tailscale GitHub repo.Fast User Switching(work in progress, not yet available in a released Tailscale version) allowsTailscale to switch between multiple accounts without logging out and logging infrom scratch. As part of this, tailscaled may need to switch to another controlplane server, without manually being restarted! We can use this feature to haveour target machine join the Headscale tailnet in just a few seconds, no rebootrequired:
OpenWrt 22.03 and later, use nftables (superseding iptables) as a backend to firewall4. Tailscale is unable to configure nftables automatically and this prevents the tailscale daemon from initializing properly and forwarding traffic.
4. Restart tailscale and add the routes you want to advertise to peers using the --advertise-routes option with a comma separated list of network addresses and CIDRs. The --accept-routes option will manage adding static routes for other subnet routes within your tailnet.
6. Devices on either subnet should be able to route traffic over the VPN. If you've configured this device to be an exit node, it should now be selectable from your tailscale apps as an Exit Node. You can test connectivity with tools like ping or traceroute.
Instead of running the optimized binaries directly, it is recommend that you repack the tailscale.ipk, and tailscaled.ipk packages with the smaller optimized binaries. This will let you benefit from OpenWrt conventions like init scripts, opkg installation receipts, etc, keeping your installation sane and consistent while still being able to use the smaller binaries.
If your device has only 16MB of flash or less, you will need to share the multicall binary between both of the tailscale and tailscaled packages. To do this, stub out the large /usr/sbin/tailscaled binaries contained within these packages, install them, manually copy the optimized binary to the device, and then replace the stubs with symlinks. More detailed instructions on how to do this are below.
The steps below were performed on Debian Linux. I repacked the OpenWrt .ipk for the tailscale and tailscaled packages and replaced the large binaries with small stub scripts that always return true. I did this so that the pre/post scripts will run successfully and the opkg database at /usr/lib/opkg will be consistent. The packages were installed manually and stub files deleted post installation. The multicall binary was then uploaded and symlinks created.
df19127ead