The built-in reverse proxy keeps picking up new capabilities. v0.65 shipped the proxy itself, v0.66 added the command , and v0.67 extended it with Layer 4 support plus geo and IP access rules. The common thread is giving you a single place to control who reaches your services, without cobbling together a separate ingress stack.
v0.69 continues that path with CrowdSec IP reputation integration, so your reverse proxy can automatically block traffic from known-malicious IPs before it touches your backends. On top of that, this release improves macOS P2P connectivity, adds PCP protocol support, and ships a handful of client and management fixes.
CrowdSec is an open-source collaborative security engine that maintains a crowdsourced list of malicious IP addresses. Think of it as a community-driven threat feed, with decisions flowing both from the global network and from local detections running against your own services.
With v0.69, you can now run a CrowdSec Local API (LAPI) alongside your reverse proxy and have the proxy check every incoming request against its decision list. Traffic from IPs flagged as malicious gets blocked at the edge, before the request ever reaches your application.
The integration ships with three operating modes so you can roll it out carefully:
| Mode | What It Does | When to Use |
|---|---|---|
| Off | CrowdSec checks are disabled | Default starting point |
| Observe | Decisions are logged but traffic is allowed through | Evaluate impact before enforcing |
| Enforce | Malicious traffic is blocked | Production use once you've validated observe mode |
With observe-mode you can watch access logs and see which requests would have been blocked, giving you a chance to catch false positives against legitimate traffic you care about. Observe-mode verdicts show up in the reverse proxy event log in the dashboard, tagged with an observe-mode badge and the decision type. They don't appear in the CrowdSec Console, which tracks the aggregate community feed rather than which of your requests the bouncer was consulted on.
One thing worth knowing about enforce mode: the proxy fails closed during the bouncer's initial decision sync, so connections are denied until the cache is populated. After that, the lookup happens in memory on every connection, so checks stay on the hot path without adding a network round trip.
CrowdSec sits alongside the CIDR and country-based access rules that shipped in v0.67 . The proxy evaluates restrictions in a defined order, so you can stack them without surprises, CIDR and country allow/deny first, then CrowdSec reputation checks. This lets you maintain your own business rules while layering in reputation data on top.
Access logs now include CrowdSec deny reasons, surfaced as , , or depending on the underlying decision type. The proxy treats all three as a denial, there's no captcha challenge or rate limiting at the proxy layer, but the specific reason is preserved in the log so you can tell at a glance whether a block came from your rules or from the reputation feed.
This feature requires self-hosted installations to add another container to the deployment. The self-hosted setup script has been updated with a CrowdSec LAPI container out of the box, so new installs get this for free. For existing deployments, there's a new Step 7 in the Enable Reverse Proxy migration guide that walks through the full setup, and the new CrowdSec IP Reputation reference page covers how the integration works day to day, optional enrollment with the CrowdSec Console, and a self-test for verifying end-to-end enforcement.
Do note that CrowdSec support for Cloud users is coming soon. If you're on Cloud, hold tight.
For full configuration details including decision types and restriction evaluation, see the authentication and access restrictions documentation .
macOS has always been a bit of a special case when it comes to routing, and some of the older approaches the client used could cause loops or prevent tunnel access to a remote peer's local addresses.
v0.69 replaces the old exclusion routes with a scoped default route combined with . In practice, this means the client no longer adds routes for every remote candidate address, which removes limitations on reaching a remote peer's local addresses through the tunnel.
If you need the old behavior for any reason, you can flip it back with a service env var:
More context on the change is in PR #5918 .
NAT traversal is a game of trying every trick you've got. v0.69 adds PCP (Port Control Protocol) support to the client, which joins the existing NAT-PMP and UPnP methods for requesting port mappings from your router.
More techniques means more peers able to establish direct P2P connections instead of falling back to relay. For networks where PCP is the only supported protocol, this is a meaningful connectivity improvement. See PR #5219 for the implementation details.
For setups where you want to pin a client to specific networks and prevent users from switching, v0.69 adds a flag. When set, the client blocks network selection at the UI and CLI level.
This is the kind of thing that matters for managed deployments where a device should always stay on the network assigned by policy. See PR #5896 .
Small quality-of-life improvement on the proxy: services can now redirect directly to SSO instead of showing an intermediate page. One fewer click between your users and the thing they're trying to reach. See PR #5874 .
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。