Idea: better reachability of clients behind a lokinet router

[jagerman]

Using lokinet on a router is a very convenient way to run it--I do it on my network so that all my devices have lokinet accessibility without needing to run lokinet.

One deficiency of this design, however, is that it is still NATing a lokinet connection: all devices behind my lokinet-enabled router can reach lokinet, but are not independently reachable and getting around this requires some sort of NAT holepunching mess, which we don't have to require for lokinet.

The idea is that such a routing lokinet would have the ability to manage multiple lokinet addresses at once, publishing introsets for each of them. Each published introset would map to one internal address (e.g. xyz123blahblah.loki <-> 10.0.0.123), so when data arrives to the lokinet client, it can send it to the proper internal address.

This might get messy in terms of the number of introsets being juggled, so an alternative to consider would be that we have some sort of "tag" on the data -- still use one address, but each local client gets assigned a different tag in the messages, remote clients learn about this tag, and can direct messages to a specific client by directing them at the router's lokinet address + appropriate tag. We would probably want to build this into the DNS, so that tagged data comes from/goes to some subdomain e.g. tag-147175123.someaddr.loki. The disadvantage of this is that you can easily see devices behind the same router, while using independent introsets would not let you see this.

[majestrate]

I dont think this is explicitly a protocol break. I think we can retain backwards compat from the existing behavior and enable the new behavior as needed and use the [network]:owned-ranges option to indicate this is being used, then we could tag by source ip, possibly with C0A80005.localnet.ourlokinetaddress.loki for lan address 192.168.0.5 (C0A80005 is the hex representation of that ip) given that 192.168.0.0/24 is given in owned ranges.

[majestrate]

possibly use an additional subdomain like C0A80005.localnet.putouraddressshere.loki to mitigate any potential conflicts with the existing synthesis of the wildcard record.

[majestrate]

there is an added side effect here that we can put these subdomains into srv records and do a bunch of cool things like have 1 .loki address as a kind of gateway with all your stuff on the lan, e.g:

# bunch of internal services
SRV _http._tcp.myservice.loki. points to C0A80005.localnet.myservice.loki
SRV _xmpp._tcp.myservice.loki. points to C0A80006.localnet.myservice.loki
SRV _yolo._tcp.myservice.loki. points to C0A80007.localnet.myservice.loki

# permit ip exit traffic to the internet via 192.168.0.1 from our .loki address
SRV _exit._ip.myservice.loki. points to C0A80001.localnet.myservice.loki

see #1841 about the last record. just a tangent.

[necro-nemesis]

Use of VLANs may be of benefit for this application.

[majestrate]

Use of VLANs may be of benefit for this application.

maybe, however that'd require lokinet run in l2 mode which we can and should eventually add support for.

[necro-nemesis]

https://openwrt.org/docs/guide-user/network/vlan/switch_configuration I am led to believe VLANs are Layer 2.

[majestrate]

yes

https://openwrt.org/docs/guide-user/network/vlan/switch_configuration I am led to believe VLANs are Layer 2.

they are indeed and lokinet needs to run in l2 mode (tap not tun) to utilize them.

[majestrate]

created #1884 for VLAN and other l2 related issues.