0. BRIEF DISCLAIMER this software comes with no warranties from the author, neither explicit nor implied. use it at your own risk. i am sorry IE doesn't handle correctly transparency in PNG images, but anyway this software is not ported to Windows yet and hence you might not be interested in reading further, i am afraid. 1. TARGET PLATFORMS and LATEST VERSION most unices. porting to other platforms is welcome. for the laest version, please see project page by clicking on the above logo. for any question, please feel free to contact me by mail. irouted is built mostly upon libnet.2. BRIEF INTRO irouted is a simple demo program that allows to extend your sight further far from where you should be allowed to, by crossing misconfigured multi-homed hosts whose kernel follows a weak end-system model kernel, such as GNU/Linux. see RFC 1122 for more about this. in fact it's not so easy to find a misconfigured multi-homed host, since the first thing anybody would do when he installs a linuxbox is to disable ping replies... you don't even need to use ipchains or netfilter to do so, you just have to have a quick look to the /proc filesystem. Furthermore the most interesting multihomed host to be crossed is a firewall... but a firewall is hardly ever configured to do something that is not explicitly allowed. So it would seem that there is no hope at all... Then, when would irouted come in any help? Are we really sure it's so hard to find a dumb stupid multihomed host? Just think about a professional switch. What if the network administrator prefers to log in remotely instead via RS232? s/he will assign the switch an ip. Then, what if s/he doesn't want to waste many of those big and expensive switches? s/he will setup some vlans. What happens then? that we have found a very stupid host which is multihomed and which in most cases cannot be configure not to reply to echo requests. And if the only route between two vlans was through the firewall? we have just overcome it without crossing it ;) or, we are crossing vlans but at a higher layer: frames don't go trough, but packets are generated by the switch and these new packets have a frame of their own and a payload that we are able to choose... 3. KNOWN BUGS any upper layer protocol can work trasparently into the i-topology. i've tested it with UDP datagrams, TCP streams such as telnet and POP3, SMTP, HTTP... and i am confident many other things should work really fine. but there is a little exception... tunneled pings towards linux boxes won't work. The kernel does not answer to the host that requested the echo but it does answer to itself since it sees the ping comes from its loopback interface. what happens is that in the reply the src and dst ip are both equal to the host address that was pinged. Possible workaround: if it is really important for you to receive ping replies from the i-topology, compile the support for dummy interfaces into the kernel, then use a dummy interface in lieu of the loopback one. i suggest you to set your loopback/dummy interface to have an MTU which is not greater than your network interface's own MTU ;) 4. COMPILATION make all && if [ "0" != "echo $?" ]; echo Huston, we had a problem... If you want to build and link this software statically, you must know that some libraries it relies on are not reentrant when linked together with your executable. you migth as well try to link statically only some of them or, which is better, to ship the needed dependencies and shared objects together with the executables, then run ldconfig. note for Solaris users that have a V9 processor: $(FLAGS) is there for you: just specify -m64 -mcpu=v9 and the correct path to shared libc libraries that work at 64 bit (accordingly to the new ABI-64 there could not be statically linked code that uses trap 0x40 handler). Sorry Sun Forte CC is not supported... please use gcc or vi Makefile. 5. INSTALLATION if i'd enter some new lines to the Makefile i'd enter these: install: for i in *; do [ -x $i ] && strip $i && cp $i /usr/sbin/; done but then stop... user should still setup his/her init scripts manually as s/he prefers... i thought it would be better to let the user completely decide what to do. Init scripts in fact, should also configure your meta-network topology, by setting up i-routing tables each time your box is powered on. To set up a i-routing entry means also to add an entry in the usual kernel routing table and setting that entry to be handled by the loopback (or dummy... see point 2) interface irouted is working on. 6. LET'S TIDY UP make clean this does not delete iroute... it only "chmods" -x it ;) do never remove iroute even when it has no execution rights: it's a source file! 7. USAGE highligths: * modify your init scripts on both the i-hosts so that they load irouted daemon at startup * modify your init scripts so that they call iroute to specify which hosts/networks to reach through the i-topology specifically: * to learn how to use the command iroute just type "iroute" without any argument at all * both iroute and i__route should be in your path for everything to go in the right way (see section 5 above)... * it is better not to call i__route directly, even though it is not dangerous... i__route contacts directly the daemon irouted. irouted does say it accepts or drops change requests without explaining why it is dropping them. the i__route wrapper script iroute does check parameters before calling iroute and tries to detect syntax errors and explain them 8. A PRACTICAL SAMPLE AAAAA BBBBB CCCCC | .113 .114 | | .117 .118 | +--------------------+ +--------------------+ 192.168.0.112/30 192.168.0.116/30 BBBBB: * you don't need to have access to host BBBBB ;) AAAAA: * make and install everything * setup your init scripts to load irouted * setup your init script to run this command (after irouted is fully started... give it a few - let say 2 or 3 - seconds with a sleep): iroute add 192.168.0.116 255.255.255.252 reflector 192.168.0.114 eth0 peer 192.168.0.118 CCCCC: * make and install everything * setup your init scripts to load irouted * setup your init script to run this command (after irouted is fully started... give it a few - let say 2 or 3 - seconds with a sleep): iroute add 192.168.0.112 255.255.255.252 reflector 192.168.0.117 eth0 peer 192.168.0.113 if the netmask were shorter than 30 bits and there were some more hosts you would not need to run irouted also on the other hosts. all you would need to is to setup the nearest peer as a gateway for that network. the other peer will contact your target on its lan for you, automagically. For the same magic that makes any program that you were used to have before work on the i-topology too ;) 9. TODO i still have some ideas about changes i should apply... i want to: * do so that iroute without arguments will display the i-routing table quite easy indeed... just very few changes over rt_dump(), i__route.c and listen_route.c * decide amongst different strategies 1) use the link layer injection type in order to allow the use r choose which interface to inject the packets with... is it really useful? this would be quite easy and quick to do with the data structures and the interface iroute has got at the moment but the resulting program would be slower, since we would need to libnet_destroy() each context we create for each packet we must inject... this in order to initialize a new context with a possibly different interface. furthermore in this way we would not be able to recycle pblocks... even slower... that's quite good, i've already tested it and it's fine indeed. but why should we be satisfied when we could be faster? faster means not only that i-networking would be faster but also that the irouted daemon would be even less cpu-intensive 2) delete the field about the interface to be used in the irouting table entry: if we don't use the link_layer interface the interface name is a don't care and may be set to NULL... (as it is now... but i'm keeping route->interface in order to be able to libnet_init(LIBNET_LINK, route->interface, errbuf)). * explore the possibilities offered by dummy interfaces in linux * if i'll keep on using the loopback and not dummy interfaces i'd think about sending an ICMP unreachable message to the kernel, saying "fragmentation needed and DF set"... it may really work and this way users won't be any more obliged to reduce their loopback MTU size ;) * add some step by step documentation that helps the user set up everything at least under GNU/Slackware Linux, GNU/Debian Linux and GNU/RedHat Linux then irouted 0.0.2 would be released and maybe this project should be frozen ;) cheers sandr8) -= [ EOF ] =-
