Cloud Native Tunnel

Overview

inlets is a Cloud Native Tunnel written in Go

Expose your local endpoints to the Internet or within a remote network, without touching firewalls.

Build Status License: MIT Go Report Card Documentation GitHub All Releases

Follow @inletsdev on Twitter

English | 中文文档

Intro

inlets ® is how you connect services between different networks. You won't have to think about managing firewalls, NAT or VPNs again. Services can be tunnelled securely over a websocket and accessed on a remote network privately, or exposed on the Internet using an exit-server (5-10USD / mo).

Why do we need this project? Similar tools such as ngrok and Argo Tunnel from Cloudflare are closed-source, have limits built-in, can work out expensive, and have limited support for arm/arm64, Docker and Kubernetes. Ngrok's domain is also often banned by corporate firewall policies meaning it can be unusable. Other open-source tunnel tools are designed to only set up a single static tunnel.

With inlets you can set up your own self-hosted tunnel, copy over the static binary and start tunnelling traffic without any arbitrary limits or restrictions. When used with TLS, inlets can be used with most corporate HTTP proxies.

Conceptual diagram

Conceptual diagram for inlets

Do you use inlets? Sponsor the author

Alex is the maintainer of inlets, if you use the project, become a sponsor on GitHub.

Sponsor this project

Find out more now

About inlets

inlets uses a websocket to create to create a tunnel between a client and a server. The server is typically a machine with a public IP address, and the client is on a private network with no public address.

inlets is considered production-ready, but you should do some testing before you depend on it. For a commercially-supported solution, see inlets PRO, which enables additional use-cases, has more thorough testing and secure defaults.

Private or public tunnels?

  • A private tunnel is where you start a tunnel to a server and only expose it on the server's LAN address (this can replace the use-cases where you would use a VPN or Kubernetes federation)
  • A public tunnel is where you expose the private service to users via the server's public IP

