Feature request: Direct mode

[stardast]

Hi!
Thanks for this great project!

It would be nice to have the feature to start alpaca in a mode where all requests are routed as "direct". This way I could always keep the proxy configured and start alpaca with this flag when I'm connected to a network without a proxy.

[samuong]

Hi @stardast, thanks! While this flag could potentially be added, I'm wondering if this use case is already supported in other ways...

Alpaca will try to download the PAC file when it is launched, as well as every time it notices that your network has changed (if a network interface is removed or added). If it is unable to download the PAC file, all requests will go direct. It was written this way so that things would work when you're connected to a network without a proxy (e.g. when you take your work laptop off of the company network).

This might not work if your PAC URL is reachable on networks without a proxy. This is the case for publicly accessible PAC scripts, as well as file:// URIs. Is this the case for you?

[stardast]

Thanks for the reply!
In my case the proxy.pac file is not publicly available, but the recognition of network change should be improved: the interfaces may remain the same, but the network may change. However, I believe I can accomplish what I had in mind using NetworkManager-dispatcher restarting alpaca.

I don't know if it's a bug but if i start alpaca with a local file i get this:
pacfetcher.go: 100: Attempting to download PAC from file: ///opt/alpaca/proxyVPN.pac
pacfetcher.go: 127: Successfully resolved public address; bypassing proxy

the last sentence is incorrect, I am in the network with the proxy.

Thanks!

[samuong]

While Alpaca doesn't have a direct mode flag, you could set up a PAC file which contains function FindProxyForURL(url, host) { return "DIRECT" }. Running alpaca -C file:///opt/alpaca/proxydirect.pac would effectively be the same as running with a flag that forced it into direct mode.

But ideally, the best way to handle this would be to put something at the top of your PAC file which checks whether you're on the VPN or not. There are a few ways to do this, e.g. if you know of a site (or proxy) that is only resolveable when you're on the VPN, then you could use if (isResolveable("internal.example.com")) { return "DIRECT" }. Another way would be to check if myIpAddress() returns an IP within your VPN's IP range.

Unfortunately I don't know of a generic way to do this. When support for file:// URIs was added, we tried to build this "connectivity check" inside Alpaca, and the way it works is to do a reverse DNS lookup of 8.8.8.8. This worked fine in my company's internal network/VPN, but turned out to not work in the general case. So you're right, this is a bug, and I suspect maybe this check just needs to be removed. This might break some other use cases though, so let me have a think about how best to do this and I'll get back to you in a few days.

[samhaque]

Hey @samuong, is it possible to bump priority on this as our organization also hit the same roadblock when using file:// based local PAC file

[samuong]

@stardast and @samhaque sorry for losing track of this one. I wanted to check in with a few people to see if this would break things for them, but didn't hear back. I think the best way to fix this is to remove the dodgy connection check (which does a reverse DNS lookup on 8.8.8.8). Any users that rely on this will need to check for proxy connectivity themselves (within their custom pac file) before returning a PROXY directive.