$man ddos
This community gets flooded.
It’s not your fault. So our network is built for that. You keep the nick. The bot keeps ops. Your bouncer stays online. We keep the ugly traffic on our side of the fence.
Unfortunately, IRC still attracts stupid people who solve arguments with packets. Channel wars, bored script kids — the reasons are old and they do not need a diagram. If your bot is the one holding +o, someone will eventually try to knock the host over. Fortunately, we are not that host.
Protection is not a footnote. It is why a shell here is different from a random VPS that is “fine until it is not.” We’ve seen every packet known to man thrown at us. You should not have to learn our internals to stay connected. And we’re not going to tell the bad guys how we do it. We’ve been doing this since 1998 for a reason. And we’re not stopping anytime soon.
No invented throughput numbers. No cartoon of a hooded figure. If you need a specific capacity conversation, ask and bring real requirements.
$in front, not after
The attack is aimed at the nick, the vhost, or the listener. Scrubbing happens on the way in. Your session should not be the thing that notices first.
$./network
Both families
Some nets still stare at IPv4. Some of us prefer the long addresses. You are not stuck in 2004, and you are not forced off v4 either.
More than one path
A single uplink is how you discover your ISP’s incident X feed. We do not run a hobby rack behind one cable. We have a few of them ;)
NVMe boxes
Disk that keeps up with logs, userfiles, and the compile you should have done yesterday. Not a drive that’s about to fall off the spindle.
$./tunnels
Smallest tool that solves the job. A tunnel is usually enough. A VPN is usually vanity.
SSH port forwarding
SSH -L / -R / -D on a real account. Tunnels, SOCKS, tmux. Not a VPN brochure.
TCP / SSL proxies
Port X to port Y, optionally with TLS. If the binary is there. SSH -D first.
WireGuard
A shell is not a VPN SKU. One peer, small AllowedIPs, ask before you become an exit.