In some cases it may be beneficial to let clients discover the addresses of site servers dynamically. To achieve this, YSoft SafeQ Client v3 can leverage existing DHCP infrastructure, namely DHCP's LPR server option.

Prerequisites

A DHCP server is necessary to utilize this feature. The DHCP server needs to be configured to respond with the LPR server option. The contents of the response is a list of IPv4 addresses of site servers. Note that this differs from the standard meaning of the option, i.e. a list of LPR server addresses.

Enabling the feature

To enable the feature, either use the appropriate option when installing YSoft SafeQ Client v3 (see Deployment of YSoft SafeQ Client v3) or manually set the following configuration value in the local.json configuration file:

{
"DhcpDiscoveryOptions": {
"Enabled": true
}
}

Details of operation

When YSoft SafeQ Spooler starts up, it will (by default) broadcast a DHCPINFORM message on every network interface that is available. It will wait for at most one response on each interface and then it will collect all the LPR server addresses from all the responses it received and use those as site server addresses instead of the usual SiteServerOptions.SiteServers configuration property.

Since there is no way to specify ports using the LPR server option, default ports will be assumed.

Potential security issue

Please note that when the SiteServerOptions.DisableCertificateValidation configuration option is set then YSoft SafeQ Spooler will have no issues connecting to any YSoft SafeQ Job Service that it discovers via DHCP. This is exploitable by an attacker running their own DHCP server and YSoft SafeQ Job Service to, for example, leak user's credentials.

It may be undesirable to attempt discovery on all interfaces or to accept all the results that were received. A result filtering facility is provided for these cases, see below.

Result filtering

To filter out unnecessary or unwanted results obtained through this feature, a list of filtering rules can be configured in the local.json configuration file. As an example, the rules might look something like this:

{
"DhcpDiscoveryOptions": {
"Enabled": true,
"FilterRules": [
{
"Name": "Block a specific site server",
"MatchSiteServerAddress": { "Address": "10.0.0.2" },
"Action": "Deny"
},
{
"Name": "Block results from Ethernet 1",
"MatchInterfaceName": "Ethernet 1",
"Action": "Deny"
},
{
"Name": "Deny a range of site server addresses from a specific DHCP server",
"MatchDhcpServerAddress": { "Address": "10.0.0.1" },
"MatchSiteServerAddress": { "AddressFrom": "10.0.2.0", "AddressTo": "10.0.2.255" },
"Action": "Deny"
},
{
"Name": "Allow results from interfaces with addresses in the given range",
"MatchInterfaceAddress": { "AddressFrom": "10.0.1.0", "AddressTo": "10.0.1.255" },
"Action": "Allow"
},
{
"Name": "Block all other results",
"Action": "Deny"
}
]
}
}

Each rule consists of three parts:

its name - is purely used for logging purposes to aid with debugging of rules, can be any string
a set of match criteria - these specify certain conditions that have to be met by a result in order to match the rule
an action - an action that will be done to the result when it's matched by the match criteria, the value can be either Allow or Deny

Rules are always evaluated top-down. An attempt is made to match each result with the match criteria in each rule. If the match is successful, the result is either accepted or discarded based on the action. If the match is not successful, the evaluation proceeds to the next rule. A result that is not matched by any rule will be accepted.

Note that if there are any network interfaces where all of their results would definitely be discarded (such as Ethernet 1 in the example above) then no discovery attempts will be made on those interfaces.

Match criteria

A rule may specify any number of match criteria. All of them have to match in order for the whole rule to be considered a match. The following match criteria are available:

MatchInterfaceName - Matches an interface by its name. The value of this criterion has to be a string that has to exactly match the interface name.
MatchInterfaceAddress - Matches an address of a network interface. Note that network interfaces may have multiple addresses at the same and matching only one of them will not affect any of the others.
MatchDhcpServerAddress - Matches the address of the DHCP server from which the result was received.
MatchSiteServerAddress - Matches the address of the received Site Server.

IP Address matching

When matching an IP address using either MatchInterfaceAddress, MatchDhcpServerAddress or MatchSiteServerAddress, the value of the criterion has these attributes:

Address - matches a single address exactly
AddressFrom - matches all addresses greater than or equal to this address
AddressTo - matches all addresses less than or equal to this address

In order to be considered a match, an address either has to match the Address attribute (if specified), or it has to fall within the range of addresses specified by AddressFrom and AddressTo (if at least one of them is specified).