2012-10-11 18:23, Gabriele Bulfon пишет:
Thanx, I could make a test.
Configured the zone with:
>add device
>set match=/dev/tun
>end
booted the zone, and I could see the tun device in /dev.
Configured openvpn, and I got this:
Thu Oct 11 15:43:51 2012 TUN/TAP device tun0 opened
Thu Oct 11 15:43:51 2012 /usr/sbin/ifconfig tun0 10.1.1.1 10.1.1.2 mtu
1500 up
Thu Oct 11 15:43:51 2012 /usr/sbin/ifconfig tun0 netmask 255.255.255.255
Thu Oct 11 15:43:51 2012 /usr/sbin/route add 10.1.1.0 -netmask
255.255.255.0 10.1.1.2
add net 10.1.1.0: gateway 10.1.1.2
Thu Oct 11 15:43:51 2012 Data Channel MTU parms [ L:1544 D:1450 EF:44
EB:135 ET:0 EL:0 AF:3/1 ]
Looks nice!
Then ifconfig was showing the tun0:
tun0:
flags=10010008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,IPv4,FIXEDMTU>
mtu 1500 index 3
inet 10.1.1.1 --> 10.1.1.2 netmask ffff
Yep, that seems normal. When your clients connect (or perhaps you
connect to a remote server - I didn't try that yet from a Solaris)
your tunnel will implicitly address new quads of addresses in /30
subnets (net, server, client, bcast) but these won't show up in
ifconfig outputs. You can however sniff on these tunnel interfaces
with snoop or tcpdump, you can firewall/NAT them with ipfilter, etc..
Well, my next question is: how can I have different zones run openvpn on
tun?
Will it let me add the device to more than one zone?
Possibly, perhaps you can "match" and delegate tun's with different
numbers? Or have a private tun0 in each zone? Sorry I can't really
elaborate, I didn't try that. Not yet... ;)
If not, is there any chance to "make install" the tun driver with
different names and instances, so
I can bind each instance/name to different zones?
Maybe, at least if you install from source and hardcode different
names into each copy of the driver.
PS: any chance to write or port the tun driver into the blowfish realm?
The tunnel driver does no encryption, so this question (if I got
it right) really applies to OpenSSL and OpenVPN config.
The OpenVPN program opens a link between server and client, that
is typically on port 1194 (tcp or udp). Comms on that link are
encrypted with use of openssl libraries, and the encrypted
packets (should) contain encapsulation of userdata packets into
tunnel-packet containers. If I am not mixing things up, the
diagram should look like this:
openvpn - tun - openssl - NIC -- INET -- NIC - openssl - tun - openvpn
For the lack of better short name, the NIC above is the place
where IP packets (with encrypted tunneled packets) depart/arrive
on the physical IP network.
From what I gather, this is also very different from IPSec tunnels
(such as those configurable by dladm) and it is unlikely that these
two concepts would converge into one, or even that tun/tap links
could become really manageable via dladm - it is not the OS that
really "intellectually" drives them, but a userland program such
as OpenVPN. To such a program the tunnel is roughly a pipe file
descriptor where it reads/writes stuff.
HTH,
//Jim Klimov
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
