Opened 7 years ago

Closed 6 years ago

#851 closed enhancement (fixed)

IP to I2P address mappings in SOCKS client tunnels

Reported by: str4d Owned by: str4d
Priority: minor Milestone: 0.9.5
Component: apps/i2ptunnel Version: 0.9.4
Keywords: Cc:
Parent Tickets: Sensitive: no

Description

Backstory: I want to run ZNC (an IRC bouncer) through SOCKS so that any IRC connections are made through I2P (and Tor), but ZNC does not natively support proxying. I can use proxychains to proxy any connections through an I2P SOCKS client tunnel, but ZNC will only connect to IP addresses - if a hostname is provided, it looks it up in DNS first, meaning that I2P addresses fail. My current ZNC setup uses individual I2P tunnels per I2P IRC server; ZNC cannot connect to these while being proxychained.

The attached patch adds support to SOCKS5 tunnels for mapping arbitrary IP addresses to .i2p URLs, similar to Tor's MapAddress? config variable. The mappings are user-defined and per-tunnel, stored in the tunnel's custom options e.g.

ipmapping.127.12.34.56=irc.postman.i2p

Does this patch make sense to apply? Is it useful? Does it create security/anonymity issues (I can't think of any, especially as it is user-configured)? Should it also be applied to SOCKS4 tunnels?

Subtickets

Attachments (1)

ipmapping.diff (2.4 KB) - added by str4d 7 years ago.

Download all attachments as: .zip

Change History (5)

Changed 7 years ago by str4d

Attachment: ipmapping.diff added

comment:1 Changed 7 years ago by zzz

As discussed on IRC, it's hackish but similar to other i2ptunnel configs for proxies, ports, etc.

You're constrained by well-known limitations of i2ptunnel for configuring complex mappings.

A general-purpose solution, e.g. full garlicat-type mapping and support of the entire addressbook, is well beyond the scope of what you're trying to do.

You could add it to 4a too, if you feel like it. You'd have to pass the props thru the constructor as in 5.

ACK

comment:2 Changed 7 years ago by str4d

Yeah… I couldn't think of a nicer way to do it within i2ptunnel, and this is a simple change which doesn't affect any existing usage (and it can always just sit there unused by the masses, like most of the advanced I2P configuration options _). I will add it to 4a as well, for consistency - since the mapping option is a property of the configured SOCKS tunnel, the user would expect that a configured mapping would work regardless of whether the connected client was using SOCKS4a or SOCKS5.

If a full garlicat-type mapping was set up, I would be inclined to turn it into a local I2P DNS server, so the clients don't have to deal with the mapping at all: they can just request an I2P hostname and the I2P DNS server could dynamically set up a mapping to return to the client. Of course, this leads to conflict issue on UDP port 53 with other local DNS server for the clearnet, but that could probably be resolved by having the I2P DNS server listen on e.g. port 5353 and then use iptables etc. to redirect the DNS requests of a specific user or group to the I2P DNS server.

comment:3 Changed 6 years ago by str4d

Owner: set to str4d
Status: newaccepted

comment:4 Changed 6 years ago by str4d

Resolution: fixed
Status: acceptedclosed

This was pushed to trunk in changeset:cb841efa9bb41894140e0a1f4664a239472de101 and is working.

Note: See TracTickets for help on using tickets.