These are Lantern-specific middleware components for the HTTP Proxy in Go:
-
A filter for access tokens
-
A filter for devices, based on their IDs
-
A filter for Pro users
-
A connection preprocessor to intercept bad requests and send custom responses
-
Custom responses for mimicking Apache in certain cases
All pushes to the main branch are automatically deployed to production via CI in GitHub Actions.
All pushes to the canary branch are automatically deployed to the canary binary distribution URL for any proxies running the canary version.
See .github/workflows/go.yml, which uses the make build Makefile target NOT THE LEGACY make dist-on-docker.
The http-proxy binary is distributed through S3 as this object. This object is versioned in S3, so if you need to roll back to a prior deployed version, you can simply delete the currently deployed version from here.
Build it with go build or with make build.
To get list of the command line options, please run http-proxy-lantern -help.
config.ini.default also has the list of options, make a copy (say, config.ini) and tweak it as you wish, then run the proxy with
http-proxy-lantern -config config.ini
To regenerate config.ini.default just run http-proxy-lantern -dumpflags.
go test
Use this for verbose output:
TRACE=1 go test
Keep in mind that cURL doesn't support tunneling through an HTTPS proxy, so if you use the -https option you have to use other tools for testing.
You can run a local server with a set configuration (just a default ReflectToSite proxy as of this writing) with
make local-proxy
Note that make local-proxy is really just an alias for make local-rts -- i.e. a ReflectToSite local proxy.
You can then copy the rts-proxies.yaml file to your Lantern config directory, as in:
cp ./rts/rts-proxies.yaml ~/Library/Application\ Support/Lantern/proxies.yaml
Run a Lantern client accordingly from lantern-desktop, as in:
./lantern -readableconfig -stickyconfig
If you're developing a new transport, you can also add new versions of those files for that transport as you're testing.
You have two options to test it: the Lantern client or checkfallbacks.
Keep in mind that they will need to send some headers in order to avoid receiving 404 messages (the chained server response if you aren't providing them).
Currently, the only header you need to add is X-Lantern-Device-Id.
If you are using checkfallbacks, make sure that both the certificate and the token are correct. A 404 will be the reply otherwise. Running the server with -debug may help you troubleshooting those scenarios.
To prevent spoofers from fetching Lantern config with fake client IP, we need to attach auth tokens to such requests. Both below options should be supplied. Once http-proxy-lantern receives GET request to one of the cfgsvrdomains, it sets X-Lantern-Config-Auth-Token header with supplied cfgsvrauthtoken, and X-Lantern-Config-Client-IP header with the IP address it sees.
-cfgsvrauthtoken string
Token attached to config-server requests, not attaching if empty
-cfgsvrdomains string
Config-server domains on which to attach auth token, separated by comma
With option -pprofaddr=localhost:6060, you can always access lots of debug information from http://localhost:6060/debug/pprof. Ref https://golang.org/pkg/net/http/pprof/.
Be sure to only listen on localhost or private addresses for security reason.
Sometimes it's useful to deploy a preview binary to a single server. This can
be done using either deployTo.bash or onlyDeployTo.bash. They do the same
thing but deployTo.bash first runs make dist whereas onlyDeployTo.bash
copies the existing binary at dist/http-proxy.
Sometimes it's useful to deploy a custom binary to one or more tracks. This can
be done by running make deploy-custom and setting the environment variable
BINARY_NAME to the desired binary name, e.g.
http-proxy-custom-hwh33-tlsmasq999.
To deploy a track running the custom binary, add the custom_proxy_binary key
to the track's pillar data, mapped to the name specified above. At the time of
writing, track pillar data is specified in the track_pillars structure in
lantern-infrastructure/etc/current_production_track_config.py
For example:
'etc-teleport': {
'custom_proxy_binary': 'http-proxy-custom-teleport-1',
},
Most of our proxies have servermasq enabled on them.
This means that you cannot ssh directly into them. Instead you have to use a cloudmaster as a bastion jump host.
You can do this relatively straightforwardly by adding this to your ~/.ssh/config file:
Host bastion
HostName CM_IP
ProxyCommand none
Host *
User lantern
ProxyJump bastion
where you'd replace CM_IP with an actual cloudmaster ip (probably the one closest to you).
./onlyDeployTo.bash <ip address>
Once you're done checking out the preview, revert back to the production binary with:
./revertToProductionBinary.bash <ip addres>
To view proxy logs on a given machine, run:
journalctl -e -u http-proxy
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent