| Age | Commit message (Collapse) | Author |
|
T8963: policy-route: trigger domain resolver for domain groups
|
|
Signed-off-by: Miaosen Wang <secretandanon@gmail.com>
|
|
|
|
Three related bugs prevented GeoIP nftables sets from being populated
correctly at boot and when incrementally modifying firewall or policy
route rules.
1. geoip_updated() always returned False
The previous implementation called node_changed() and then searched
the result with dict_search_recursive(changes, 'geoip'). This could
never match: node_changed() is annotated `-> list` and returns a flat
list of the immediate top-level child names whose subtree changed
(e.g. ['ipv4'] for the firewall path, or route names for policy
route). The 'geoip' key sits several levels deeper than those names,
so dict_search_recursive — which only walks dicts and lists for a
matching dict key — never yielded a hit, and geoip_updated() always
returned False. As a consequence, geoip_update() was never triggered
by an incremental add or change of a GeoIP rule; the only path that
ever populated /run/nftables-geoip.conf was the explicit \"update
geoip\" command or the fallback when geoip_refresh() failed.
Fix: bypass node_changed() and call get_config_diff() /
get_child_nodes_diff() directly with expand_nodes=Diff.ADD|Diff.DELETE
and recursive=True. In that mode, the 'add' and 'delete' values in
the returned dict are full nested subtrees of the config diff, so
dict_search_recursive correctly finds 'geoip' wherever it appears in
the change set.
2. GeoIP block executed unconditionally, breaking the boot sequence
geoip_sets() always returns {'name': [], 'ipv6_name': []}. A
non-empty dict is truthy in Python regardless of whether its values
are empty lists, so the guards \"if geoip_sets:\" and
\"if 'name' in geoip_sets:\" were always True.
On boot, when policy_route.py is invoked as a dependent of
firewall.py (triggered by group_resync), it entered the GeoIP block
even with no policy route GeoIP rules configured. Because
/run/nftables-geoip.conf did not yet exist, geoip_refresh() returned
False and geoip_update(policy=policy) was called with an empty
policy. This created /run/nftables-geoip.conf containing only empty
table stubs. When firewall.py subsequently called geoip_refresh(),
the file existed and nft loaded it successfully — so the
geoip_update(firewall) call was never reached and the firewall GeoIP
sets stayed empty for the entire uptime of the router.
Fix: check the actual list contents instead of the container dict:
if geoip_sets['name'] or geoip_sets['ipv6_name'].
3. geoip_update() clobbered the other caller's sets
geoip_update() renders /run/nftables-geoip.conf from both
firewall_sets and policy_sets in a single pass. When called with
only one argument (as firewall.py and policy_route.py each do), the
other argument defaulted to None and that half of the file was
rendered empty, erasing whatever the other script had written. The
geoip-update helper used by \"update geoip\" and the weekly cron was
unaffected because it always passes both arguments, which masked
this bug in normal manual operation.
Fix: when either argument is absent, read the missing config from
the live Config session before building the set tables, so every
invocation writes the complete combined firewall + policy file.
|
|
|
|
* Move core logic to separate vyos.geoip module
* Use a sqlite database for storing and querying address ranges by country
* Remove downloaded geoip ranges once loaded into sqlite db
* No longer rebuild geoip sets on each commit unless necessary
* Allows for extensibility using other geoip data vendors
|
|
The legal team says years are not necessary so we can go ahead with it, since
it will simplify backporting.
Automatically removed using: git ls-files | grep -v libvyosconfig | xargs sed -i -E \
's/^# Copyright (19|20)[0-9]{2}(-[0-9]{4})? VyOS maintainers.*/# Copyright VyOS maintainers and contributors <maintainers@vyos.io>/g'
In addition we will error-out during "make" if someone re-adds a legacy
copyright notice
|
|
|
|
Commit 452068ce78 ("interfaces: T6592: moving an interface between VRF instances
failed") added a similar but more detailed implementation of get_vrf_table_id()
that was added in commit adeac78ed of this PR. Move to the common available
implementation.
|
|
* PBR can only target table IDs up to 200 and the previous PR to extend the
range was rejected
* PBR with this PR can now also target VRFs directly by name, working around
targeting problems for VRF table IDs outside the overlapping 100-200 range
* Validation ensures rules can't target both a table ID and a VRF name
(internally they are handled the same)
* Added a simple accessor (get_vrf_table_id) for runtime mapping a VRF name
to table ID, based on vyos.ifconfig.interface._set_vrf_ct_zone().
It does not replace that usage, as it deliberately does not handle non-VRF
interface lookups (would fail with a KeyError).
* Added route table ID lookup dict, global route table and VRF table defs
to vyos.defaults. Table ID references have been updated in code touched
by this PR.
* Added a simple smoketest to validate 'set vrf' usage in PBR rules
|
|
|
|
appropiate commands to populate such groups using source and destination address of the packet.
|
|
We will use _ as CLI level divider. The XML definition filename and also
the Python helper should match the CLI node.
Example:
set interfaces ethernet -> interfaces_ethernet.xml.in
set interfaces bond -> interfaces_bond.xml.in
set service dhcp-server -> service_dhcp-server-xml.in
|