There are 4 adapters, direct, mitm, http(https) and shadowsocks.
There are 6 actions, http(https):http_adapter, shadowsocks:shadowsocks_adapter, direct:direct_adapter, speed:select fastest adapters, mitm:mitm_adapter, and reject:just close this socket.
There are 6 rule types, geoip, domain, domain_keyword, domain_suffix, ip_cidr and other, note: rules are in order.
Filters is for packet capture, just work for http. if it is https, please use mitm action
Note
If you are using https adapter, the auth will be ignore
TUN and TAP are virtual networking devices which allow userland applications to receive packets sent to it. The userland applications can also send their own packets to the devices and they will be forwarded to the kernel.
This is useful for developping tunnels, private networks or virtualisation systems.
Supported Features
Creation of TUN and TAP devices;
Autodetection of available TUN or TAP devices;
Setting and getting the MAC address of the device;
Setting and getting the MTU of the device;
Setting the status of the device (up/down);
Setting the IPv4 address and netmask of the device;
Setting the persistence mode of the device;
Setting the name of the device (Linux only);
Setting the description of the device (OpenBSD and FreeBSD only);
Wrapper libraries for other languages.
Supported Systems
OpenBSD;
Linux;
NetBSD;
Darwin (up to High Sierra).
Current Porting Efforts
Windows;
FreeBSD.
In the future
AIX;
Solaris.
Install
Requires
cmake;
C and C++ compilers.
Build
This project is built with cmake:
$ mkdir build; cd build $ cmake ../ $ make # make install
It is possible to tweak the destination folder for the install rule with the environment variable DESTDIR. The default behaviour is to install under the /usr/lib folder for Linux and /usr/local/lib for everyone else.
Example make invocation:
$ DESTDIR=/tmp make install
The following options can be tweaked:
ENABLE_CXX: Enable building of the C++ wrapper library libtuntap++;
ENABLE_PYTHON: Enable building of the Python wrapper library pytuntap;
BUILD_TESTING: Enable building of the regress tests;
BUILD_SHARED_LIBS: Build shared libraries instead of static ones.
Other languages bindings
We currently provide wrappers for two other languages: C++ and Python, respectively named libtuntap++ and pytuntap. More instructions about them is provided in the bindings folder.
The C++ library is built by default and can be disabled with the flag ENABLE_CXX.
The Python library is disabled by default and requires both ENABLE_CXX and ENABLE_PYTHON to work. You will also need Python 3.6 and Boost libraries.
A series of regress tests can be built with the BUILD_TESTING option. They are enabled by default. A list and a description for each of them can be found in the regress folder.
Example cmake invocation:
$ mkdir build; cd build $ cmake -D BUILD_TESTING=ON ../ # make test
Static or shared
Up to version 0.3 the libtuntap CMakeFiles.txt exported two libraries: one shared, one static. To simplify the building of the wrapper libraries it was decided to only build one. The default is to build a static library but this behaviour can be changed with the option BUILD_SHARED_LIBS.
Example cmake invocation:
$ mkdir build; cd build $ cmake -D BUILD_SHARED_LIBS=ON ../ $ make
Local configurations
The main CMakeFiles.txt includes an optional CMakeFiles.txt.local which can be used to store persistent options across builds.
Although Go strives to be a cross platform language, cross compilation from one platform to another is not as simple as it could be, as you need the Go sources bootstrapped to each platform and architecture.
The first step towards cross compiling was Dave Cheney's golang-crosscompile package, which automatically bootstrapped the necessary sources based on your existing Go installation. Although this was enough for a lot of cases, certain drawbacks became apparent where the official libraries used CGO internally: any dependency to third party platform code is unavailable, hence those parts don't cross compile nicely (native DNS resolution, system certificate access, etc).
A step forward in enabling cross compilation was Alan Shreve's gonative package, which instead of bootstrapping the different platforms based on the existing Go installation, downloaded the official pre-compiled binaries from the golang website and injected those into the local toolchain. Since the pre-built binaries already contained the necessary platform specific code, the few missing dependencies were resolved, and true cross compilation could commence... of pure Go code.
However, there was still one feature missing: cross compiling Go code that used CGO itself, which isn't trivial since you need access to OS specific headers and libraries. This becomes very annoying when you need access only to some trivial OS specific functionality (e.g. query the CPU load), but need to configure and maintain separate build environments to do it.
Enter xgo
My solution to the challenge of cross compiling Go code with embedded C/C++ snippets (i.e. CGO_ENABLED=1) is based on the concept of lightweight Linux containers. All the necessary Go tool-chains, C cross compilers and platform headers/libraries have been assembled into a single Docker container, which can then be called as if a single command to compile a Go package to various platforms and architectures.
Installation
Although you could build the container manually, it is available as an automatic trusted build from Docker's container registry (not insignificant in size):
docker pull karalabe/xgo-latest
To prevent having to remember a potentially complex Docker command every time, a lightweight Go wrapper was written on top of it.
go get github.com/karalabe/xgo
Usage
Simply specify the import path you want to build, and xgo will do the rest:
$ xgo github.com/project-iris/iris ...
$ ls -al -rwxr-xr-x 1 root root 9995000 Nov 24 16:44 iris-android-16-arm -rwxr-xr-x 1 root root 6776500 Nov 24 16:44 iris-darwin-10.6-386 -rwxr-xr-x 1 root root 8755532 Nov 24 16:44 iris-darwin-10.6-amd64 -rwxr-xr-x 1 root root 7114176 Nov 24 16:45 iris-ios-5.0-arm -rwxr-xr-x 1 root root 10135248 Nov 24 16:44 iris-linux-386 -rwxr-xr-x 1 root root 12598472 Nov 24 16:44 iris-linux-amd64 -rwxr-xr-x 1 root root 10040464 Nov 24 16:44 iris-linux-arm -rwxr-xr-x 1 root root 7516368 Nov 24 16:44 iris-windows-4.0-386.exe -rwxr-xr-x 1 root root 9549416 Nov 24 16:44 iris-windows-4.0-amd64.exe
If the path is not a canonical import path, but rather a local path (starts with a dot . or a dash /), xgo will use the local GOPATH contents for the cross compilation.
Build flags
A handful of flags can be passed to go build. The currently supported ones are
-v: prints the names of packages as they are compiled
-x: prints the build commands as compilation progresses
-race: enables data race detection (supported only on amd64, rest built without)
-tags='tag list': list of build tags to consider satisfied during the build
-ldflags='flag list': arguments to pass on each go tool link invocation
-buildmode=mode: binary type to produce by the compiler
Go releases
As newer versions of the language runtime, libraries and tools get released, these will get incorporated into xgo too as extensions layers to the base cross compilation image (only Go 1.3 and above will be supported).
You can select which Go release to work with through the -go command line flag to xgo and if the specific release was already integrated, it will automatically be retrieved and installed.
$ xgo -go 1.6.1 github.com/project-iris/iris
Additionally, a few wildcard release strings are also supported:
latest will use the latest Go release (this is the default)
1.6.x will use the latest point release of a specific Go version
1.6-develop will use the develop branch of a specific Go version
develop will use the develop branch of the entire Go repository
Output prefixing
xgo by default uses the name of the package being cross compiled as the output file prefix. This can be overridden with the -out flag.
$ ls -al -rwxr-xr-x 1 root root 9995000 Nov 24 16:44 iris-v0.3.2-android-16-arm -rwxr-xr-x 1 root root 6776500 Nov 24 16:44 iris-v0.3.2-darwin-10.6-386 -rwxr-xr-x 1 root root 8755532 Nov 24 16:44 iris-v0.3.2-darwin-10.6-amd64 -rwxr-xr-x 1 root root 7114176 Nov 24 16:45 iris-v0.3.2-ios-5.0-arm -rwxr-xr-x 1 root root 10135248 Nov 24 16:44 iris-v0.3.2-linux-386 -rwxr-xr-x 1 root root 12598472 Nov 24 16:44 iris-v0.3.2-linux-amd64 -rwxr-xr-x 1 root root 10040464 Nov 24 16:44 iris-v0.3.2-linux-arm -rwxr-xr-x 1 root root 7516368 Nov 24 16:44 iris-v0.3.2-windows-4.0-386.exe -rwxr-xr-x 1 root root 9549416 Nov 24 16:44 iris-v0.3.2-windows-4.0-amd64.exe
Branch selection
Similarly to go get, xgo also uses the master branch of a repository during source code retrieval. To switch to a different branch before compilation pass the desired branch name through the --branch argument.
$ ls -al -rwxr-xr-x 1 root root 4171248 Nov 24 16:40 goimports-android-16-arm -rwxr-xr-x 1 root root 4139868 Nov 24 16:40 goimports-darwin-10.6-386 -rwxr-xr-x 1 root root 5186720 Nov 24 16:40 goimports-darwin-10.6-amd64 -rwxr-xr-x 1 root root 3202364 Nov 24 16:40 goimports-ios-5.0-arm -rwxr-xr-x 1 root root 4189456 Nov 24 16:40 goimports-linux-386 -rwxr-xr-x 1 root root 5264136 Nov 24 16:40 goimports-linux-amd64 -rwxr-xr-x 1 root root 4209416 Nov 24 16:40 goimports-linux-arm -rwxr-xr-x 1 root root 4348416 Nov 24 16:40 goimports-windows-4.0-386.exe -rwxr-xr-x 1 root root 5415424 Nov 24 16:40 goimports-windows-4.0-amd64.exe
Remote selection
Yet again similarly to go get, xgo uses the repository remote corresponding to the import path being built. To switch to a different remote while preserving the original import path, use the --remote argument.
If you used the above branch or remote selection machanisms, it may happen that the path you are trying to build is only present in the specific branch and not the default repository, causing Go to fail at locating it. To circumvent this, you may specify only the repository root for xgo, and use an additional --pkg parameter to select the exact package within, honoring any prior branch and remote selections.
$ xgo --pkg cmd/goimports golang.org/x/tools ...
$ ls -al -rwxr-xr-x 1 root root 4194956 Nov 24 16:38 goimports-android-16-arm -rwxr-xr-x 1 root root 4164448 Nov 24 16:38 goimports-darwin-10.6-386 -rwxr-xr-x 1 root root 5223584 Nov 24 16:38 goimports-darwin-10.6-amd64 -rwxr-xr-x 1 root root 3222848 Nov 24 16:39 goimports-ios-5.0-arm -rwxr-xr-x 1 root root 4217184 Nov 24 16:38 goimports-linux-386 -rwxr-xr-x 1 root root 5295768 Nov 24 16:38 goimports-linux-amd64 -rwxr-xr-x 1 root root 4233120 Nov 24 16:38 goimports-linux-arm -rwxr-xr-x 1 root root 4373504 Nov 24 16:38 goimports-windows-4.0-386.exe -rwxr-xr-x 1 root root 5450240 Nov 24 16:38 goimports-windows-4.0-amd64.exe
This argument may at some point be integrated into the import path itself, but for now it exists as an independent build parameter. Also, there is not possibility for now to build mulitple commands in one go.
Limit build targets
By default xgo will try and build the specified package to all platforms and architectures supported by the underlying Go runtime. If you wish to restrict the build to only a few target systems, use the comma separated --targets CLI argument:
--targets=linux/arm: builds only the ARMv5 Linux binaries (arm-6/arm-7 allowed)
--targets=windows/*,darwin/*: builds all Windows and OSX binaries
--targets=*/arm: builds ARM binaries for all platforms
--targets=*/*: builds all suppoted targets (default)
By default xgo tries to cross compile to the lowest possible versions of every supported platform, in order to produce binaries that are portable among various versions of the same operating system. This however can lead to issues if a used dependency is only supported by more recent systems. As such, xgo supports the selection of specific platform versions by appending them to the OS target string.
--targets=ios-8.1/*: cross compile to iOS 8.1
--targets=android-16/*: cross compile to Android Jelly Bean
--targets=darwin-10.9/*: cross compile to Mac OS X Mavericks
--targets=windows-6.0/*: cross compile to Windows Vista
The supported platforms are:
All Android APIs up to Android Lollipop 5.0 (API level ids)
All Windows APIs up to Windows 8.1 limited by mingw-w64 (API level ids)
OSX APIs in the range of 10.6 - 10.11
All iOS APIs up to iOS 9.3
Mobile libraries
Apart from the usual runnable binaries, xgo also supports building library archives for Android (android/aar) and iOS (ios/framework). Opposed to gomobile however xgo does not derive library APIs from the Go code, so proper CGO C external methods must be defined within the package.
In the case of Android archives, all architectures will be bundled that are supported by the requested Android platform version. For iOS frameworks xgo will bundle armv7 and arm64 by default, and also the x86_64 simulator builds if the iPhoneSimulator.sdk was injected by the user:
Create a new docker image based on xgo: FROM karalabe/xgo-latest
Inject the simulator SDK: ADD iPhoneSimulator9.3.sdk.tar.xz /iPhoneSimulator9.3.sdk.tar.xz
Bootstrap the simulator SDK: $UPDATE_IOS /iPhoneSimulator9.3.sdk.tar.xz
CGO dependencies
The main differentiator of xgo versus other cross compilers is support for basic embedded C/C++ code and target-platform specific OS SDK availability. The current xgo release introduces an experimental CGO dependency cross compilation, enabling building Go programs that require external C/C++ libraries.
It is assumed that the dependent C/C++ library is configure/make based, was properly prepared for cross compilation and is available as a tarball download (.tar, .tar.gz or .tar.bz2). Further plans include extending this to cmake based projects, if need arises (please open an issue if it's important to you).
Such dependencies can be added via the --deps argument. They will be retrieved prior to starting the cross compilation and the packages cached to save bandwidth on subsequent calls.
A complex sample for such a scenario is building the Ethereum CLI node, which has the GNU Multiple Precision Arithmetic Library as it's dependency.
Seeexamples For advanced SSH configuration use~/.ssh/config
Usage
sshsocksvpn --help usage: sshsocksvpn [-h] -n NAME [-p PATH] {start,stop}
positional arguments: {start,stop} Command to perform
optional arguments: -h, --help show this help message and exit -n NAME, --name NAME Name of the server to start -p PATH, --path PATH Config file to use default ~/.config/sshvpn.cfg
I create the script mostly for usage by myself but if it will be useful for somebody else - it'll be great !
You need to have server with "white" IP that will work as proxy (it can be OpenWRT router for example) and you need to compile badvpn-tun2socks for your system and badvpn-udpgw for your remote server.
It is possible that I'll add some help and more detailed description here but no promise.
I'm very beginner in shell scripting and linux so there may be much better way to get proper functionality. I'll be very grateful for any feedback, bug report or comment. Feel free to fork and contibute...
tun2socks is used to "socksify" TCP (IPv4 and IPv6) connections at the network layer. It implements a TUN virtual network interface which accepts all incoming TCP connections (regardless of destination IP), and forwards them through a SOCKS server. This allows you to forward all connections through SOCKS, without any need for application support. It can be used, for example, to forward connections through a remote SSH server or through Tor. Because of how it works, it can even be installed on a Linux router to transparently forward clients through SOCKS.
Installation
tun2socks is part of BadVPN. If you're on Linux, just build BadVPN with its CMake build system (or use the Gentoo package net-misc/badvpn, the Arch AUR or Ubuntu PPA packages). You can build just tun2socks without any other software in the package; this way, you don't need to have the NSS and OpenSSL libraries installed: mkdir badvpn-build cd badvpn-build cmake /path/to/badvpn -DBUILD_NOTHING_BY_DEFAULT=1 -DBUILD_TUN2SOCKS=1 make Alternatively, you can use a shell script to compile tun2socks only, in case using CMake is a problem for you: http://badvpn.googlecode.com/svn/trunk/compile-tun2sock.sh . If you're on Windows, simply grab the Windows build of BadVPN.
Example (tunnelling through SSH)
First create a TUN device:
On Linux, use ip tuntap add dev tun0 mode tun user .
On Windows, install OpenVPN (or, if you already have it, click the start menu shortcut that creates a new TAP-Win32 device). The new device will appear in Network Adapters and will be identifiable by its Device Name field (saying Tap-Win32 something).
Configure IP for the device: assign IP address 10.0.0.1, netmask 255.255.255.0. Now start the program (on Linux, run it as ): badvpn-tun2socks --tundev --netif-ipaddr 10.0.0.2 --netif-netmask 255.255.255.0 --socks-server-addr 127.0.0.1:1080 where is:
on Linux, tun0,
on Windows, "tap0901::10.0.0.1:10.0.0.0:255.255.255.0" (the three numbers are TUN interface IP address, network, and subnet mask).
NOTE: --netif-ipaddr 10.0.0.2 is not a typo. It specifies the IP address of the virtual router inside the TUN device, and must be different than the IP of the TUN interface itself. Now you should be able to ping the virtual router's IP (10.0.0.2). Connect to the SSH server, passing -D localhost:1080 to the ssh command to enable dynamic forwarding. This will make ssh open a local SOCKS server which badvpn-tun2socks will use. If you use Putty, go to Connection->SSH->Tunnels, type 1080 in Source port, choose Dynamic and click Add. All that remains is to route connections through the TUN device instead of the existing default gateway. This is done as follows:
Add a route to the SSH server through your existing gateway, with a lower metric than the original default route.
If your DNS servers are in the Internet (rather than your local network), also add routes for them (like for the SSH server). This is needed because tun2socks does not forward UDP by default (see below).
Add default route through the virtual router in the TUN device, with a lower metric than the original default route, but higher than the SSH and DNS routes.
This will make all external connections go through the TUN device, except for the SSH connection (else SSH would go through the TUN device, which would go through... SSH). For example (assuming there are no existing default routes with metric <=6; otherwise remove them or change their metrics), in Linux: route add gw metric 5 route add default gw 10.0.0.2 metric 6 Or on Windows (NOTE: tun2socks must be running and the interface of the default gateway must be working for these to succeed): route add metric 5 route add 0.0.0.0 mask 0.0.0.0 10.0.0.2 metric 6 These routes will not persist across a reboot. You should probably make scripts that install and remove them. You can remove a route by changing the add to del or delete, depending on whether you're in Linux or Windows. Windows 7: This OS has problems with respecting route metrics. If after a few minutes of normal operation connections suddenly stop being routed into tun2socks and instead go out the original default gateway, for no apparent reason, take a look at issue 5. One workaround is to temporarily remove the original default route.
UDP forwarding
tun2socks can forward UDP, however this requires a daemon, badvpn-udpgw to run on the remote SSH server. To enable UDP forwarding:
On the remote SSH server, start: badvpn-udpgw --listen-addr 127.0.0.1:7300
Add the following arguments to badvpn-tun2socks: --udpgw-remote-server-addr 127.0.0.1:7300
IPv6 support
NOTE: IPv6 support is only available in the SVN repository, and is not yet in a release version. IPv6 forwarding in tun2socks works much like IPv4 forwarding. It is enabled using the --netif-ip6addr command line option. For example, you can assign the address fdfe:dcba:9876::1 to the TUN interface, and tell tun2socks to assume the address fdfe:dcba:9876::2, like this: badvpn-tun2socks ...other..options... --netif-ip6addr fdfe:dcba:9876::2/126 Once this is done, you should be able to ping the virtual router inside tun2socks at fdfe:dcba:9876::2. To forward IPv6 through tun2socks, update your routing table appropriately. UDP forwarding via badvpn-udpgw also supports IPv6. It is irrelevant whether the connection to the badvpn-udpgw program is made using IPv4 or IPv6, as long as it works.
Using with Tor
The goal here is to have all connections initiating from a virtual machine go through Tor via tun2socks. NOTE: It is hard, but not impossible, to use tun2socks with Tor on a single host without a virtual machine, since the OS would have to route tun2socks outgoing connections differently from other programs. This can be achieved using policy routing, but this guide does not provide any more information. WARNING: software in the VM may reveal information about you without your knowledge. The Tor project recommends only using the Tor Browser Bundle as your web browser. However, it is not possible to properly use this browser together with transparent proxying as described here. You should however at least use something like Chrome's Incognito mode; however, this is not equivalent to using the bundle. You can read more about the privacy features of the Tor Browser Bundle you may be missing on in this document. NOTE: DNS queries done by the guest will be slower than if applications were directly configured to use Tor. The following steps show how to set transparent proxying for the virtual machine.
Let's assume you use VirtualBox to run the VM, and you run Tor on the host.
Set the Network Adapter type in VirtualBox to Host Only.
On the host, identify the IP address of the host on the VirtualBox interface. This IP address can found and configured in File->Preferences->Network. Most likely it will be 192.168.56.1. On a Linux host, this interface will likely be called vboxnet0.
On the host, configure Tor to provide a SOCKS and DNS server for the VM to use. Do this by adding the following options to the torrc file (use the right IP address): "SocksListenAddress 192.168.56.1" and "DNSPort 192.168.56.1:53".
Start Tor on the host. If possible, verify that it's listening on port numbers 9050 and 53 on the IP address of the VirtualBox interface (e.g. 192.168.56.1, not localhost!). On a Linux host, you can do this by running netstat -nlp as root.
In the VM, configure the local network interface (the normal one, not TAP). Do not use DHCP; only set the IP address (e.g. 192.168.56.2). At this point, is should be possible to ping the guest from the host, and the reverse.
On the guest, create and configure the TUN device for tun2socks, as is described in SSH tunneling example above. Additionally, set the default gateway (10.0.0.2) as part of interface configuration, and use Tor's DNS server, e.g. 192.168.56.1.
Then finally start tun2socks in the guest, similarly to how it is done in the SSH example above. However, instead of using 127.0.0.1:8080 as the SOCKS server, use Tor's SOCKS server running on the host, e.g. 192.168.56.1:9050. Note that you don't have to manually configure any routes; the default route on the TUN interface is all that is needed. This is because the SOCKS and DNS servers are on the local network, so you don't have to override the default tun2socks route.
All traffic from the VM should now be going through TOR. TCP connections will be intercepted by tun2socks and will be sent through Tor's SOCKS server; DNS queries will be sent by the guest's OS directly to Tor's DNS server. UDP will not work because Tor doesn't support UDP. This configuration has been tested using a Linux host and a Windows XP guest; however, it should work with any OS combination assuming the relevant software (tor, tun2socks) is supported. In particular, you're limited to Linux and Windows guests. NOTE: Tor will issue warnings that IP addresses come without hostnames: "Warning: Your application (using socks5 to port 80) is giving Tor only an IP address....". This is normal and you might be able to silence it by adding these to torrc: SafeSocks 0 TestSocks 0 WarnUnsafeSocks 0
from https://code.google.com/archive/p/badvpn/wikis/tun2socks.wiki
OpenShift SDN Ecnrypted tunnel will create a VPN mesh between OpenShift cluster SDNs in such a way that IP packets become routable between pods across SDNs.
The archietcture of the tunnel is depicted in this diagram:
The process works as follows
SETUP PHASE:
a tun device is created by the tunnel daemon set
the tun is wired to the bridge so that ip packets destined to the CIDR of the other cluster are routed to the tunnel.
TRANSMIT PHASE:
a packet is put in the bridge with destination to the CIDR of one of the nodes of the other cluster
the flow rules send the packet to the tunnel
the tunnel daemonset process manages the wired side of the tunnel and sends the UDP-encapsulated and encrypted packet to the correct VIP of the other cluster
RECEIVE PHASE:
A UDP encapsulated and encrypted packet is received by the VIP and sent to the corresponding tunnel ds process
the tunnel daemonset process extracts and decrypts the packet from the UDP envelope and puts it in the tun device.
the packet ends up in the bridge.
the bridge examines the destination, which will be local to the node, and delivers the packet immediately.
The routing of the packets works as described in this diagram:
Service Proxying
Service Proxying is the ability to load balance connection to Kubernetes services to pods. In this case we want to be able to load abalnce conenction to a service of a connected Kubernetes cluster to the pods of this cluster. To do so we use IPVS managed bykube-router, the architecture is the following:
Discovery
Discovery is the ability to discover Kuberneets service IPs by quering a DNS. We define the convention that each cluster has a domain of this pattern.cluster., besides the usual.cluster.local. We usecorednsto setup a DNS server with the followign architecture:
Pods that need to use that DNS need the following in their template:
