Kariz v2.6.0-beta.2

A beta, like 2.6.0-beta.1:
only panels on the Beta channel are offered it; kariz-manager update and the stable channel
stay on 2.5.1. To try it on a server by hand: kariz-manager install --version v2.6.0-beta.2.

VXLAN now also where an agent is set up, and in the benchmark: a server that GRE does not reach
the panel's server from but UDP does can be added over a VXLAN link, and a benchmark measures
GRE and VXLAN links each on their own. Update the panel first, then the agents from the panel.

Added

• An agent over a VXLAN link. Add server now has Over a VXLAN link beside Over a GRE
  link, for a server that GRE does not reach the panel's server from but UDP does. The link's
  addresses come from the first VXLAN network, or the panel makes one (kariz-vxlan, UDP 4789,
  on the first pool free beside the others); its own end comes up at once and the command makes
  the server's end before the agent connects across it. The panel connects to it (Across a
  private link) and a server's Edit ask GRE or VXLAN for a new link too. API: kind (gre
  or vxlan) in join-gre, and in the gre of join-reverse and reconnect.
• VXLAN in the benchmark. A benchmark now measures the VXLAN link between two servers too
  (tcp with mux, kcp and quic), marked VXLAN, beside the GRE link when there are both.
  Before, only the first link of any kind was measured, and called GRE. Using such a result
  puts the tunnel on that link's network.

Kariz v2.6.0-beta.1

A beta: a prerelease that only panels on the Beta channel are offered (Settings,
Updates, Channel); kariz-manager update and the stable channel stay on 2.5.1. To try it on
a server by hand: kariz-manager install --version v2.6.0-beta.1. On a server that runs the
beta, kariz-manager update installs the latest stable release (2.5.1) again: update it from
the panel instead.

Private networks can now be VXLAN as well as GRE: for two servers between which GRE
(protocol 47) does not pass but UDP does. Both servers of a VXLAN link need this version:
update the panel first, then the agents from the panel. The GRE networks and links you have
stay as they are.

Added

• VXLAN private networks. In Networks, New network now asks for the link type: GRE, or
  VXLAN over a UDP port (4789 by default; every network has its own, so when one port is
  blocked, make another network on another port). Each link of a VXLAN network is a one-peer
  VXLAN interface (ip link add kz-XXXXX type vxlan id VNI local A remote B dstport PORT) with
  an MTU of 1450, and the panel gives it a VNI that no other VXLAN link of either server has.
  Everything a GRE network does works over VXLAN too: mesh and hub and spoke, tunnels that listen
  on and dial the private addresses, an agent that reaches the panel across a link, adding a
  server over a link, and links that come back after a reboot. Before it makes anything the panel
  checks that both servers can make VXLAN (the vxlan module) and run 2.6 or newer, and it pings
  across each link before it keeps it; a UDP port blocked on the way is named, with the iptables
  line that opens it.
  See private networks.

Changed

• A network's card shows its kind (and, for VXLAN, its port), the links table the VNI, and the
  wizard's network list, the panel's addresses and the server chips (via VXLAN · network) say
  which kind a link is.

Kariz v2.5.1

The stable release after 2.3.0, with everything of the two betas
(2.4.0-beta.1 and
2.5.0-beta.1);
there is no 2.5.0. Built for busy evenings: a tunnel takes 4096 streams per connection
instead of 512, says so when it is full, a health probe tells whether a new connection gets
through, and Xray behind a tunnel can see each user's real address (PROXY protocol), so
device limits in 3x-ui or Marzban work behind a tunnel too.

Update the panel first, then the agents from the panel (or kariz-manager update on each
server): each side checks its own stream limit, and the probe and the PROXY header need this
version on both servers. A server on one of the betas is offered 2.5.1 on either channel.

Added

