ANet is a Rust VPN with its own transport protocol and a noise-shaped packet stream

A tool for trusted groups rather than a service

ANet is presented in Russian as a tool for organising a private, protected information space between people close to one another, building digital bridges where ordinary routes are not available. The next two lines set the framing clearly: this is not a service, it is a technology for connecting people who trust each other. That is a meaningful design constraint rather than marketing, because it changes what the software is trying to be. A general purpose VPN client is built to route traffic past a gatekeeper you do not control, while a tool built for a small trusted group can make different trade-offs about the protocol, the topology and the amount of infrastructure required. The project is written in Rust and split into modules, with the badge in the readme indicating Rust 1.98 or newer and a protocol badge for ASTP v0.6. The topics carried by the repository are simply rust and vpn, and the licence is recorded as a custom one that GitHub cannot classify.

ASTP is the project's own transport protocol

At the centre of the project is its own transport protocol, ASTP, the ANet Secure Transport Protocol, developed with three stated goals. Privacy is full end-to-end encryption using ChaCha20Poly1305 and X25519, and the Cargo workspace pins chacha20poly1305 at 0.10.1 and x25519-dalek at 2.0.1 with static secrets, alongside ed25519-dalek for signing and sha2 for hashing. Resilience means stable operation in networks with high packet loss and an unstable connection. And mimicry means the transport layer is indistinguishable from random noise, described as a high-entropy UDP stream. The transport underneath is quinn at 0.11.11 with rustls and the ring provider, so the QUIC layer is a known quantity and the custom part sits above it, and there is a Makefile target that generates a certificate for QUIC.

make all
make musl
make mob
make macos
make cert

The Makefile comment for that last target is a certificate generation step for QUIC, which tells you the transport is TLS over QUIC rather than something bespoke at the packet level, and the mimicry claim is about how the payload looks on the wire rather than about the whole stack.

Ten crates, and the split tells you the architecture

The Cargo workspace lists ten members and a default set of six. The modules are anet-auth, described as the coordination node, anet-server, the server itself which can run without anet-auth, anet-client-core, the client itself, anet-client-cli, a console client for Linux and headless systems, anet-client-gui, a graphical client for Windows and Linux with a minimalist interface, anet-mobile, a library with JNI bindings for Android, anet-common, which holds the ASTP protocol implementation and the cryptography, anet-keygen, a utility for generating access keys, and anet-webui, an admin panel. Two further crates sit outside that list in the repository, anet-appfilter and anet-ebpf with anet-ebpf-common, and the comments in the Cargo file explain that the eBPF traffic shaper is built and embedded into anet-server through a build script using aya-build. The presence of a separate key generation utility and of a coordination node that the server can run without is the shape of a peer-to-peer system with an optional directory.

TUN, eBPF and per-application routing on the client

The client stack shows how the traffic is handled on the host. The workspace depends on the tun crate at 0.8.5 with the async feature, which is the usual way a userspace VPN creates its virtual interface, and netdev at 0.39 with the gateway feature for manipulating routes. The appfilter crate is what makes the per-application behaviour visible in the screenshots, where the mobile client offers a window for choosing which applications to tunnel and the desktop client has a screen for excluding addresses from tunnelling, so the filtering is a first-class feature rather than a rule file. The eBPF crates add a traffic shaper at the kernel level, using aya at 0.14.0 and aya-log, which is what makes shaping possible without a userspace round trip per packet. The dependency list also carries russh at 0.62.6 for SSH, tokio-tungstenite for WebSocket transport, webrtc and rtc at 0.21.0, http at 1.3.1, reqwest, roxmltree, dashmap and prost for protobuf.

Building it is a handful of make targets

Building requires an installed Rust with cargo, and the Makefile is the front door. The all target runs a release build of the default workspace members, check runs cargo check across the workspace, test runs the workspace tests and clean removes the build artefacts. The musl target builds static Linux binaries for the server, the CLI client and the auth node with crt-static enabled for the x86_64-unknown-linux-musl target, which is what you want for a portable static binary. The mob target uses cargo ndk to build the Android library for x86_64, aarch64 and armv7, writing the results into an android-build jniLibs directory, and the separate anet-android repository holds the Android application source. The macOS targets build the CLI client and the GUI client, with a message telling you to run the client with sudo and a config file, and a universal target for Intel plus Apple Silicon. There is also an infra target that brings up a docker-compose file for the infrastructure and a win-gui target that cross-compiles the GUI for Windows.

Interfaces, documentation and the community around it

The readme carries a gallery of screenshots that maps the features rather than the code. On the Windows desktop application there are shots of the disconnected state, the connecting process, a successful connection, application management, updates, settings management, node selection and a screen for excluding addresses from tunnelling. The Android application shows the same progression plus config selection, config editing and config deletion. The web admin panel has five screens ending in a successful connection. The documentation lives in the repository under contrib/docs, with one file describing the project in Russian and another describing the AUTH HTTP API, and the readme introduces them with some bluntness, the first saying someone dashed it off and the second saying it is entirely a neural network output. There is also a Telegram channel, a donation link, a code of conduct and a changelog. A third party has packaged the project into an anet-docker repository, and the author is careful about it, saying he has not checked it personally but that it looks fine at first glance, and warning that it is not a friend and not an acquaintance, so use it at your own risk, with a discussion linked in issue 36.

Where this is the wrong choice

Three limits are worth naming. The first is the protocol risk, which is inherent rather than a flaw in the code. Writing your own transport protocol means there is no field history, no public analysis and no second implementation, and the readme is candid about the goal of making the transport indistinguishable from random noise, which is a property that is hard to verify from outside. The second is the operating requirement. The Linux and Android paths use a TUN device and an eBPF program, so the client needs elevated privileges and a kernel that supports eBPF, and the macOS instructions say to run the CLI with sudo. The third is scope. The project explicitly describes itself as not a service, which means there is no exit node, no account system and no support contract, and a user who wants to reach the public internet through someone else's machine is looking for a different tool. What the design does buy is control, since the trust boundary stays between the people in the group and the code is all in the repository.

Editorial conclusion

ANet suits a small group of people who want a private network between their own devices without handing control of the trust boundary to a third party, and it suits anyone who wants to read the whole implementation rather than configure a mainstream VPN client. It is the wrong tool if you need a solution with an audited protocol and years of field use, because a bespoke transport protocol carries the risk that comes with being the only implementation. It is also the wrong choice if you need a public exit node or commercial support, since the project describes itself as not a service. Before building it, read the protocol documentation linked from the repository and the QUIC certificate step in the Makefile, and note that the Linux and Android targets use a TUN device and eBPF, so they need privileges. The last push was on 2026-10-20 and the current release is v0.7.3 from 2026-09-10.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. ZeroTworu/anet on GitHub