eyedeekay / sam-forwarder

i2ptunnel for Go applications, using SAM instead of I2CP.

sam-forwarder

Forward a local port to i2p over the SAM API, or proxy a destination to a port on the local host. This is no longer substantially a work-in-progress, it's a very useful way of configuring applications in an i2ptunnel-like way. TCP and UDP are supported, but there may be some lingering bugs in UDP, please report them if found.

STATUS: This project is maintained. I will respond to issues, pull requests, and feature requests within a few days. I am not adding many new features to it at this time.

getting

    go get -u github.com/eyedeekay/sam-forwarder/samcatd
    # for now

building

Just:

    make deps build

and it will be in the folder ./bin/

Usage:

There are a number of ways to use sam-forwarder:

usage/configuration as an application(Start here for samcatd)

embedding in other applications

encapsulate configuration for i2p-enabled packages

implement the interface for fine-grained control over SAM connections

binaries

The standalone application for configuring tunnels is named samcatd and it's main package is in the directory ./samcatd. It works as a cli and is capable of running a WebUI, which is currently view-only. In a future time, the WebUI will also be capable of configuring and editing tunnels.

The previous application ephsite has been fully retired. If you were using it, it can usually be replaced with samcatd -s and your existing arguments.

Current limitations:

I need samcatd to accept a configuration folder identical to /etc/i2pd/tunnels.conf.d, since part of the point of this is to be compatible with i2pd's tunnels configuration. Once this is done, I'll resume turning it into a .deb package.

It doesn't encrypt the .i2pkeys file by default, so if someone can steal them, then they can use them to construct tunnels to impersonate you. Experimental support for encrypted saves has been added. The idea is that only the person with the key will be able to decrypt and start the tunnels. It is up to the user to determine how to go about managing these keys. Right now this system is pretty bad. I'll be addressing that soon too.

Experimental support for KCP-based error correction and streaming-over-datagrams is in the works. Some kind of reverse-proxy or filter is also an obvious choice.

I've only enabled the use of a subset of the i2cp and tunnel configuration options, the ones I use the most and for no other real reason assume other people use the most. They're pretty easy to add, it's just boring. If you want an i2cp or tunnel option that isn't available, bring it to my attention please. I'm pretty responsive when people actually contact me, it'll probably be added within 24 hours. I intend to have configuration options for all relevant i2cp and tunnel options, which I'm keeping track of here.

I need to just change how the configuration is done entirely. I want it to work with the configuration formats used by each I2P router.

TLS configuration is experimental. I have decided to implement optional, automatically-configured self-signed TLS certificates. No CA support is planned as an alternative CA would have to be used and no apparent option exists which would be usable. If you're working on anything like that, I would like very to know.

Stuff that's using it:

Mostly mine, but this is all Free-as-in-Freedom for anyone to use:

• eephttpd
• my fork of wikigopher
• orangeforum

Donate

Monero Wallet Address

XMR:43V6cTZrUfAb9JD6Dmn3vjdT9XxLbiE27D1kaoehb359ACaHs8191mR4RsJH7hGjRTiAoSwFQAVdsCBToXXPAqTMDdP2bZB

Bitcoin Wallet Address

BTC:159M8MEUwhTzE9RXmcZxtigKaEjgfwRbHt

Index

• readme
• usage
• configuration
• embedding
• interface

sam-forwarder's Issues

Real Filtering

Hey

Hey its me. Your Telegram was down got something to show ya. How can I connect 👍

TLS support(At least for TCP Tunnels)

Migrate default configs from INI to JSON

Preserve compatibility with INI config by translating from INI config files to JSON config files on the fly, but some way or another get rid of the goddawful INI business I did on top of /config and replace it with something Go-native and sane(JSON). Config files will work basically the same, with defaults at the top level and tunnel-specific settings specified underneath.

Make better use of samtunnel.SAMTunnel interface and sub-projects

There are 5 tunnel types in sam-forwarder(/tcp has three, client, server, and httpserver and /udp has two, client and server) but about 11 sub-projects based on sam-forwarder that fulfill the samtunnel.SAMTunnel interface. Of those, only two are integrated into sam-forwarder at this time(httpproxy and browserproxy). I gotta get those numbers up. Those are rookie numbers. The only reason I can think of that I would exclude one from the main sam-forwarder project is that it has to be run as root, for now that's only go-anonvpn, and when I figure out how to do the capabilities it can go in.

That UI tho

I need to finally get around to replacing the crude, hardwired webUI with an RPC interface, but that's really about the least of it. Right now there's no way to add a new tunnel to the webUI without restarting entirely or starting a new instance on a different port. The RPC interface should accept a method which allows the user to input a config file to set up a tunnel. It should be capable of deleting a tunnel. It should be capable of stopping, starting, and restarting a tunnel(By name) and it should be able to adjust tunnel settings that do not require a restart without restarting(This may require additional features in the upstream libraries, goSam and sam3).

cc @postables, this RPC interface will automatically be compatible with libanonvpn and can be the basis for other components.