Hi Michael! Thank you for your detailed reply!
You are absolutely right, the VPN server needs to get an IP. 1.) But is it possible to address a wider range of IP addresses (192.168.0.1-192.168.254.254) as well? In this case, we could use e.g. 192.168.0.* fort he servers (including VPN), 192.168.1.* for VPN clients and 192.168.2.* to 192.168.254.* for devices. This should be possible by using the subnetmask 255.255.0.0, shouldn't it? I guess, this rather leads into a more general network discussion than a pure VTUN discussion, but maybe you'd be so kind to answer it anyhow :). 4.) If it's not possible to use wildcards, does it mean it is not possible because linux/unix doesn't support this or is it a VTUN specific problem. In other words, do you know any other way to attach a lot of IP addresses to a device other than adding each one separately? 5.) Do you really think, this requires a lot of resources? I am not the network driver expert but I'd assume as long as it is one network device, it doesn't really matter how many IP addresses are attached. In my understanding, it "only" means that the device has a table with all its addresses. As soon as a router asks (ARP) "who has this IP?" the device would answer with its MAC address. And thats it. All packets gets routed to this device. So it's only limited by a) the network bandwidth and b) the computing power that is required to process all incoming data. Is that correct? Thanks! (Grüße aus Berlin :) ) > -----Ursprüngliche Nachricht----- > Von: Michael Rack [mailto:michael.r...@rsm-freilassing.de] > Gesendet: Freitag, 18. Dezember 2009 07:24 > An: Jan Wedel > Betreff: Re: [Vtun-Users] TCP sockets on multiple virtual ip addresses > > Hi Jan, > > TUN is only a LAYER2-Bridge and TAP LAYER1. > > You can not assign 192.168.0.1-255 to your VPN-Users. Your VPN-Server > needs one ip-address of this space. > > Server: 192.168.0.1, Clients-Range: 192.168.0.10 to 192.168.0.254. > > The last IP-Address of 192.168.0.0/24 is 192.168.0.254! > > TAP-Devices are real devices with a MAC-Address. That is not virtual. > You don't have to do anything, it works out of the box. > > Remember, VTUN is for UNIX only. > > Is IP_FORWARD enabled? Check this by > > cat /proc/sys/net/ipv4/ip_forward > > this option have to be enabled by (1). If (0) is returned, IP- > Forwarding > is disabled. Enable IP-Forwarding by > > echo 1 > /proc/sys/net/ipv4/ip_forward > > 1. Yes you can do this, because VTUND don't handle this things. The > Kernel is doing this job (TCP/IP-Stack). > > You have only to add new virtual ip-addresses > > ip addr add dev tap0 192.168.0.1/24 brd + > ip addr add dev tap0 192.168.0.2/24 brd + > ip addr add dev tap0 192.168.0.3/24 brd + > > 2. A example for VTUN? > > up > { > program "/sbin/ ip link set dev %% up" > program "/sbin/ ip addr add dev %% 192.168.0.1/24 brd +" > program "/sbin/ ip addr add dev %% 192.168.0.2/24 brd +" > program "/sbin/ ip addr add dev %% 192.168.0.3/24 brd +" > }; > > This configuration makes only sense for a client! > If you need more IP-Addresses on your Server, create a dummy-interface > switch them up and assign ip-addresses to this interface. > > 3. For VTUN you need a configuration-file. You can dynamicly change the > interface configuration by adding and removing ip-addresses. > > 4. no that is not able. > > 5. if you have enough memory on your system. Kernel can handle > thousends > of ip-addresses, it is only limitated by your machine. > > Liebe Grüße aus Freilassing, > > Michael Rack > RSM Freilassing > -- > RSM Freilassing Tel.: +49 8654 607110 > Nocksteinstr. 13 Fax.: +49 8654 670438 > D-83395 Freilassing www.rsm-freilassing.de > > Am 16.12.2009 17:53, schrieb Jan Wedel: > > Hi! > > > > I was searching for a while for a solution to my problem and tun/tap > > might be this solution. I have to admit that I haven't worked with it > yet. > > > > Here is what I am looking for: > > > > We have an OpenVPN network (which already uses a TAP driver). Within > > this network, we have several clients, lets say addresses from > > 192.168.0.1 to 192.168.0.255. These clients try to access ip > addresses > > e.g. 192.168.1.1 to 192.168.1.255. > > > > The problem is, that the latter addresses are purely virtual. We want > to > > create the "illusion" that there are real devices that for example > > answer to SNMP requests. Physically, there is only one server in this > > network segment. > > > > I think, the TUN/TAP driver can be configured to accept all requests > on > > specified ip addresses and deliver them unchanged (no forwarding by > > replacing the IP address etc.) to the operating system. > > > > On this system, e.g. a Java ServerSocket waits on a port on an > anycast > > address to accept all local ip addresses. I've tested it by simply > > adding ip addresses to an existing physical NIC. > > > > Now, the question is, > > > > 1.) is it possible to configure the tun/tap driver to do this, i.e. > > representing multiple IP addresses that can be used in the > application > > layer? > > > > 2.) If yes, could you give an example how to do this (if its very > easy) > > or point me to the part of the documentation? > > > > 3.) Would you recommend a configuration file or can this be changed > > dynamically? > > > > Moreover, > > > > 4.) is it possible to set wildcards for IP segments like 192.168.1.* > > instead of adding ip addresses one by one? This is important and > leads > > to the next question: > > > > 5.) Is it possible to have something like e.g. 10,000 IP addresses > > connected to a single TUN/TAP driver? Will this require a lot of > > performance or is simply an entry in a table and respectively a > lookup > > in this table for every incoming packet? > > > > Thank you very much! Any comments are appreciated! > > > > Jan > > > > > > > > --------------------------------------------------------------------- > --------- > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast > and easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > > > > > > > _______________________________________________ > > Vtun-Users mailing list > > Vtun-Users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/vtun-users ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Vtun-Users mailing list Vtun-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vtun-users