• Real user addresses for Xray (PROXY protocol). Every user reached the target from the exit
  server's own Kariz process, so Xray saw 127.0.0.1 for everyone: per-account IP and device
  limits in 3x-ui or Marzban, Xray's logs, IP routing rules and fail2ban on the exit server all
  saw one address. A forward rule can now have proxy_protocol = "v1" or "v2": the exit side
  starts each TCP connection to the target with a PROXY header carrying the user's address and
  port (UDP flows never get one). In the panel: Real user IPs (PROXY protocol) in the wizard
  and on the edit page, written to every TCP port of the tunnel. The target must expect the
  header: turn on acceptProxyProtocol on the Xray inbound behind those ports (in 3x-ui, the
  inbound's Proxy Protocol switch), or every connection through them breaks. Both servers need
  2.5 or newer; the panel refuses the setting while either runs an older version.
  See configuration.
• A health probe: does a new connection get through? A tunnel could be connected, moving
  60-100 Mbit/s for the users already on it, while every new connection failed: a busy evening
  had taken every stream, or the target (Xray) was down. Every 15 seconds the entry side now
  opens a connection the way a user's is opened and has the exit side connect to a forwarded
  target. kariz status shows the result on a health line, the status document has it as
  probe, the tunnel's page in the panel has a Health card, Needs attention lists such a
  tunnel, and the Telegram bot tells when three probes in a row fail (and when it is fixed). An
  exit side older than 2.4 is shown as not answering probes, never as a failure.
• How full a tunnel is. The status document has streams and streams_max (with mux), and
  full: new connections that failed because every connection was full. The panel draws it as a
  bar, lists a tunnel at 80 % in Needs attention and the Telegram bot tells once.
• A limit per user address (tuning.max_conns_per_ip, off by default): connections and UDP
  flows one client address may hold open, over all forwarded ports; more are closed at once and
  counted (refused_per_ip). In the panel: Connections per user address in the wizard and on
  the edit page. Users on mobile networks often share one address, so it stays off unless set.

Changed

• 4096 streams per connection by default, up from 512 (tunnel.mux.max_streams, now up to
  16384). With four connections a tunnel took only 2048 user connections and UDP flows at once
  (1024 with the gaming profile or QUIC), which a busy server reaches; then new connections waited
  20 seconds and failed while the open ones kept working. A stream that is not in use costs
  nothing. Each side checks its own limit, so update both servers.
• A full tunnel says so. A connection that found every session full failed with no tunnel
  connection available (is the other side running?), at debug level. Now it says every tunnel
  connection is full (N streams open) with what to raise, as a warning (at most every 30
  seconds).

Fixed

• The panel names the server to update. When a tunnel used something one server was too old
  for (a chosen cipher, sealed QUIC, the 2.4 limits), checking or saving it failed with
  internal instead of saying which server to update.
• Betas past nine. The panel's updater compared 2.4.0-beta.10 and 2.4.0-beta.9 as text,
  so the tenth beta looked older and was not offered. The parts after the dash are compared as
  semver does now.
• The panel's mux form showed 4 connections as QUIC's default; it is 2.

Kariz v2.5.0-beta.1

A beta: a prerelease that only panels on the Beta channel are offered (Settings,
Updates, Channel); kariz-manager update and the stable channel stay on 2.3.0. To try it on
a server by hand: kariz-manager install --version v2.5.0-beta.1. On a server that runs the
beta, kariz-manager update installs the latest stable release (2.3.0) again: update it from
the panel instead.

Xray behind a tunnel can now see each user's real address (PROXY protocol), so device
limits in 3x-ui or Marzban work behind a tunnel too. It is off unless chosen, and Xray must be set to
expect it first (acceptProxyProtocol), or every connection through those ports breaks.
Both servers need this version: update the panel first, then the agents from the panel. It
also carries everything of 2.4.0-beta.1 (4096 streams per
connection, the health probe, the per-address limit).

Added

• Real user addresses for Xray (PROXY protocol). Every user reached the target from the exit
  server's own Kariz process, so Xray saw 127.0.0.1 for everyone: per-account IP and device
  limits in 3x-ui or Marzban, Xray's logs, IP routing rules and fail2ban on the exit server all
  saw one address. A forward rule can now have proxy_protocol = "v1" or "v2": the exit side
  starts each TCP connection to the target with a PROXY header carrying the user's address and
  port (UDP flows never get one). In the panel: Real user IPs (PROXY protocol) in the wizard
  and on the edit page, written to every TCP port of the tunnel. The target must expect the
  header: turn on acceptProxyProtocol on the Xray inbound behind those ports (in 3x-ui, the
  inbound's Proxy Protocol switch), or every connection through them breaks. Both servers need
  2.5 or newer; the panel refuses the setting while either runs an older version.
  See configuration.

Fixed

• The panel names the server to update. When a tunnel used something one server was too old
  for (a chosen cipher, sealed QUIC, the 2.4 limits), checking or saving it failed with
  internal instead of saying which server to update.

Kariz v2.4.0-beta.1

A beta: a prerelease that only panels on the Beta channel are offered (Settings,
Updates, Channel); kariz-manager update and the stable channel stay on 2.3.0. To try it on
a server by hand: kariz-manager install --version v2.4.0-beta.1. On a server that runs the
beta, kariz-manager update installs the latest stable release (2.3.0) again: update it from
the panel instead.

Built for busy evenings: a tunnel takes 4096 streams per connection instead of 512, says so
when it is full, and a health probe tells whether a new connection gets through, not only
whether the tunnel is connected. Update the panel first, then the agents from the panel:
each side checks its own stream limit, and the probe needs 2.4 on both servers (with an older
exit side it is shown as not checked, never as a failure).

Added

• A health probe: does a new connection get through? A tunnel could be connected, moving
  60-100 Mbit/s for the users already on it, while every new connection failed: a busy evening
  had taken every stream, or the target (Xray) was down. Every 15 seconds the entry side now
  opens a connection the way a user's is opened and has the exit side connect to a forwarded
  target. kariz status shows the result on a health line, the status document has it as
  probe, the tunnel's page in the panel has a Health card, Needs attention lists such a
  tunnel, and the Telegram bot tells when three probes in a row fail (and when it is fixed). An
  exit side older than 2.4 is shown as not answering probes, never as a failure.
• How full a tunnel is. The status document has streams and streams_max (with mux), and
  full: new connections that failed because every connection was full. The panel draws it as a
  bar, lists a tunnel at 80 % in Needs attention and the Telegram bot tells once.
• A limit per user address (tuning.max_conns_per_ip, off by default): connections and UDP
  flows one client address may hold open, over all forwarded ports; more are closed at once and
  counted (refused_per_ip). In the panel: Connections per user address in the wizard and on
  the edit page. Users on mobile networks often share one address, so it stays off unless set.

Changed

• 4096 streams per connection by default, up from 512 (tunnel.mux.max_streams, now up to
  16384). With four connections a tunnel took only 2048 user connections and UDP flows at once
  (1024 with the gaming profile or QUIC), which a busy server reaches; then new connections waited
  20 seconds and failed while the open ones kept working. A stream that is not in use costs
  nothing. Each side checks its own limit, so update both servers.
• A full tunnel says so. A connection that found every session full failed with no tunnel
  connection available (is the other side running?), at debug level. Now it says every tunnel
  connection is full (N streams open) with what to raise, as a warning (at most every 30
  seconds).

Fixed

• Betas past nine. The panel's updater compared 2.4.0-beta.10 and 2.4.0-beta.9 as text,
  so the tenth beta looked older and was not offered. The parts after the dash are compared as
  semver does now.
• The panel's mux form showed 4 connections as QUIC's default; it is 2.

Kariz v2.3.0

The benchmark now measures IPv6 (when both servers have an address), tries wss with
a server name to show whether a filter judges TLS by it, and measures quic across GRE; its
card is much lighter to read. A tunnel dialed at an IPv6 address now connects. Nothing changes
for 2.2.0 agents. Update the panel first (Settings, Updates), then the agents from the panel:
the IPv6 and server-name tests need both servers on 2.3.0 (an older agent is reported as one).

Added

• The benchmark measures IPv6 too. When both servers have a public IPv6 address, every
  transport is also tried between the two IPv6 addresses, side by side with IPv4 on the same
  port, so a run takes no longer; the best over IPv4 and the best over IPv6 are both measured
  for speed. When one server has no IPv6 address, the result says which. Using an IPv6 result
  puts the IPv6 address in the tunnel and has it listen on every address ([::]).
• wss with a server name in the benchmark. A wss test sent no server name (SNI), as for
  an IP address, while a tunnel with a domain sends one. Now the tunnel's own name (or one
  typed) has wss tried once more with it, to show whether a filter judges TLS by its name.
• quic across GRE in the benchmark, beside tcp with mux and kcp.

Changed

• A lighter benchmark. Before a run, one line and the button; while it runs, one bar and a
  chip per test; after it, the recommendation with three numbers (the rest under Details), the
  next two, and everything else folded under one line. At most one note is shown, the one that
  matters most.

Fixed

• A tunnel dialed at an IPv6 address. The wizard offers a server's IPv6 address to dial, but
  the tunnel listened on every IPv4 address only, so it never connected. It now listens on every
  address ([::]) when it is dialed at an IPv6 one.

Kariz v2.2.0

The panel now follows a new IP address of its server: when the address it had is filtered
and the provider gives a new one, the panel gets a certificate for the new address by itself and
opens there with no browser warning. And a server that was only ever updated from the panel gets
the manager menu of its release. Nothing changes for 2.1.0 agents. Update the panel first
(Settings, Updates), then the agents from the panel: each program that starts as 2.2.0 puts
the manager of 2.2.0 in place on its server.

Added

• The panel follows a new IP address of its server. When the server's IP address changes
  (the old one was filtered and the provider gave a new one) and the panel's certificate was for
  the old address, the browser refused it and the panel looked down. Now a timer
  (kariz-panel-heal.timer, a minute after boot and every 10 minutes) runs
  kariz-manager panel heal: it sees that the certificate's address is no longer on the server,
  gets a Let's Encrypt certificate for the new one, switches the panel to it and removes the old
  one. It asks for nothing unless the address changed, and waits an hour after a failure (Let's
  Encrypt limits failed attempts). Behind NAT, and for a domain, the change cannot be seen from
  the server: run panel cert. A panel set up before this gets the timer when it starts after
  the update.
• The manager says when the certificate no longer fits. The menu shows a line when the
  certificate is for an address the server does not have any more, the login link uses the new
  address, and item 6 (now New IP, domain or certificate) says what the certificate is for,
  whether its domain still points at this server, and offers the IP address first when the
  certificate was for one.

Fixed

• The manager's menu of an old release on a server updated from the panel. An update from
  the panel swaps the programs but not /usr/local/bin/kariz-manager, so a server set up long
  ago and only ever updated from the panel went on showing the menu of the release it was
  installed with. The panel and the agent now put the manager of their own release in place each
  time they start (an update restarts them), when the one there is missing or different. And
  kariz-manager update fetches the script of the release it installed instead of the newest
  one on main, so the two ways of updating agree.

Kariz v2.1.0

Two new things, both working with the agents you have: the benchmark finds the transport
that gets through best between two servers before a tunnel is built, and the panel can connect
to a server across a GRE link. The panel had a UX review, and getting a certificate for a wss
tunnel works on servers set up with an older Kariz. The benchmark and the GRE link need the agents
on both servers to be 2.1.0: update them from the panel (Settings, Updates) after the panel.

Added

• The panel can connect to a server across a GRE link. Add server, The panel connects to
  it has Across a GRE link: type the new server's public IPv4 address, and the panel makes a
  GRE link to it (its own end at once; the code carries the other) and dials the server's private
  address on the link. Edit has the same choice for a server the panel connects to: one of the
  links it has with the panel's server, or a new one. A code for a server the panel dials across
  a link carries the link, so the agent makes it again before it listens; such a link cannot be
  removed while the panel uses it. API: gre: {ip, network} in POST /api/servers/join-reverse
  and POST /api/servers/reconnect.
• Benchmark: which transport gets through best between two servers. In the wizard's Kind
  step and on every tunnel's page. In about 20 seconds, without making a tunnel, it tries every
  transport in both directions (and across a GRE link between the two, if there is one) on the
  tunnel's port, measures the speed of the best three, and scores each from 0 to 100 (speed,
  latency, stability; weighted by the profile). It recommends one with the reason, ranks the
  others, explains what did not get through, and says when a direction is blocked. Use this
  fills the wizard in; Edit with this opens a tunnel's edit page with it. The last result of
  each pair is kept. Core: kariz::bench (test links over any tunnel transport, measured like
  the speed test). Agents: BenchListen and BenchDial. API: POST /api/bench,
  GET /api/bench?id=, POST /api/bench/stop, GET /api/bench/last.

