The reverse proxy was sending the ingressd IPv6 down as the
X-Forwarded-For. This update uses the actual remote addr.
Updates tailscale/corp#9914
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
This change trims the mountPoint from the request URL path before
sending the request to the reverse proxy.
Today if you mount a proxy at `/foo` and request to
`/foo/bar/baz`, we leak the `mountPoint` `/foo` as part of the request
URL's path.
This fix makes removed the `mountPoint` prefix from the path so
proxied services receive requests as if they were running at the root
(`/`) path.
This could be an issue if the app generates URLs (in HTML or otherwise)
and assumes `/path`. In this case, those URLs will 404.
With that, I still think we should trim by default and not leak the
`mountPoint` (specific to Tailscale) into whatever app is hosted.
If it causes an issue with URL generation, I'd suggest looking at configuring
an app-specific path prefix or running Caddy as a more advanced
solution.
Fixes: #6571
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
We persist the ServeConfig, even for tsnet apps. It's quite possible for
the ServeConfig to be out of step with the code. Example: If you run
`ListenFunnel` then later turn it off, the ServeConfig will still show
it enabled, the admin console will show it enabled, but the packet
handler will reject the packets.
Workaround by clearing the ServeConfig in `tsnet.Up`
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
This is to address a possible DNS failure on startup. Before this
change IPv6 addresses would be listed first, and the client dialer would
fail for hosts without IPv6 connectivity.
Bleeding edge Tailscale Nix flake broke after updating to go1.20rc3.
Go 1.20 moved to Go 1.17 as a bootstarp toolchain. Fortunately nixpkgs
nixos-unstable already had a 1.20.nix with bootstrap117.nix.
```
❯ ./result/bin/tailscale version
1.37.0-dev
track: unstable (dev); frequent updates and bugs are likely
go version: go1.20rc3-ts6a17f14c05
```
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
You can now install Tailscale on Windows via [Scoop](https://scoop.sh).
This change adds a check to `packageTypeWindows()`, looking at the exe's path, and
checking if it starts with: `C:\User\<NAME>\scoop\apps\tailscale`. If so, it
returns `"scoop"` as the package type.
Fixes: #6988
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
On macOS (AppStore and macsys), we need to bind to ""/all-interfaces
due to the network sandbox. Ideally we would only bind to the
Tailscale interface, but macOS errors out if we try to
to listen on privileged ports binding only to a specific
interface.
We also implement the lc.Control hook, same as we do for
peerapi. It doesn't solve our problem but it's better that
we do and would likely be required when Apple gets around to
fixing per-interface priviliged port binding.
Fixes: #6364
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
Create an interface and mock implementation of tailscale.LocalClient for
serve command tests.
Updates #6304Closes#6372
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
Fixes#6400
open up GETs for localapi serve-config to allow read-only access to
ServeConfig
`tailscale status` will include "Funnel on" status when Funnel is
configured. Prints nothing if Funnel is not running.
Example:
$ tailscale status
<nodes redacted>
# Funnel on:
# - https://node-name.corp.ts.net
# - https://node-name.corp.ts.net:8443
# - tcp://node-name.corp.ts.net:10000
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
There are three specific requirements for Funnel to work:
1) They must accept an invite.
2) They must enable HTTPS.
3) The "funnel" node attribute must be appropriately set up in the ACLs.
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>
Current behavior is broken. tailscale serve text / "" returns no error
and shows up in tailscale serve status but requests return a 500
"empty handler".
Adds an error if the user passes in an empty string for the text
handler.
Closes#6405
Signed-off-by: Shayne Sweeney <shayne@tailscale.com>