On 08/28/2016 02:00 AM, grarpamp wrote: > On 8/28/16, Mirimir <miri...@riseup.net> wrote: >> Is it possible to specify a different /48? > > On the command line or config file, currently, in r570? No. > Excluding tunnel setup it's in src/ocat_netdesc.h. > Go ahead and add the -option if you want, seems useful.
I'm no coder, so at best, I'd get something to build ;) > Make sure you check the rfc and document your prefix > generation, some of the example scripts out there are > also wrong, and I believe the current prefix is unreproducible. > There's also a voluntary registry of sorts. OK. As I understand it, all that matters is using a /48 that won't be provisioned by ISPs. In case it hits the public Internet. Right? What do you mean by "unreproducible"? >> I understand that would break >> routing from stock OnionCat. But that's actually the goal. > > I think you'd end up with a "private" network via breakage, > though it seems hardly a security feature without end > to end keying / packet filtering. See also -U and -R. Yes, I've discovered the importance of -U :) I restrict traffic by local and remote OnionCat IPv6 addresses, both in ip6tables and for ip4ip6 tunnels. But honestly, it hadn't occurred to me to use the HiddenServiceAuthorizeClient option. Thanks :) > I could see ocat expanded to recognize a list of known > prefixes where you'd handle each differently in the host > stack (via interfaces, or even subinterface / vlan presentation) > even though they're all backhauled over a -t tor. > Today that would require running multiple onioncats > with no way to multiplex the prefixes over a -s. OK, so I get that -t is the SocksPort used for outbound connections. And for inbound connections, I get that -l is the listening address and port, and that -s is the virtual hidden service port. So for now, each instance would have its own pair of -t and -l/-s. But I'm having a hard time imagining what multiplexing would look like. And anyway, isn't it better to split stuff across multiple SocksPorts? > You probably know about this thread spanning months > where people interested in onioncat... > https://lists.torproject.org/pipermail/tor-dev/2016-April/010847.html Yes :) > Do wish the mailing list and all its archives would come back. > > https://www.onioncat.org/ > https://www.cypherpunk.at/onioncat_trac/ Me too. I've very intrigued by overlay networks. And I'm impressed with OnionCat. It's simple, it's fast, and it's reliable. I've even managed a LizardFS cluster on many VPS linked via OnionCat. All it took was increasing timeouts 10x to accept 2000 ms rtt. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
