Correct, you can setup a network 192.168.0.0/16 but be aware, that all 
clients can get a big broadcast subnet :-D If you connect Microsoft 
Windows machines, Windows will send discovermessages for NETBIOS, that 
can be very heavy for your vpn-bandwidth.

Wildcards are not possible by Linux. Perhaps there is a Module that can 
handle this.
But sorry for my question: what are you plan to do with many 
ip-addresses allocated to only one machine?

You can assign ip-addresses very fast with Bash-Scripting:

     ip addr add 192.168.0.[1-200] brd + dev br0

This syntax is not available on all unix-systems.

Yes of course, it does allocate many ressources on your System. All 
configuration-information is stored on your systems memory (RAM). For 
each IP-Address your system will allocate bytes to bytes...

Checkout your Routing-Table:

     ip route show table local
     ip route show table main

You will fill up your routingtables with all routing informations. This 
information have to be saved anywhere it is accessible in microseconds.

The Linux-Kernel have to walk through the routing table, what can result 
in a long search for the right entry.

So long. Check if your intend is correct to solve with many ip-addresses :-D

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 18.12.2009 14:19, schrieb Jan Wedel:
> 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

Reply via email to