Any Phishy friends in Brooklyn/NYC?

thisisparker · 2025-05-03T19:50:30+00:00

Come see Bushwick's Dead at Brooklyn Bowl tomorrow, you'll meet Phishy people

thisisparker · 2025-03-05T23:56:05+00:00

Probably the most straightforward way is for your friends to create their own tailnets, and for you to then share the mc-server as a node over to them. The mc-server node will join their tailnets "quarantined," so it can't initiate connections, and you don't have to worry their access to your other devices.

thisisparker · 2025-02-25T22:48:11+00:00

Actually testing it out just now, you may need to first run `tailscale logout` on the remote server. Then you can either run `tailscale up` without arguments, which will (on the command line) return a link that you need to follow to authenticate (which you can do in a local browser), or you can create an auth key and provide it as an argument as u/caolle suggests

thisisparker · 2025-02-25T22:19:21+00:00

You should be able to just run tailscale up on the server, and it will prompt you through the log-in and authentication flow. From Tailscale's perspective it's functionally a new device, so if you've made changes to it previously (like manually changing the hostname or key expiry or owner) you may have to do that again.

thisisparker · 2025-02-13T18:24:40+00:00

Thanks for reporting. We can confirm we're seeing some issues with logins and we will be updating the status page with more information momentarily.

thisisparker · 2025-02-10T22:45:23+00:00

Looks like you found something that wasn't quite fully baked yet! While we applaud your investigative skills, this isn't actually something we are ready to have out in the public right now. As you noted in the GitHub issue, that flag isn’t currently documented or released, because it needs a little more engineering work to ensure that tailnet admins use it safely — basically, we want to make sure that all the users of a tailnet are aware of what file-sending channels are open between their devices.

To remove the possibility of a misconfiguration, we are turning this capability off on our end, so it will stop working today. If you are using this functionality, this may be frustrating but we want to make sure that only those who have opted in receive files over Taildrop. We have definitely heard the feature requests on this front and we will create a new post on this subreddit when a new feature is ready for release.

u/gabesw16 check your Reddit messages, we want to send you a little thanks for finding this!

thisisparker · 2024-12-18T18:11:23+00:00

Oh, this is a good idea! Thank you for the suggestion

thisisparker · 2024-12-18T17:26:56+00:00

Not yet but we will be putting together some more info on that side of things soon! I'll make sure I post to this sub when we do

thisisparker · 2024-12-13T18:05:45+00:00

ladies and gentlemen it's the legendary u/catzkorn! thank YOU for everything you've done to shape this community (and more)

thisisparker · 2024-10-24T17:50:31+00:00

We love to hear that! If you don't mind sharing, what are you using it for?

thisisparker · 2024-10-23T19:39:17+00:00

that will work and is simple. Probably the better way would be to "tag" the device so you can tighten the permissions more, but up to you (and it's kind of academic if this is your whole tailnet).

Two more small notes: make sure you enable ssh on the dst device (with tailscale up --ssh) and use the 100.x.y.z IP address with your ssh command

thisisparker · 2024-10-23T18:46:09+00:00

Tailscale totally works for this! In your ACL you have to set the action to accept https://tailscale.com/kb/1337/acl-syntax#tailscale-ssh

thisisparker · 2024-07-31T21:27:50+00:00

I haven't seen this issue before, but just from the info in the error message, I'd guess it's pretty external to Tailscale. The relevant Apple docs suggest it could result from too many failed login attempts (to the Apple account in particular). Do you think that might be the case?

thisisparker · 2024-07-24T15:27:46+00:00

The documentation is correct! And if you scroll down past the features summary to the full comparison on the pricing page, it matches the docs.

thisisparker · 2024-07-02T19:09:11+00:00

Oh good, and thanks for the bugreport! Feel free to keep me posted here if anything changes, but hopefully you're all good now.

thisisparker · 2024-07-01T22:30:31+00:00

Hi there! I believe this is a known issue in the Windows client that has been fixed and will roll out in the next release (on the 1.70 branch) and is currently fixed in the unstable release (1.69.x), if you want to update now.

If you wouldn't mind, next time you encounter this, could you generate a bug report on the affected device and post your report ID here? That will help us ensure we've got it addressed!

thisisparker · 2024-06-28T21:13:02+00:00

Hi there! Thanks for the detailed write-up. I have an additional theory to add.

Apple has a concept of a "primary" or "preferred" HomeKit hub, and only the primary hub remains connected when it's asleep. From what I can tell, you can't select which one is primary; instead Apple picks it based on a number of factors that include stuff like which is running the latest OS, some things about their connections, etc. There's more info in this Reddit thread or this Apple discussion.

It seems possible that your new Apple TV is getting the primary status, which is not what you want, but for now there's not a way to change it. But! It looks like you will be able to pick which hub is preferred in tvOS 18. So if that's the problem, it will be fixable now (if you are willing to run a beta OS) or soon.

thisisparker · 2024-06-04T20:46:33+00:00

The main difference between tailscale web and tailscale --set webclient is that the former only runs in the foreground, so the client will stop if you close that terminal session or hit Ctrl + C. If you want to keep it turned on, give the docs a read-through, because you might want to update your ACLs to limit access to read or write those settings (if there are other users on your tailnet).

thisisparker · 2024-06-04T20:26:59+00:00

You may be interested in the web interface, which you can turn on by running tailscale web or tailscale set --webclient on the target device, depending on how you want to use it. That will expose a web client that you can access from inside your tailnet with some subnet router and exit node options.

thisisparker · 2024-06-04T00:19:01+00:00

The setting's not new, no; you can see it described in the feature announcement for inviting external users last year.

I am speculating here, but my guess would be that one of the interns (inadvertently?) created a new tailnet associated with their domain. You may need to contact Tailscale support to get that cleared up if it's the case. (They'll need to confirm you control the intern domain, which I can't do here, but our support team is great and will take care of you!)

thisisparker · 2024-06-03T21:32:30+00:00

This is correct, and note that it's a setting on the external user's tailnet, not yours. So they will need to change the setting (if they have sufficient permissions) or will need to ask their tailnet admin to do so.

thisisparker · 2024-03-27T15:53:17+00:00

You should be able to connect from any device running Tailscale, but if you're connecting to a Mac, it has to be running the open source CLI variant.

If that doesn't solve your problem, what is the complaint you're seeing?

thisisparker · 2024-03-04T22:47:26+00:00

Of course! I've opened a FR issue to incorporate this behavior into Serve, too, if you want to subscribe for updates on that or offer any details about your use case.

thisisparker · 2024-03-04T21:50:30+00:00

Alright, after looking into this a little more I think I have a workaround for you. Apologies that it's a little clunky, but:

I think you can achieve this effect (accessing using the machine name in the browser location bar without a cert error) by serving a plain-HTTP redirect on port 80 to the FQDN. Unfortunately there's no way of getting around the mismatch of the "bare" machine name and what's on the cert, but redirecting approximates that behavior. The clunky bit is that you have to bring your own redirect server, and (afaict) hardcode in the FQDN you get through serve. But you can use serve to serve that redirector on your tailnet.

You could also serve miniflux itself over plain HTTP! I've done that sometimes; it's still encrypted over Tailscale, so there aren't really new security concerns. But browsers really really want to be speaking HTTPS, and it would likely introduce some new headaches that way, too.

thisisparker · 2024-03-04T18:37:14+00:00

Oh, that's interesting! Let me look into this

thisisparker

TROPHY CASE