Opncentral (#383)

* OPNcentral - work in progress upcoming features§

* OPNcentral - work in progress upcoming features

* Development / API reference - Add BE core API descriptions
pull/385/head
Ad Schellevis 2 years ago committed by GitHub
parent ed1ddef0e4
commit 89523d5911
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -48,3 +48,18 @@ Plugins API
:glob:
api/plugins/*
Business edition API
------------------------
The business edition comes packed with some additional features which could also be used
for integration purposes from third-party applications. The most relevant ones will be explained in this section.
.. toctree::
:maxdepth: 2
:titlesonly:
:glob:
api/be/*

@ -0,0 +1,144 @@
OPNBECore
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. csv-table:: Resources (SyncController.php) -- extends : ApiControllerBase
:header: "Method", "Module", "Controller", "Command", "Parameters"
:widths: 4, 15, 15, 30, 40
"``GET``","opncentral","sync","listServices",""
"``GET``","opncentral","sync","listClasses",""
"``GET``","opncentral","sync","metrics",""
"``GET``","opncentral","sync","readConfig","$paths"
"``POST``","opncentral","sync","reconfigure",""
"``POST``","opncentral","sync","restartService",""
-----------------------
Sync API explained
-----------------------
The :code:`sync` API is being used to process central actions in parallell from the OPNcentral dashboard.
As explained in the documentation for OPNcentral, provisioning is able to detect change on the sections it may
distribute. In order to do this the :code:`listClasses` API action plays a large role here.
listClasses
.........................
The list classes endpoint provides insights into the different configuration items the target host understands
and how these are tied into services. It's also a key component in comparing configuration items.
.. code-block:: json
{
"classes": [
{
"description": "Aliases",
"help": "Synchronize the aliases over to the other HA host.",
"section": "OPNsense.Firewall.Alias",
"services": [
"pf"
],
"md5": "942d6358fb4f17abed7cf4f5de6c5b24",
"id": "aliases"
},
....
"runtime": 0.07380509376525879
}
When the target firewall is 100% equal to the central node, the :code:`md5` values will match. In order to steer
specific overrides on the synchronisation action, it is possible to send a json encoded base64 structure as :code:`metadata`
post parameter (not available in the online documentation, advanced usage only).
readConfig
.........................
This endpoint is responsible for providing access to various parts of the configuration and mostly practical
to retrieve parts of the configuration.
Example usage of this endpoint is provided below.
.. code-block:: python
import json
import requests
auth = {
"key":"3RhWOno+HwvtmT406I6zw8of8J6n9FOKlWK6U0B+K7stt/fDaJg7bjeF3QAshlScYqC+3o5THy3vQViW",
"secret":"uaBk27NKhQCZSDpfAlG6YJ473MzvsCNiED6kzbYuykzU05fCRkcJADhDm5nxbZt8yREC74ZpvD/vbcEx"
}
r = requests.get(
'https://127.0.0.1/api/opncentral/sync/read_config/OPNsense.Firewall.Alias',
auth=(auth['key'], auth['secret']),
verify=False # use for localhost testing only
)
print(r.text)
When executed, this will dump the contents of the configuration path :code:`OPNsense.Firewall.Alias` into a named array
with serialisable content.
reconfigure
.........................
The reconfigure action is the counterpart of the readConfig endpoint and accepts new configuration data specified in
the :code:`payload` attribute of the :code:`POST` request.
In some cases configuration merges have ways to handle local changes, which is documented in the "Provisioning classes"
section of the OPNcentral documentation.
After merging the new configuration, this endpoint also detects which services need to be restarted and will issue
a restart command automatically.
.. code-block:: python
import json
import requests
auth = {
"key":"3RhWOno+HwvtmT406I6zw8of8J6n9FOKlWK6U0B+K7stt/fDaJg7bjeF3QAshlScYqC+3o5THy3vQViW",
"secret":"uaBk27NKhQCZSDpfAlG6YJ473MzvsCNiED6kzbYuykzU05fCRkcJADhDm5nxbZt8yREC74ZpvD/vbcEx"
}
payload = "<<dictionary type content from readConfig>>"
r = requests.post(
'https://127.0.0.1/api/opncentral/sync/reconfigure',
auth=(auth['key'], auth['secret']),
json={'payload': payload},
verify=False, # use for localhost testing only
headers={'Content-Type': 'application/json; charset=UTF-8'}
)
listServices
.........................
In order to gain insights on the active running services, you can use the listServices api action.
This will report all active services and their status.
restartService
.........................
The restart service action is also used in :menuselection:`Management: Status / Services` and offers the ability
to restart a list of selected services on the target host.
.. code-block:: python
import json
import requests
auth = {
"key":"3RhWOno+HwvtmT406I6zw8of8J6n9FOKlWK6U0B+K7stt/fDaJg7bjeF3QAshlScYqC+3o5THy3vQViW",
"secret":"uaBk27NKhQCZSDpfAlG6YJ473MzvsCNiED6kzbYuykzU05fCRkcJADhDm5nxbZt8yREC74ZpvD/vbcEx"
}
r = requests.post(
'https://127.0.0.1/api/opncentral/sync/restart_service',
auth=(auth['key'], auth['secret']),
json={'services':['cron']},
verify=False, # use for localhost testing only
headers={'Content-Type': 'application/json; charset=UTF-8'}
)
The example above will restart the :code:`cron` service.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 259 KiB

After

Width:  |  Height:  |  Size: 313 KiB

@ -42,6 +42,19 @@ the url from the machine and the API key and secret generated above.
Alter generic host settings
..................................
The second tab in the screen contains the setting page which configures defaults for all hosts where applicable.
================================= ===============================================================================================================================================
Option Description
================================= ===============================================================================================================================================
Interfaces Select the interfaces of the central node that would be used when merging settings on the remote firewall, only applicable on part of the
configuration sections (such as the firewall). See the provisioning section for more details.
================================= ===============================================================================================================================================
Connect to managed machine
----------------------------------
@ -208,14 +221,129 @@ You can either selectlively reconfigure specific hosts with the checkbox or reco
<i class="fa fa-times text-danger" style="color:#F05050"></i> Unable to connect <br/><br/>
Provisioning classes
----------------------------------------------------
By default merging configuration items from the central firewall overwrites the settings on the target machine, but in some
cases we need a more practical approach to deal with local modifications.
In this chapter we are going to describe how classes with special implemenations are being treated on synchronisation and
how to utilise this behaviour to ease management.
Users & Groups
....................................................
When users and groups are synchronized, the existing api key+secret is merged into the user with the same name to prevent access
issues after reconfigure. To avoid issues, make sure there's a unique username with proper credentials before using
the synchronization.
.. Note::
Although quite some setups will likely use external authentication options available in OPNsense, sometimes it's practical
to share the same user database among different firewalls. This option allows for sharing, without the need to
sue the same key+secret on all connected firewalls.
Aliases (Firewall)
....................................................
Since various firewall sections depend on aliases, OPNcentral checks if aliases are used before removing local aliases
from the remote firewall.
Due to this powerful feature, after synchronisation of the central aliases you can also use nesting to combine remote aliases
into new local ones.
For example, when the local machine has :code:`local_alias_1` and the central location offers :code:`central_alias_1`
when both are combined into :code:`local_alias_2` and :code:`local_alias_2` is used in firewall/nat rules it will
automatically merge central changes after a reconfigure action from the dashboard.
.. blockdiag::
:desctable:
blockdiag {
local_alias_1 [label="'local'\nlocal_alias_1"];
central_alias_1 [label="'central'\ncentral_alias_1"];
local_alias_2 [label="'merged'\nlocal_alias_2"];
local_alias_1 -> local_alias_2 [label="in"]
central_alias_1 -> local_alias_2 [label="in"];
}
.. Note::
As long as :code:`local_alias_2` is used, both :code:`local_alias_1` and :code:`local_alias_2` will be preserved after provisioning.
Firewall rules
....................................................
Merging the firewall rules will keep the interfaces unaltered which don't exists on the central node as these are being provided to
the target firewall. In case you want to exclude some interfaces (for all remote firewalls), you can easily override the
known interfaces in :menuselection:`Management -> Host configuration` on the General settings tab.
Since there's an explicit order in which different types of rules are being handled, you can choose if you want to prefer
central rules being matched first or last depending on the type of "interface" to use.
.. blockdiag::
:desctable:
blockdiag {
System [label="System defined", style = dotted];
Floating [label="Floating rules"];
Groups [label="Interface groups"];
Interfaces [label="Interfaces"];
System -> Floating -> Groups -> Interfaces;
}
.. Tip::
When users and groups are synchronized, the existing api key+secret is merged into the user with the same name to prevent access
issues after reconfigure. To avoid issues, make sure there's a unique username with proper credentials before using
the synchronization.
When forcing interface groups to the backup node, these will precede interface rules such as LAN and WAN, when only sending
over interface groups the remote firewall is able to allow traffic which would otherwise be rejected.
.. Note::
When multiple interfaces are attached to a (floating) rule, these will be removed by the provisioning algorithm as
the intend isn't fully clear in these matters.
.. Note::
Rules on the central node which do apply to all interfaces or a selection of interfaces are always being send to the remote
firewall. When this isn't intentional, best not use these options in the "floating" rules.
NAT (Firewall)
....................................................
Merging the nat rules will keep the interfaces unaltered which don't exists on the central node as these are being provided to
the target firewall. In case you want to exclude some interfaces (for all remote firewalls), you can easily override the
known interfaces in :menuselection:`Management -> Host configuration` on the General settings tab.
.. Note::
All NAT type rules (:code:`Port Forward`, :code:`One-to-One`, :code:`Outbound`, :code:`NPTv6`) are treated similar.
.. Note::
Since various firewall sections depend on aliases, OPNcentral checks if aliases are used before removing local aliases
from the remote firewall.
When multiple interfaces are attached to a rule, which is possible for port forwards. These will be removed by the provisioning algorithm.
.. Note::
Port forwarding rules on the central node which do apply on a selection of interfaces are always being send to the remote
firewall. When this isn't intentional, best prevent the usage of these forwards.
Firewall categories
....................................................
Merging categories will preserve the ones that are currently used on the remote firewall.
WebGui (Administration)
....................................................
To prevent breakage after synchronisation, the certificate used by the webgui will be preserved after synchronisation.
.. Note:
Currently it's not possible to merge certificates and webgui admin settings, as the certificate store will be
overwritten in that case.

Loading…
Cancel
Save