Features

  • Tunnel HTTP or websockets
  • Client announces the tunnelled services to the server
  • Expose multiple sites on same port through the use of DNS entries and a Host header
  • Upgrade to link encryption using TLS for websockets (wss://) with an external add-on, or inlets PRO
  • Shared authentication token for the client and server
  • Automatic reconnects for when the connection drops

Distribution:

  • Binaries and Docker images for multiple architecture - Intel and ARM
  • Kubernetes YAML files and Dockerfile
  • systemd unit file for client/server
  • Native Kubernetes Service and LoadBalancer integration with inlets-operator

Going to production with inlets PRO

The following features / use-cases are covered by inlets PRO:

  • Tunnel L4 TCP traffic such as websockets, databases, reverse proxies, remote desktop and SSH
  • Tunnel L7 HTTPS / REST traffic - with automated Let's Encrypt support
  • Expose multiple ports from the same client - i.e. 80 and 443
  • Run a reverse proxy or Kubernetes IngressController directly on your host
  • Automated TLS for the control-plane
  • Commercial services & support
  • Documentation, blog posts, tutorials and videos

inlets projects

inlets is a Cloud Native Tunnel and is listed on the Cloud Native Landscape under Service Proxies.

  • inlets PRO - Cloud Native Tunnel - TCP, HTTP & websockets with automated TLS encryption
  • inlets-operator - Public IPs for your private Kubernetes Services and CRD
  • inletsctl - The fastest way to create self-hosted exit-servers
  • inlets - Cloud Native Tunnel for HTTP only - configure TLS separately, not available for inletsctl or inlets-operator

Get inlets

You can install the CLI with a curl utility script, brew or by downloading the binary from the releases page. Once installed you'll get the inlets command.

Install the CLI

Note: inlets is made available free-of-charge, but you can support its ongoing development and sign up for updates through GitHub Sponsors 💪

Utility script with curl:

# Install to local directory
curl -sLS https://get.inlets.dev | sh

# Install to /usr/local/bin/
curl -sLS https://get.inlets.dev | sudo sh

Note: the brew distribution is maintained by the brew team, so it may lag a little behind the GitHub release.

Binaries are made available on the releases page for Linux (x86_64, armhf & arm64), Windows (experimental), and for Darwin (MacOS). You will also find SHA checksums available if you want to verify your download.

Windows users are encouraged to use git bash to install the inlets binary.

Using inlets

Video demo

Using inlets I was able to set up a public endpoint (with a custom domain name) for my JavaScript & Webpack Create React App.

https://img.youtube.com/vi/jrAqqe8N3q4/hqdefault.jpg

Quickstart tutorial

You can run inlets between any two computers with connectivity, these could be containers, VMs, bare metal or even "loop-back" on your own laptop.

Try the quickstart tutorial now on your local computer.

Documentation & tutorials

inlets and inlets PRO have their own documentation site:

Official docs: docs.inlets.dev

See also: advanced usage of inlets including Docker, Kubernetes, multiple-services, and binding to private IPs

What are people saying about inlets?

Read community tutorials, the launch posts on Hacker News, and send a PR if you have written about inlets or inlets PRO:

You can share about inlets using @inletsdev, #inletsdev, and https://inlets.dev.

Do you use inlets or inlets PRO?

Add an entry to the ADOPTERS.md file with your use-case.

Sponsorship

You can become a GitHub Sponsor as an individual user or company.

Sponsor alex or Sponsor inlets

Disclaimer

Developers wishing to use inlets within a corporate network are advised to seek approval from their administrators or management before using the tool. By downloading, using, or distributing inlets, you agree to the LICENSE terms & conditions. No warranty or liability is provided.

Development

See CONTRIBUTING.md

Other Kubernetes port-forwarding tooling

  • kubectl port-forward - built into the Kubernetes CLI, forwards a single port to the local computer.
  • inlets PRO - exit-server automation, multiple ports, TCP and automatic Let's Encrypt
  • kubefwd - Kubernetes utility to port-forward multiple services to your local computer.
  • kurun - Run main.go in Kubernetes with one command, also port-forward your app into Kubernetes.

inlets® is a registered trademark of OpenFaaS Ltd. All rights reserved, registered company in the UK: 11076587

Issues
  • Switch from go/flags to spf13/cobra

    Switch from go/flags to spf13/cobra

    Signed-off-by: RaviTezu [email protected]

    Description/Changes

    This PR replaces the go/flags package with spf13/cobra for parsing the command line arguments:

    • Moved parse_upstream.go code into the cmd/client.go as we are do the parsing only in the client mode. Thoughts?
    • Introduced pkg/errors to wrap the context around the errors which are retuned. Thoughts? We can just log/Print them as we are currently doing, no strong feelings here. But I think, wrapping errors using pkg/errors will help in future as the codebase bigger and bigger.
    • Updated the README.md file with the changes introduced to the commands.

    How Has This Been Tested?

    Looks like we are yet to add the unit tests, so I have tested the changes by manually running the commands and see how the arguments are being parsed in client and server modes.

    How are existing users impacted? What migration steps/scripts do we need?

    Yes, there's a change in the way the existing users run the commands. For example, -server=true/false has been split into two subcommands like inlets server and inlets client. I have updated the README.md with the changes. I think, we will need to bump up the version? Feel free to let me know I will update this PR with bumping up the version.

    Checklist:

    I have:

    • [X] updated the documentation and/or roadmap (if required)
    • [X] read the CONTRIBUTION guide
    • [X] signed-off my commits with git commit -s

    Adding [WIP] to the PR title as there are some open questions and will remove it once we have the answers. Closes #7

    new-contributor 
    opened by RaviTezu 20
  • Running Exit Node on Google Compute Engine

    Running Exit Node on Google Compute Engine

    Wrote a short tutorial to show how to run an Inlets Exit Node on Google Compute Engine:

    https://pretired.dazwilkin.com/posts/200122/

    Description

    How Has This Been Tested?

    How are existing users impacted? What migration steps/scripts do we need?

    Checklist:

    I have:

    • [ ] updated the documentation and/or roadmap (if required)
    • [ ] read the CONTRIBUTION guide
    • [ ] signed-off my commits with git commit -s
    • [ ] added unit tests
    new-contributor 
    opened by DazWilkin 15
  • Add buildkit support for cross-platform docker image publishing

    Add buildkit support for cross-platform docker image publishing

    Description

    PR for implemention of #60 multi-arch docker image publishing

    • Added rules to Makefile (and invoke in .travis.yml)

      1. launch a buildkitd

      2. build cross-platform docker container images (amd64, arm64, armhf) and tag

      3. Tag archs and latest. Create and push multi-arch image using docker manifest. Tags for the pushed images are set in the Makefile

    • Created Dockerfile.multi-arch

      • works like standard project Dockerfile, but adds cross-platform support
        1. go build builds appropriate arch in build stage
        2. alpine-based image is created adding ca-certificates and the app user.

    TODO

    • [X] Get signoff on docker image platform tag names (Mooted with 'latest' tag)
    • [X] annotate image manifests and support multi-arch image tags
    • [X] ~~replace Dockerfile with Dockerfile.multi-arch?~~

    How Has This Been Tested?

    # run as root user on an Ubuntu 18.04 machine
    make buildkitd
    BUILDKIT_PUSH_TO_REPO=false make docker-buildkit-images
    
    # run as root on an ubuntu VM
    make buildkitd
    DOCKER_HUB_REPO=dpcrook/inlets make docker-buildkit-images
    DOCKER_HUB_REPO=dpcrook/inlets make docker-buildkit-push-manifests
    

    With this PR, on each of the supported architectures, something like the following will work:

    $ sudo docker run -i dpcrook/inlets:latest
    $ uname -m
    aarch64
    

    Also works on each of support platform using simple image tag :Version (no -{arch} necessary)

    $ docker run -i dpcrook/inlets:2.0.3-5-gf88adc4
    $ uname -m
    armv7l
    

    How are existing users impacted? What migration steps/scripts do we need?

    This PR will affect the travis/release phase for docker images.

    • Adds support for building cross-platform docker images, including on travis-ci.

    Checklist:

    I have:

    • [X] updated the documentation and/or roadmap (if required)
    • [X] read the CONTRIBUTION guide
    • [X] signed-off my commits with git commit -s
    • [X] added unit tests (implicit in travis-ci builds and deploys)
    new-contributor 
    opened by idcrook 14
  • Build multi-arch docker images

    Build multi-arch docker images

    Description

    Build and publish multi-arch docker images; closes #60

    How Has This Been Tested?

    I've built the image and pushed it to matevzmihalic/inlets:2.5.0-2-g769dfe8-dirty. I've ran the image on Packet ARM server and on my computer and it shows help and version just fine. I didn't try to run client or server, but I think it should work.

    How are existing users impacted? What migration steps/scripts do we need?

    Checklist:

    I have:

    • [ ] updated the documentation and/or roadmap (if required)
    • [x] read the CONTRIBUTION guide
    • [x] signed-off my commits with git commit -s
    • [ ] added unit tests
    new-contributor 
    opened by matevzmihalic 13
  • adding the ASCII logo to the help messages and the version message

    adding the ASCII logo to the help messages and the version message

    Signed-off-by: Zaher Ghaibeh [email protected]

    Description

    This should get https://github.com/alexellis/inlets/issues/83 off.

    How Has This Been Tested?

    I test it manually by executing the commands

    Screen Shot 2019-08-19 at 12 47 04 PM

    Screen Shot 2019-08-19 at 12 47 51 PM Screen Shot 2019-08-19 at 12 48 09 PM

    How are existing users impacted? What migration steps/scripts do we need?

    Checklist:

    I have:

    • [x] updated the documentation and/or roadmap (if required)
    • [x] read the CONTRIBUTION guide
    • [x] signed-off my commits with git commit -s
    • [ ] added unit tests
    new-contributor 
    opened by zaherg 9
  • Add files to create RPMs

    Add files to create RPMs

    Signed-off-by: Eduardo Minguez Perez [email protected]

    Description

    Added a script and a spec file to be able to build an RPM

    I've been trying to do a better spec based on the official documentation but it seems that it only works in Fedora 31 (unreleased yet). Also due to the project uses dep I'm not sure if doing it properly will work

    How Has This Been Tested?

    Fedora 30 box:

    sudo dnf install rpm-build redhat-rpm-config
    sh -x hack/createRPM.sh
    sudo dnf install ./inlets-*.rpm -y
    

    Check:

    $ rpm -ql inlets
    /usr/lib/systemd/system/inlets.service
    /usr/local/bin/inlets
    /usr/share/doc/inlets
    /usr/share/doc/inlets/README.md
    /usr/share/licenses/inlets
    /usr/share/licenses/inlets/LICENSE
    $ systemctl status inlets
    ● inlets.service - Inlets Server Service
       Loaded: loaded (/usr/lib/systemd/system/inlets.service; disabled; vendor preset: disabled)
       Active: inactive (dead)
    

    How are existing users impacted? What migration steps/scripts do we need?

    No impact, just a new artifact will be available (RPM)

    Checklist:

    I have:

    • [ ] updated the documentation and/or roadmap (if required)
    • [x] read the CONTRIBUTION guide
    • [x] signed-off my commits with git commit -s
    • [ ] added unit tests
    new-contributor 
    opened by e-minguez 9
  • Bump remotedialer dependency

    Bump remotedialer dependency

    Signed-off-by: Alex Ellis (OpenFaaS Ltd) [email protected]

    Description

    Bump remotedialer dependency

    How Has This Been Tested?

    Tested with a local tunnel and a simple HTTP server

    How are existing users impacted? What migration steps/scripts do we need?

    Further testing would be beneficial and a review from @ibuildthecloud before merging.

    Checklist:

    I have:

    • [x] updated the documentation and/or roadmap (if required)
    • [x] read the CONTRIBUTION guide
    • [x] signed-off my commits with git commit -s
    • [ ] added unit tests
    opened by alexellis 8
  • fix relative link in documentation

    fix relative link in documentation

    Simply fixes the link to the correct documentation

    new-contributor no-dco 
    opened by PhilETaylor 8
  • Add ability for clients to forward local connections

    Add ability for clients to forward local connections

    Description

    How Has This Been Tested?

    How are existing users impacted? What migration steps/scripts do we need?

    Checklist:

    I have:

    • [ ] updated the documentation and/or roadmap (if required)
    • [ ] read the CONTRIBUTION guide
    • [ ] signed-off my commits with git commit -s
    • [ ] added unit tests
    opened by ibuildthecloud 8
  • WIP: Switch to using github.com/rancher/remotedialer for the transport

    WIP: Switch to using github.com/rancher/remotedialer for the transport

    Fundamentally Inlets must perform tunneling and reverse proxying. Prior to this commit both functions in Inlets are custom implementations tied quite heavily to HTTP 1.1 request/response with no bi-directional communication.

    This patch replaces both tunneling and proxying with external libraries. The transport layer is switched to using github.com/rancher/remotedialer. Remote dialer allows tunneling connections at a net.Conn level so higher level protocols such as HTTP, HTTP2, WebSockets, gRPC, etc need not require specific tunneling logic only proxy logic.

    For proxying logic we use Kubernetes UpgradeAwareHandler which builds on top of go's built in httputil.ReverseProxy but adds support for "Connection: Upgrade" requests and HTTP response HTML rewriting. Once Inlets switches to go 1.12 it might be possible to drop the Kubernetes library and instead use the bare httputil.ReverseProxy as go 1.12 adds support for proxying WebSockets.

    new-contributor 
    opened by ibuildthecloud 7
Releases(4.0.1)
Owner
inlets
The Cloud Native Tunnel
inlets
Cloud Native Tunnel

inlets is a Cloud Native Tunnel written in Go Expose your local endpoints to the Internet or within a remote network, without touching firewalls. Foll

inlets 8.4k Jul 16, 2021
tunnels to localhost and other ssh plumbing

remotemoe is a software daemon for exposing ad-hoc services to the internet without having to deal with the regular network stuff such as configuring VPNs, changing firewalls, or adding port forwards.

Kristian Mide 74 Jul 11, 2021
Iris Go binding

Iris Go binding This is the official Go language binding for the Iris cloud messaging framework. Version v1 of the binding is compatible with Iris v0.

Project Iris 135 May 4, 2021
Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH.

Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH. Single executable including both client and server. Written in Go (golang). Chisel is mainly useful for passing through firewalls, though it can also be used to provide a secure endpoint into your network.

Jaime Pillora 6.1k Jul 23, 2021
The fastest way to create self-hosted exit-servers

inletsctl - the fastest way to create self-hosted exit-servers inletsctl automates the task of creating an exit-server (tunnel server) on public cloud

inlets 349 Jul 21, 2021
Clash - A rule-based tunnel in Go.

Clash A rule-based tunnel in Go. Features Local HTTP/HTTPS/SOCKS server with authentication support VMess, Shadowsocks, Trojan, Snell protocol support

Dreamacro 17.8k Jul 18, 2021
Standalone client for proxies of Opera VPN

opera-proxy Standalone Opera VPN client. Younger brother of hola-proxy. Just run it and it'll start a plain HTTP proxy server forwarding traffic throu

null 199 Jul 18, 2021
HTTP(S)/WS(S)/TCP Tunnels to localhost using only SSH.

An open source serveo/ngrok alternative.

Antonio Mika 1.9k Jul 23, 2021
Toy gRPC Tunnel over CloudFlare (Proof of Concept)

gun You know what it means. Guide Server Go to your domain in CloudFlare. In "Network" tab, turn on gRPC.

Qv2ray Workgroup 121 Jul 19, 2021
A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.

frp README | 中文文档 What is frp? frp is a fast reverse proxy to help you expose a local server behind a NAT or firewall to the Internet. As of now, it s

null 47k Jul 22, 2021
Simple HTTP tunnel using SSH remote port forwarding

Simple HTTP tunnel using SSH remote port forwarding

Skye L. 16 May 8, 2021
Decentralized VPN

Decentralized VPN The RadVPN doesn't need any central point as it connects to other nodes directly (full mesh) it has built-in router that helps packe

Mehrdad Arshad Rad 1k Jul 18, 2021
A deployable proxy server and tunnel written in go

Tunnelify Tunnelify is a deployable proxy server and tunnel written in go Installing | Quickstart | Configuration Installing Direct download You can i

Kofo Okesola 25 Jun 20, 2021