Repository navigation
v0.3.1
Install on the hub (Iran server) — نصب روی هاب (سرور ایران):
bash <(curl -fsSL https://github.com/localroot4/DeyRoute/releases/latest/download/install.sh)This release exactly: bash <(curl -fsSL https://github.com/localroot4/DeyRoute/releases/download/v0.3.1/install.sh) --version 0.3.1
Already installed? Run deyroute update on the hub (the nodes follow).
قبلاً نصب کردهاید؟ روی هاب deyroute update بزنید (نودها خودشان دنبال میکنند).
What's new in 0.3.1
Added
deyroute setup --public-ip A.B.C.Dand--public-ip6 Xstore exactly
that hub address (canonical form) and skip the wizard's IP question;
--allow-private-ipaccepts a private, CGNAT or loopback address for test
labs (never a link-local one). A refused address isDEY-C013before any
setup step; the three flags are refused with--role nodeand on
deyroute join.setup --jsonaddspublic_ip_source(flag,
detectedorwizard). Without the flag nothing changes: a private
detection still only warns (DEY-I021), so automation on a NAT or
floating-IP server must pass--public-ip(docs/en/install.md, lab S01,
DR-07).deyroute join --sysctl off|balanced|auto(defaultbalanced; when
given, the kernel question is not asked;offwrites nothing under
/etc/sysctl.d) and--reserve-ports LIST(ports and ranges, the flag
repeats, at most 64 entries, at least 1024 ephemeral ports left free;
withoffit isDEY-C013).join --jsonaddsreserved_ports(never
null). The entries are kept in/var/lib/deyroute/reserved-portsand
reserved again by every profile the node applies exceptoff
(docs/en/join.md, docs/en/tuning.md, lab S23, DR-09).- A node joined with
--sysctl off, or whose owner answered no to the
kernel question, refuses the hub's kernel tuning (optimize applyand
optimize auto) with the newDEY-N052; a revert tooffstill runs.
The switch is the root-only marker/var/lib/deyroute/hub-tuning-off: to
lift it, remove it on the node and re-apply the hub's profile as
deyroute optimize statusshows it. Nodes joined with an earlier version
keep following the hub (QUESTIONS.md C.65, DR-09).
Changed
- The
balancedandaggressiveprofiles a node applies, at join or
pushed by the hub, now also reserve the backend control range
30000-31999innet.ipv4.ip_local_reserved_ports, asautoalready
did (a set union: existing reservations stay). Migration: on the hub,
re-apply the profiledeyroute optimize statusshows (deyroute optimize autoon an auto hub, otherwisedeyroute optimize apply --profile <that profile>) so the online nodes reserve the range now (QUESTIONS.md C.64,
DR-09).
Fixed
deyroute setup --helpsaid--yesapplies the balanced kernel profile;
it applies the automatic profile, and the help now says so (deyroute optimize statusshows it). The hiddenjoin --yeskeeps its own text: a
join applies balanced (docs/en/install.md, DR-19).- The sysctl backup recorded the live union of
net.ipv4.ip_local_reserved_portsas deyroute's value, so a later apply
followed by a revert or uninstall also removed a port another program
had reserved in between. It now records only the entries deyroute
requested; the kernel write is still the union (DR-09). deyroute optimize checkno longer reports the reserved ports as drift
when another program adds or removes its own reservation; only a port
deyroute wants that is missing counts (DR-09).
Added — the firewall table comes back by itself
- The hub and every node now check their table
inet deyrouteevery 60
seconds and apply it again when it is missing or changed (nft flush rulesetby an admin or a provider script,ufw reloadon some systems,
another tool). The new keysecurity.firewall_reassert_ssets the
interval (10-3600 seconds, 0 = off; absent = 60). A node checks only
while it has NAT rules (WireGuard/AmneziaWG rungs, Hysteria2 port
hopping) and no longer keeps a flushed table gone until its rules
change. Nothing is checked withsecurity.firewall_managed: false. The
hub records the warning eventfirewall_reapplied(reasonmissingor
drift, at most once per 10 minutes per reason; Telegram sends it when
hub.notify.telegram.eventsnames it); a node writes the same warning
tonode.log(docs/en/security.md, docs/en/monitoring.md, lab S37). - Releases before 0.3.1 do not know
security.firewall_reassert_sor
firewall_reappliedinhub.notify.telegram.events: while either is
set,deyroute update --rollbackandupdate --versionto such a
release are refused (DEY-S011), and a node refuses a self.update to
such a release while its ownconfig.yamlsets the key.
Changed — unknown control-port sources are limited per address
- A node whose public IP changed reconnects through the admission for
unknown sources. That admission was one global bucket of 6 new
connections per minute, which a single scanner could use up. Each
source address now has its own budget of 3 per minute (burst 3; the
dynamic sets@ctl_unknown4/@ctl_unknown6, 10-minute buckets) and all
unknown sources together at most 30 per minute. New keys
security.unknown_control_rate_per_source(default3/minute) and
security.unknown_control_rate(default30/minute) take nft rates.
When nft or the kernel refuses the per-source form, the hub applies the
earlier single rule atunknown_control_rate, keeps it until it
restarts and logsnft refused the per-source limit of the control portonce (docs/en/security.md, lab S27). - Migration: nothing to do; the hub applies the new rules at its next
start. While either new key is set, a rollback below 0.3.1 is refused
(DEY-S011).
Fixed — port check behind a per-source limit
deyroute port checkread an nftables rule of another firewall that
adds the source to a set with a per-element limit (add @set { ip saddr limit rate … },meter) as never matching, so a port behind it was
reported blocked; it now counts as a rate-limited accept, like
limit rate … accept.
More in the full changelog.
Full changelog · راهنمای فارسی · English guides
Verify
SHA256SUMS is signed with minisign; the installer and deyroute update check it before anything is installed. Public key: RWQtE2Hu1KwstgupEuPAWy+J2tiIgFVTIcReWI+Qh+yGMY3s2xWpyMuO