But all SNMP Request will get the same Answer, right?
So you can do the following:
iptables -t nat -A PREROUTE -d 192.168.0.0/24 -p udp --dport 162 -j
DNAT --to-destination 127.0.0.1:162
Configure SNMP to listen on 127.0.0.1:162, all requests on
192.168.0.0-255 will mapped to 127.0.0.1:162
You need only one IP-Address on your Network and aggregate all to your
loopback-device.
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 15:40, schrieb Jan Wedel:
> Michael,
>
> To address your question: We plan to enable a customer access devices,
> e.g. via SNMP, that are not existing or at least that are not accessible
> by IP/SNMP etc. To create this "illusion", we need a server (which will
> be Linux, not Windows) that is able to process requests to many virtual
> IP addresses. On the upper layers, a server socket, e.g. a customized
> SNMP server waits for incoming requests on any of these IP addresses
> (which works). The server responds and the inquirer thinks that he just
> got an answer by a real SNMP network device.
>
> I hope this makes it a bit clearer for you and if you have some further
> suggestion, feel free to tell me!
>
> However, you already helped me a lot!
>
> Thank you!
>
> Jan
>
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Michael Rack [mailto:michael.r...@rsm-freilassing.de]
>> Gesendet: Freitag, 18. Dezember 2009 15:21
>> An: Jan Wedel
>> Cc: vtun-users@lists.sourceforge.net
>> Betreff: Re: [Vtun-Users] TCP sockets on multiple virtual ip addresses
>>
>> 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
