Hi Ivo, --On Freitag, 23. Juni 2000 01:15 +0200 Ivo Timmermans <zarq@icicle.yi.org> wrote:> I'm not sure I fully understand your patch.This is not so important since I'm trying to get 1.0pre2 running. Although I had no luck so far, I'll point out what's going wrong at the end of this mail.> For instance, you force a > key exchange when the connection is made, but not when a key is > regenerated. Is this intentional?I did not look much into key regeneration of tinc. The reason to force this immediate key exchange was to save time. If I think it over again now, it doesn't really save time ;-(> The parameter `proxymode' was removed in pre2, because it wouldn't > work. It was there for all wrong reasons anyway, and implemented in > the wrong way. I will re-introduce it under another name, so that the > intention is clear (NoDirectData for instance).In the scenario in which we use tinc this feature is crucial. That's why I modified tinc 0.3.3 which we are still running. As soon as you have VPN (tinc outgoing) clients accessing whole networks through a VPN (tinc incoming) server you have to tell the VPN client to send everything to the VPN server (proxy) reagardless if this is a know VPN destination.> And defining the syslog levels would sure make sense, I think I will > copy your practise here. >From practical experience I would appreciate that. Currently there is nomeaning behind log levels. Having a meaning one can easily set the proper log level. I would also add some more log messages, i.e. which configuration file tinc read after startup etc.. I already added some of them in the version I'm using.> The metaprotocol definition was removed because it was just after a > rewrite of the protocol, so the specification was obsolete, and it > needs a rewrite.Since I'm stuck with a meta protocol error right now it would help a lot to have the spec.> As for contributing to tinc, any help is appreciated.I thought that way ;-) (although I have to admit that I'm not a C expert ...)> Are you > subscribed to the mailing list(s)? (tinc@nl.linux.org and > tinc-devel@nl.linux.org, send an email to majordomo@nl.linux.org.)I did it today.> We > have some ideas for the future, and I'm now putting up a bug tracking > system for tinc.In our company we set up Bugzilla for that. *** Problems with tinc 1.0pre2 *** Since there is nothing like the ProxyMode you tried to introduce I have to modify netutl.c like I did for tinc 0.3.3 (which is working fine that way): diff -u tinc-1.0pre2/src/netutl.c tinc-1.0pre2-i2c/src/netutl.c --- tinc-1.0pre2/src/netutl.c Wed May 31 20:23:06 2000 +++ tinc-1.0pre2-i2c/src/netutl.c Fri Jun 23 14:14:42 2000 @@ -56,6 +56,9 @@ for(p = conn_list; p != NULL; p = p->next) if(((ip & p->vpn_mask) == (p->vpn_ip & p->vpn_mask)) && p->status.active) return p; + p = conn_list; + if(p->status.outgoing) + return p; cp return NULL; } This small patch causes everything to be sent to the uplink if we have an outgoing connection. Although this working fine with tinc 0.3.3 it does not work with 1.0pre1 or 1.0pre2. Below is the log of a test I did with 1.0pre2 running on both ends: Jun 23 14:20:43 tomcat tinc[15012]: tincd 1.0pre2 (Jun 23 2000 14:15:07) starting, debug level 3. Jun 23 14:20:43 tomcat tinc[15012]: Generating 128 bits keys. Jun 23 14:20:43 tomcat tinc[15012]: Ready: listening on port 655. Jun 23 14:20:43 tomcat tinc[15012]: Connected to 212.79.9.74:655 Jun 23 14:20:43 tomcat tinc[15012]: got BASIC_INFO(655,192.168.9.1,255.255.255.0) Jun 23 14:20:43 tomcat tinc[15012]: Peer uses protocol version 6 Jun 23 14:20:43 tomcat tinc[15012]: Opening UDP socket to 212.79.9.74 Jun 23 14:20:43 tomcat tinc[15012]: Send BASIC_INFO to 212.79.9.74 Jun 23 14:20:55 tomcat tinc[15012]: Sending out request for public key to 192.168.9.1 Jun 23 14:20:55 tomcat tinc[15012]: Metadata socket read error: Invalid argument Jun 23 14:20:55 tomcat tinc[15012]: Closing connection with 212.79.9.74. Jun 23 14:20:55 tomcat tinc[15012]: Send TERMREQ to 192.168.9.1 Jun 23 14:20:55 tomcat tinc[15012]: Try to re-establish outgoing connection in 5 seconds. Jun 23 14:20:56 tomcat tinc[15012]: Got SEGV signal after netutl.c line 51. Trying to re-execute. Jun 23 14:20:56 tomcat tinc[15012]: Terminating. Jun 23 14:20:56 tomcat tinc[15015]: tincd 1.0pre2 (Jun 23 2000 14:15:07) starting, debug level 3. Jun 23 14:20:56 tomcat tinc[15015]: Generating 128 bits keys. Jun 23 14:20:56 tomcat tinc[15015]: Ready: listening on port 655. Jun 23 14:20:56 tomcat tinc[15015]: Connected to 212.79.9.74:655 Jun 23 14:20:56 tomcat tinc[15015]: got BASIC_INFO(655,192.168.9.1,255.255.255.0) Jun 23 14:20:56 tomcat tinc[15015]: Peer uses protocol version 6 Jun 23 14:20:56 tomcat tinc[15015]: Opening UDP socket to 212.79.9.74 Jun 23 14:20:56 tomcat tinc[15015]: Send BASIC_INFO to 212.79.9.74 Jun 23 14:20:57 tomcat tinc[15015]: Sending out request for public key to 192.168.9.1 Jun 23 14:20:57 tomcat tinc[15015]: Metadata socket read error: Invalid argument Jun 23 14:20:57 tomcat tinc[15015]: Closing connection with 212.79.9.74. Jun 23 14:20:57 tomcat tinc[15015]: Send TERMREQ to 192.168.9.1 Jun 23 14:20:57 tomcat tinc[15015]: Try to re-establish outgoing connection in 5 seconds. Jun 23 14:21:02 tomcat tinc[15015]: Connected to 212.79.9.74:655 Jun 23 14:21:02 tomcat tinc[15015]: got BASIC_INFO(655,192.168.9.1,255.255.255.0) Jun 23 14:21:02 tomcat tinc[15015]: Peer uses protocol version 6 Jun 23 14:21:02 tomcat tinc[15015]: Opening UDP socket to 212.79.9.74 Jun 23 14:21:02 tomcat tinc[15015]: Send BASIC_INFO to 212.79.9.74 Any idea? Anything else I should test? P.S.: What are the "cp" at the beginning and end of each function about? Axel --- TINC development list, tinc-devel@nl.linux.org Archive: http://mail.nl.linux.org/tinc-devel/
On Fri, 23 Jun 2000, [ISO-8859-1] Axel Müller wrote:> I did not look much into key regeneration of tinc. The reason to force this > immediate key exchange was to save time. If I think it over again now, it > doesn't really save time ;-(In fact, you might actually send keys that are not needed, and although this is not a problem for only a few tinc daemons, when the network is larger, this is bad for scalability.> In the scenario in which we use tinc this feature is crucial. That's why I > modified tinc 0.3.3 which we are still running. As soon as you have VPN > (tinc outgoing) clients accessing whole networks through a VPN (tinc > incoming) server you have to tell the VPN client to send everything to the > VPN server (proxy) reagardless if this is a know VPN destination.Your setup only works if EVERY host uses proxymode (or whatever it'll be called). That's not scalable either. The Right Thing(tm) would be that a tinc daemon can tell it wants to use proxymode to it's uplink, and that the uplink tells all other hosts about the new host, but sends it's own real IP address instead of the one from the new host. We'll implement that ASAP. [...]> This small patch causes everything to be sent to the uplink if we have an > outgoing connection. > Although this working fine with tinc 0.3.3 it does not work with 1.0pre1 or > 1.0pre2. > Below is the log of a test I did with 1.0pre2 running on both ends:[...]> Any idea? Anything else I should test?Not yet. Thank for the logs, it will surely help.> P.S.: What are the "cp" at the beginning and end of each function about?CheckPoint. It's a macro (defined in util.h) that saves the current filename and position, which is used by the exception handler (the one that prints syslog messages whenever there's a segfault or something like that) to give an indication where the error happened. You can add more cp's if you're testing something. ------------------------------------------- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.warande.net> ------------------------------------------- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ ------------------------------------------- --- TINC development list, tinc-devel@nl.linux.org Archive: http://mail.nl.linux.org/tinc-devel/
--On Freitag, 23. Juni 2000 18:07 +0200 Guus Sliepen <guus@warande3094.warande.uu.nl> wrote:>> In the scenario in which we use tinc this feature is crucial. That's why >> I modified tinc 0.3.3 which we are still running. As soon as you have >> VPN (tinc outgoing) clients accessing whole networks through a VPN >> (tinc incoming) server you have to tell the VPN client to send >> everything to the VPN server (proxy) reagardless if this is a know VPN >> destination. > > Your setup only works if EVERY host uses proxymode (or whatever it'll be > called). That's not scalable either. The Right Thing(tm) would be that a > tinc daemon can tell it wants to use proxymode to it's uplink, and that > the uplink tells all other hosts about the new host, but sends it's own > real IP address instead of the one from the new host. We'll implement that > ASAP.If you have ONE tinc acting as VPN server and MANY acting as VPN clients to the VPN server then all off them have to use the VPN server as proxy. The VPN clients don't have to know about each other as long as the VPN server knows all current VPN clients to deliver the packets to the proper real-IPs. I don't think that each VPN client has to know about each other VPN client when using a proxy. I would therefore this not consider to be an issue of the tinc meta protocol if normal routing is sufficient. Maybe I explain a bit more about the environment we use tinc in: Usually I (tap0=192.168.9.100) want to access any host on our corporate intranet (192.168.75.0) through the firewall running tinc (tap0=192.168.9.1). None of those hosts is running tinc but it is obvious from the routing table that packets going to our intranet have to go through tap0 respective tinc. Look at the routing table I have on my Linux box at home connecting through a dial-up link to the Internet and to our corporate network: root@tomcat:/usr/src > netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.75.0 192.168.9.1 255.255.255.0 UG 0 0 0 tap0 192.168.99.0 * 255.255.255.0 U 0 0 0 vmnet1 212.122.151.0 * 255.255.255.0 U 0 0 0 ippp0 192.168.9.0 * 255.255.255.0 U 0 0 0 tap0 loopback * 255.0.0.0 U 0 0 0 lo default pg9-nt.frankfur 0.0.0.0 UG 0 0 0 ippp0 And here is the routing table on our VPN server (acting primarily as Internet gateway, firewall): lemon:~ # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 212.79.9.72 * 255.255.255.248 U 0 0 0 eth0 212.79.58.0 * 255.255.255.192 U 0 0 0 eth1 192.168.70.0 212.79.58.78 255.255.255.0 UG 0 0 0 eth0 192.168.24.0 * 255.255.255.0 U 0 0 0 eth7 192.168.75.0 * 255.255.255.0 U 0 0 0 eth3 192.168.9.0 * 255.255.255.0 U 0 0 0 tap0 192.168.60.0 * 255.255.255.0 U 0 0 0 eth2 loopback * 255.0.0.0 U 0 0 0 lo default router.i2c-syst 0.0.0.0 UG 0 0 0 eth0 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 ;-)). 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)>> P.S.: What are the "cp" at the beginning and end of each function about? > > CheckPoint. It's a macro (defined in util.h) that saves the current > [...]Thanks :-) --- TINC development list, tinc-devel@nl.linux.org Archive: http://mail.nl.linux.org/tinc-devel/