Changed

• A clearer panel, after a UX review (heuristics, error states, accessibility, wording):
  • The tunnel filters show their counts as badges. In Persian, "· ۱" read as "۱۰" (the Persian
    zero is a dot); the same separator next to Persian digits elsewhere is now a short line.
  • Latin names in the Persian layout are cut at their end ("iran-…") instead of losing their
    first letters, the table keeps room for a tunnel's name and its two servers, and on a narrow
    window the switches are never cut off.
  • The tunnel wizard names the tunnel after its two servers until you type a name, and says what
    is missing (the servers, an empty name, a name in use) next to the field, which it focuses.
  • Screen readers hear the top bar, the navigation and the command palette in the panel's
    language; the copy button says Copy (and Copied after), and a copy that fails says so.
  • Every page names itself in the browser tab ("iran-eu — Tunnels — Kariz").
  • The log level filter says All levels, and Follow explains itself; the Persian settings
    say دستگاه‌های واردشده instead of mixing in "session", and "@Botfather" keeps its direction.

Fixed

• Getting a certificate for a wss tunnel on a server set up with an older Kariz. An update
  swaps the programs but not the manager script, so a server installed before tunnel-cert
  answered with its usage text ("certificate not obtained: ... Set GITHUB_TOKEN ..."). The panel
  and the agent now carry the manager of their own release and put it in place (in
  /usr/local/bin/kariz-manager) before they ask it for a certificate.

