omniosorg / zadm

zone management tool
https://omnios.org/setup/zadm
GNU General Public License v3.0
24 stars 8 forks source link

possible to set linkprop's in zadm manifest? #121

Closed bahamas10 closed 2 years ago

bahamas10 commented 2 years ago

Hello, is it possible to specify linkprops (like protection) with zadm when creating an interface? Right now I can achieve what I want by running dladm commands after booting the zone, but I know these won't persist by default over a zone (or gz) reboot.

The default when I create a zone with zadm:

dave - GZ:test-gz sunos ~ $ sudo dladm show-linkprop -p protection ns10
LINK         PROPERTY        PERM VALUE          DEFAULT        POSSIBLE
ns10         protection      rw   ip-nospoof     --             mac-nospoof,
                                                                restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof

Is this something that zadm supports? or should I create the interface outside of zadm and use zadm to just give my preconfigured network interface to the zone?

citrus-it commented 2 years ago

The brand framework supports both persistent and on-demand VNICs, so if you create a VNIC without specifying the global-nic property, it will persist over a zone reboot. That's the current workaround for doing something like this, create the VNIC manually, add it to the zone without specifying global-nic, and then set the properties you want. One thing to bear in mind is that if you configure an allowed-address attribute, zoneadmd will automatically set protection to ip-nospoof and configure allowed-ips on zone boot, unless you have manually set either of those properties on the link.

Can you expand a bit on what you're trying to achieve here? We could add more properties to the network resource in the zone configuration, we just have to manage the interaction with allowed-ips.

bahamas10 commented 2 years ago

@citrus-it Thanks for the reply - that's good to know about the persistent VNICs.

My current goal is to move my dhcp zone (dhcp server for my home network) over from SmartOS to OmniOS. When I originally spun up my new DHCP server on my OmniOS test server I noticed that none of the DHCP responses were going out. The zone was getting the requests from clients, and offering IPs back, but nothing was actually leaving the zone.

At the request of @papertigers I ran the D script from this comment (https://github.com/joyent/smartos-live/issues/567#issuecomment-187462068). Running that while an incoming DHCP request was received by the zone I saw:

dave - GZ:test-gz sunos ~ $ sudo ./test.d
dtrace: script './test.d' matched 6 probes
CPU     ID                    FUNCTION:NAME
  0  41603 intercept_dhcpv4_outbound:return intercept_dhcpv4_outbound returned 0

  0  41681           ipnospoof_check:return ipnospoof_check returned 22

  0  16331 mac_protect_check_one:ip-nospoof-fail
             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef
         0: ff ff ff ff ff ff 02 08 20 c8 fa 2a 08 00        ........ ..*..

^C

I then compared the protection properties on my links (my DHCP server lives on 4 vlans so it has 4 VNICs) from SmartOS to OmniOS.

On SmartOS:

root - datadyne sunos ~ # dladm show-linkprop -z b72627b5-5eca-eb70-875d-dddeb85eaf68 -p protection
LINK         PROPERTY        PERM VALUE          DEFAULT        POSSIBLE
net0         protection      rw   mac-nospoof,   --             mac-nospoof,
                                  restricted                    restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof
net1         protection      rw   mac-nospoof,   --             mac-nospoof,
                                  restricted                    restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof
net2         protection      rw   mac-nospoof,   --             mac-nospoof,
                                  restricted                    restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof
net3         protection      rw   mac-nospoof,   --             mac-nospoof,
                                  restricted                    restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof

On OmniOS:

dave - GZ:test-gz sunos ~ $ dladm show-linkprop -p protection
LINK         PROPERTY        PERM VALUE          DEFAULT        POSSIBLE
... snipped ...
dhcp0        protection      rw   ip-nospoof     --             mac-nospoof,
                                                                restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof
dhcp1        protection      rw   ip-nospoof     --             mac-nospoof,
                                                                restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof
dhcp2        protection      rw   ip-nospoof     --             mac-nospoof,
                                                                restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof
dhcp3        protection      rw   ip-nospoof     --             mac-nospoof,
                                                                restricted,
                                                                ip-nospoof,
                                                                dhcp-nospoof

Because of the ip-nospoof-fail from the D script output, and ip-nospoof being enabled on OmniOS and not SmartOS for the zone, I disabled all protections on the interfaces in the DHCP zone. This allowed the DHCP server to work as expected.


So there are a couple things going on here:

It appears that my zone on SmartOS when configured with "allow_dhcp_spoofing":true disables ip-nospoof. I was surprised by this behavior personally - I'm not immediately sure why a DHCP server packet would require spoofing an IP address. However, this could just be my ignorance about how DHCP's server work showing.

My first thought was to have zadm be able to set (or reset) link properties, but after more thought I realize the persistence of those would be more the responsibility of the brand scripts and how they tie in with what zadm does during creation.

This is all a long winded way to ask:

hadfl commented 2 years ago

zadm does not set any link protection properties when creating vnics; as andy mentioned it's the allowed-address zone net attribute that sets ip-nospoof. You can either create a vnic manually or let zadm create it, but don't specify neither global-nic nor allowed-address (you can use the over attribute in the zone net config to tell zadm which link to use for the vnic to create if it does not exist, yet).

We'll discuss it in the team how to make setting vnic link protection properties easier.

bahamas10 commented 2 years ago

Ok, great thank you for the reply @hadfl . I was able to create the VNICs manually and just give them to the zone with no protections (and no allowed-address) properties. I then was able to use ipadm in the zone to give them the right addresses and this gives me the result I want.


I made this GitHub issue to mostly ask is this something that zadm can/could support (if it's feasible). In the SmartOS world configuring the JSON manifest was enough to make the VNICs in a way that I never had to manually intervene with. I don't mind having to create the VNICs with dladm and then use ipadm in the zone - I just wanted to know if this was possible with zadm before I reached for my manual solution.

PS: Thank you both for the quick replies - you've both eased a lot of the learning curve I had coming from the SmartOS world!


[edit] for anyone coming here from google, here is how I accomplished this:

In the global zone I created the VNICs with the vlan IDs in the global zone over my physical NIC (e1000g0, found via dladm show-phys):

dladm create-vnic -l e1000g0  newdhcp0
dladm create-vnic -l e1000g0 -v 3 newdhcp1
dladm create-vnic -l e1000g0 -v 4 newdhcp2
dladm create-vnic -l e1000g0 -v 5 newdhcp3

Then, I modified the zadm manifest for my zone to look like:

$ zadm show dhcp
... snipped ...
[[net]]
physical="newdhcp0"
[[net]]
physical="newdhcp1"
[[net]]
physical="newdhcp2"
[[net]]
physical="newdhcp3"

After booting the zone I zlogin'd in and set up the interfaces with their correct IPs via ipadm:

ipadm create-addr -T static -a 10.0.1.4/24 newdhcp0/v4
ipadm create-addr -T static -a 10.0.2.4/24 newdhcp1/v4
ipadm create-addr -T static -a 10.0.3.4/24 newdhcp2/v4
ipadm create-addr -T static -a 10.0.4.4/24 newdhcp3/v4
route add default 10.0.1.1
echo 10.0.1.1 > /etc/defaultrouter

With all of that the interfaces should be setup and ready to server DHCP traffic, and survives reboots.

hadfl commented 2 years ago

I just wanted to know if this was possible with zadm before I reached for my manual solution.

We could certainly enhance zadm to deal with link protection properties; however, to fully support it even for "transient" vnics we'll have to imlement it at the zone brand level.

bahamas10 commented 2 years ago

This all makes sense - I'll close this issue for now