tinc 0.3.3 vs. 1.0pre2

[Guus Sliepen]

On Sat, 24 Jun 2000, [ISO-8859-1] Axel Müller wrote:

> When I first looked at tinc I very much liked the clear way it is 
> operating: The VPN client encrypts packets for VPN destinations (our 
> Intranet) and puts them into other packets which will be routed to the VPN 
> destination (our VPN server). There the packet gets decrypted and the 
> orignal packet pops out, gets a new sender label (MAC of VPN server) and 
> gets routed to the destination host which not necessarily runs tinc. You 
> know tinc much better than I do but I think tinc handles all this in a nice 
> way (You won't disagree to that ;-)).

I won't. Thank you :)

> The only thing I missed in tinc was a "Proxy feature" which I added by
> this simple patch. My point is that I would rather consider a proxy
> setting in the tinc.conf file than extending the meta protocol. (KISS
> = Keep It Safe & Simple)

Uhm, to implement a NICE proxy feature (and not a quick hack) the meta
protocol really has to be altered a bit (because not only shouldn't it
send data to non-uplink hosts, but it also shouldn't receive from
non-uplink hosts. And if you do the former for every host, then you don't
have the latter problem, but others might have different setups).

I just partly implemented what Ivo has called the "indirectdata" option.
Get it from the CVS tree. I have not been able to test it, but you might
:). For the moment, you still need to add it to every tinc daemon's
configuration (except to the "main" tincd).

-------------------------------------------
Met vriendelijke groet / with kind regards,
  Guus Sliepen <guus at sliepen.warande.net>
-------------------------------------------
See also: http://tinc.nl.linux.org/
          http://www.kernelbench.org/
-------------------------------------------

---
TINC development list, tinc-devel at nl.linux.org
Archive: http://mail.nl.linux.org/tinc-devel/