Kariz v2.0.0

A new major version: servers can now join three ways (over the internet, over a GRE link alone,
or with the panel connecting to them), and join codes and agent settings gain fields that older
agents do not know. Panels update to it only when you confirm (Settings, Updates); update the
agents from the panel after it.

Added

• Add a server over GRE alone. Add server asks how the new server reaches the panel: Over
  the internet (as before) or Over a GRE link, for a server that can reach the panel's server
  only over GRE. Type its public IPv4 address and the panel lists the server (waiting for its
  agent), gives the link a /30 of a private network (it makes kariz, 10.77.0.0/16, when
  there is none) and makes its own end of the GRE link at once; the join code carries the other
  end, which the agent makes before it dials the panel's private address across it. New command
  on the waiting server's card makes another code, Remove undoes it all. A reconnect code through
  the panel's GRE address carries the link too, so an agent that lost it can make it again. New
  API: POST /api/servers/join-gre; GET /api/servers/panel-addresses has gre_local. A server
  whose agent never connected raises no server down alert.
• The panel can connect to a server (reverse). For a server that cannot reach the panel but that
  the panel can reach, Add server has a third way, The panel connects to it: type its address
  and a port, run the command on it, and its agent listens there (the same four transports as a
  panel's agents port, on the port and the next) while the panel dials it and keeps the link up,
  trying again by itself when it drops. The agent proves who it is as always; one that turns out
  to be another server is let go. Reconnect and Edit can switch a server either way
  (Who makes the connection). It works on a panel that takes no agents, and backups keep where
  the panel dials each server. New API: POST /api/servers/join-reverse, reverse in
  POST /api/servers/reconnect and in GET /api/servers; agents get listen in agent.toml.

Fixed

• A wss tunnel with a Let's Encrypt certificate failed with BadCertificate when the dialing
  side checked the certificate against another name than the one it was issued for: a server name
  typed while Self-signed was chosen, a WebSocket Host, or a dial address that is not the
  certificate's (a private GRE address, for one). The dialing side now always checks it against
  the certificate's own domain or address, and a failed tunnel shows the dialing side's error with
  a word on what to do.

Kariz v1.9.6

Added

• A server's agent can reach the panel through a private (GRE) network. Edit and Reconnect on
  a server that has a GRE link to the panel's own server offer the panel's address on the link
  (GRE · network) beside the public ones, and choose it for a server whose agent already comes in
  that way; Add server lists the panel's GRE addresses too. A server whose agent comes through a
  link shows via GRE, and that link cannot be deleted while the agent depends on it (the panel
  would lose the only way it has to ask that server anything). GET /api/servers/panel-addresses
  has the new gre list and GET /api/servers a gre field.