http proxy not working since 1.22.x #4811
Comments
DentonGentry
added
L2 Few
|
bug still present in 1.28.0 |
|
@steom What do your logs look like in 1.28.0? Are there still proxy errors in them? Can you post a snippet or send a bug report ID? |
|
tshttpproxy: CONNECT response from http://proxy.lan.org:80 for target "controlplane.tailscale.com:443" (auth "Basic xxxxxxxxxxxxxxxxxx... |
|
control: doLogin(regen=false, hasUrl=false) |
|
@steom Which version of Windows are you running? |
|
any, tailscale 1.22.2 works flawlessy with any win os the "Improved HTTPS proxy handling for windows client" introduced in 1.24.0 broke the use of http proxy with any win os, socks5 works always fine instead, (indeed in changelog of 1.24.0 there is no modify for it) in 1.28.0 it's still present the missing services message from the gui when http proxy is set. |
… to mkwinsyscall, fix memory leak The definition of winHTTPProxyInfo was using the wrong type (uint16 vs uint32) for its first field. I fixed that type. Furthermore, any UTF16 strings returned in that structure must be explicitly freed. I added code to do this. Finally, since this is the second time I've seen type safety errors in this code, I switched the native API calls over to use wrappers generated by mkwinsyscall. I know that would not have helped prevent the previous two problems, but every bit helps IMHO. Updates #4811 Signed-off-by: Aaron Klotz <aaron@tailscale.com>
… to mkwinsyscall, fix memory leak The definition of winHTTPProxyInfo was using the wrong type (uint16 vs uint32) for its first field. I fixed that type. Furthermore, any UTF16 strings returned in that structure must be explicitly freed. I added code to do this. Finally, since this is the second time I've seen type safety errors in this code, I switched the native API calls over to use wrappers generated by mkwinsyscall. I know that would not have helped prevent the previous two problems, but every bit helps IMHO. Updates #4811 Signed-off-by: Aaron Klotz <aaron@tailscale.com>
… to mkwinsyscall, fix memory leak The definition of winHTTPProxyInfo was using the wrong type (uint16 vs uint32) for its first field. I fixed that type. Furthermore, any UTF16 strings returned in that structure must be explicitly freed. I added code to do this. Finally, since this is the second time I've seen type safety errors in this code, I switched the native API calls over to use wrappers generated by mkwinsyscall. I know that would not have helped prevent the previous two problems, but every bit helps IMHO. Updates #4811 Signed-off-by: Aaron Klotz <aaron@tailscale.com>
… to mkwinsyscall, fix memory leak The definition of winHTTPProxyInfo was using the wrong type (uint16 vs uint32) for its first field. I fixed that type. Furthermore, any UTF16 strings returned in that structure must be explicitly freed. I added code to do this. Finally, since this is the second time I've seen type safety errors in this code, I switched the native API calls over to use wrappers generated by mkwinsyscall. I know that would not have helped prevent the previous two problems, but every bit helps IMHO. Updates #4811 Signed-off-by: Aaron Klotz <aaron@tailscale.com>
… to mkwinsyscall, fix memory leak The definition of winHTTPProxyInfo was using the wrong type (uint16 vs uint32) for its first field. I fixed that type. Furthermore, any UTF16 strings returned in that structure must be explicitly freed. I added code to do this. Finally, since this is the second time I've seen type safety errors in this code, I switched the native API calls over to use wrappers generated by mkwinsyscall. I know that would not have helped prevent the previous two problems, but every bit helps IMHO. Updates #4811 Signed-off-by: Aaron Klotz <aaron@tailscale.com>
|
4dbdb19 is an attempt to fix this, which will be in the 1.30 client to be released next week. |
|
1.30 the same, don't connect. 1.22.2 still works okay. |
|
@steom can you tell me a bit more about your environment? Are your machines members of a domain? |
|
It's indifferent, also happens in workgroups pc. The culprint are the changes introduced with 1.24.0. Maybe "Improved HTTPS proxy handling" for windows client or something related to: |
|
1.32.0 the same, don't connect. 1.22.2 still works okay. |
|
1.32.2 the same, don't connect. 1.22.2 still works okay. bootstrapDNS("derp5.tailscale.com", "103.43.75.49") for "log.tailscale.io" error trying bootstrapDNS("derp2e.tailscale.com", "192.73.252.134") for "controlplane. bootstrapDNS("derp4e.tailscale.com", "134.122.74.153") for "log.tailscale.io" er logtail: upload: log upload of 355 bytes compressed failed: Post "https://log.ta Received error: register request: Post "https://controlplane.tailscale.com/machi |
|
Possibly related: #4394 |
To collect some data on how widespread this is and whether there's any correlation between different versions of Windows, etc. Updates #4811 Change-Id: I003041d0d7e61d2482acd8155c1a4ed413a2c5c4 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
To collect some data on how widespread this is and whether there's any correlation between different versions of Windows, etc. Updates #4811 Change-Id: I003041d0d7e61d2482acd8155c1a4ed413a2c5c4 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
To collect some data on how widespread this is and whether there's any correlation between different versions of Windows, etc. Updates #4811 Change-Id: I003041d0d7e61d2482acd8155c1a4ed413a2c5c4 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
|
I can reproduce this. I put a Windows VM on a VLAN without internet access and ran a little CONNECT proxy on the LAN that Windows could reach and configured Windows to use it:
Browsing the web in Edge/etc works fine through it, but Tailscale doesn't start:
|
|
Debugging. The path I'm hitting is: if err == syscall.Errno(ERROR_WINHTTP_AUTODETECTION_FAILED) {
metricErrDetectionFailed.Add(1)
setNoProxyUntil(10 * time.Second)
return nil, nil
} |
|
Hah, of course. We're dealing with two (at least) different Window proxying settings/layers. The one I set in settings (which works in Edge, etc) isn't apparently winhttp (per So, uh, I guess there are different APIs we need to get the Proxy as set by
|
|
But, uh, ... current user? The |
|
Okay, I confirmed that var kernel32 = windows.NewLazySystemDLL("kernel32.dll")
var globalFree = kernel32.NewProc("GlobalFree")
func globalFreeMaybe(ptr *uint16) {
if ptr != nil {
_, _, _ = globalFree.Call(uintptr(unsafe.Pointer(ptr)))
}
}
var winHttp = windows.NewLazySystemDLL("winhttp.dll")
var winHttpGetIEProxyConfigForCurrentUser = winHttp.NewProc("WinHttpGetIEProxyConfigForCurrentUser")
type tWINHTTP_CURRENT_USER_IE_PROXY_CONFIG struct {
fAutoDetect int32 // BOOL
lpszAutoConfigUrl *uint16
lpszProxy *uint16
lpszProxyBypass *uint16
}
func WinHttpGetIEProxyConfigForCurrentUser() (string, error) {
if err := winHttpGetIEProxyConfigForCurrentUser.Find(); err != nil {
return "", err
}
p := new(tWINHTTP_CURRENT_USER_IE_PROXY_CONFIG)
r, _, err := winHttpGetIEProxyConfigForCurrentUser.Call(uintptr(unsafe.Pointer(p)))
if r == 1 {
defer globalFreeMaybe(p.lpszProxy)
defer globalFreeMaybe(p.lpszProxyBypass)
return windows.UTF16PtrToString(p.lpszProxy), nil
}
return "", err
} |
|
But @steom, where in Windows do you configure your proxy? And what type? I don't yet understand how it ever worked for you, assuming you're setting the proxy in the same place I just found that doesn't work. So I suspect you're setting it elsewhere. |
|
Environment variables were working at some point, sort of (logs didn't use the proxy, and it could make the GUI unable to talk to the service) Edit: that was my vague recollection, actual details in #4394 |
|
|
@steom, can you answer my question? Where are you configuring your proxy, and how? |
|
From the GUI - Control Panel | System | Environment | System/User Variables |
…kups fail There was a mechanism in tshttpproxy to note that a Windows proxy lookup failed and to stop hitting it so often. But that turns out to fire a lot (no PAC file configured at all results in a proxy lookup), so after the first proxy lookup, we were enabling the "omg something's wrong, stop looking up proxies" bit for awhile, which was then also preventing the normal Go environment-based proxy lookups from working. This at least fixes environment-based proxies. Plenty of other Windows-specific proxy work remains (using WinHttpGetIEProxyConfigForCurrentUser instead of just PAC files, ignoring certain types of errors, etc), but this should fix the regression reported in #4811. Updates #4811 Change-Id: I665e1891897d58e290163bda5ca51a22a017c5f9 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
…kups fail There was a mechanism in tshttpproxy to note that a Windows proxy lookup failed and to stop hitting it so often. But that turns out to fire a lot (no PAC file configured at all results in a proxy lookup), so after the first proxy lookup, we were enabling the "omg something's wrong, stop looking up proxies" bit for awhile, which was then also preventing the normal Go environment-based proxy lookups from working. This at least fixes environment-based proxies. Plenty of other Windows-specific proxy work remains (using WinHttpGetIEProxyConfigForCurrentUser instead of just PAC files, ignoring certain types of errors, etc), but this should fix the regression reported in #4811. Updates #4811 Change-Id: I665e1891897d58e290163bda5ca51a22a017c5f9 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
…kups fail There was a mechanism in tshttpproxy to note that a Windows proxy lookup failed and to stop hitting it so often. But that turns out to fire a lot (no PAC file configured at all results in a proxy lookup), so after the first proxy lookup, we were enabling the "omg something's wrong, stop looking up proxies" bit for awhile, which was then also preventing the normal Go environment-based proxy lookups from working. This at least fixes environment-based proxies. Plenty of other Windows-specific proxy work remains (using WinHttpGetIEProxyConfigForCurrentUser instead of just PAC files, ignoring certain types of errors, etc), but this should fix the regression reported in #4811. Updates #4811 Change-Id: I665e1891897d58e290163bda5ca51a22a017c5f9 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
…kups fail There was a mechanism in tshttpproxy to note that a Windows proxy lookup failed and to stop hitting it so often. But that turns out to fire a lot (no PAC file configured at all results in a proxy lookup), so after the first proxy lookup, we were enabling the "omg something's wrong, stop looking up proxies" bit for awhile, which was then also preventing the normal Go environment-based proxy lookups from working. This at least fixes environment-based proxies. Plenty of other Windows-specific proxy work remains (using WinHttpGetIEProxyConfigForCurrentUser instead of just PAC files, ignoring certain types of errors, etc), but this should fix the regression reported in #4811. Updates #4811 Change-Id: I665e1891897d58e290163bda5ca51a22a017c5f9 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
…kups fail There was a mechanism in tshttpproxy to note that a Windows proxy lookup failed and to stop hitting it so often. But that turns out to fire a lot (no PAC file configured at all results in a proxy lookup), so after the first proxy lookup, we were enabling the "omg something's wrong, stop looking up proxies" bit for awhile, which was then also preventing the normal Go environment-based proxy lookups from working. This at least fixes environment-based proxies. Plenty of other Windows-specific proxy work remains (using WinHttpGetIEProxyConfigForCurrentUser instead of just PAC files, ignoring certain types of errors, etc), but this should fix the regression reported in #4811. Updates #4811 Change-Id: I665e1891897d58e290163bda5ca51a22a017c5f9 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
|
1.34.0 finally re-works. I've notice that the last seen information from the website it's not update in "realtime" anymore, like in 1.22.2
|
|
Good to hear! Closing this. @steom, can you file a separate bug about the "Last seen"? That "Last seen" value is only relevant when the node is offline. While the node is actively connected, we account for it differently. The UI should probably just say "Now" or something when it's already connected. (cc @tailscale/frontend) |
…kups fail There was a mechanism in tshttpproxy to note that a Windows proxy lookup failed and to stop hitting it so often. But that turns out to fire a lot (no PAC file configured at all results in a proxy lookup), so after the first proxy lookup, we were enabling the "omg something's wrong, stop looking up proxies" bit for awhile, which was then also preventing the normal Go environment-based proxy lookups from working. This at least fixes environment-based proxies. Plenty of other Windows-specific proxy work remains (using WinHttpGetIEProxyConfigForCurrentUser instead of just PAC files, ignoring certain types of errors, etc), but this should fix the regression reported in tailscale#4811. Updates tailscale#4811 Change-Id: I665e1891897d58e290163bda5ca51a22a017c5f9 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
just to inform that
Improved HTTPS proxy handling for windows client from 1.24.0, 124.2 and still today 1.26.0
broke support for http proxy.
version 1.22.2 works great instead!
control: control server key from https://controlplane.tailscale.com: ts2021=[fSeS+], legacy=[nlFWp]
control: RegisterReq: onode= node=[25gj+] fup=false
tshttpproxy: winhttp: GetProxyForURL("http://controlplane.tailscale.com:80/ts2021"): ERROR_INVALID_PARAMETER [unexpected]
logtail: dial "log.tailscale.io:443" failed: dial tcp 34.229.201.48:443:
Received error: PollNetMap: Post "https://controlplane.tailscale.com/machine/map": connection attempts aborted by context: context deadline exceeded
trying bootstrapDNS("derp9b.tailscale.com", "144.202.67.195") for "log.tailscal.io" ...
bootstrapDNS("derp9b.tailscale.com", "144.202.67.195") for "log.tailscale.io" eror: Get "https://derp9b.tailscale.com/bootstrap-dns?q=log.tailscale.io": dialcp 144.202.67.195:443:
trying bootstrapDNS("derp8b.tailscale.com", "2a03:b0c0:1:d0::ec1:e001") for "lo.tailscale.io" ...
bootstrapDNS("derp8b.tailscale.com", "2a03:b0c0:1:d0::ec1:e001") for "log.tailsale.io" error: Get "https://derp8b.tailscale.com/bootstrap-dns?q=log.tailscale.
o": dial tcp [2a03:b0c0:1:d0::ec1:e001]:443:
trying bootstrapDNS("derp8c.tailscale.com", "206.189.16.32") for "log.tailscaleio" ...
The text was updated successfully, but these errors were encountered: