net: exempt loopback from the per-IP connection cap

Review follow-up. A managed-Tor node receives every inbound onion peer
over its local hidden-service listener, so they all accept as 127.0.0.1.
Capping loopback would cap onion peers as one group and refuse the 33rd
legitimate onion peer -- the wrong limit for a network moving toward
onion-only. Exempt loopback (127.0.0.0/8): the global MAX_CONNECTIONS
still bounds the total, and the direct-IP flood this defends against
never arrives over loopback.

Bench: a 40-connection flood from 127.0.0.1 is now held in full (no
per-IP refusal), while a flood from the machine's LAN address still caps
at exactly 32.

1 files changed, 8 insertions, 0 deletions

diff --git a/src/net.h b/src/net.h
index 4fdd1b3..e3d4a93 100644
--- a/src/net.h
+++ b/src/net.h
@@ -119,6 +119,14 @@ static const unsigned int MAX_CONNECTIONS = 125;
 // needs only a handful; 32 leaves generous room while denying any one address
 // more than a quarter of the table. The firewall connlimit on the relays does
 // the same thing a layer lower; this makes every build carry the defense.
+//
+// Loopback (127.0.0.0/8) is exempt in the accept path. A managed-Tor node
+// receives every inbound onion peer over its local hidden-service listener, so
+// they all appear as 127.0.0.1 -- capping loopback would cap onion peers as a
+// group, which is exactly wrong for a network moving toward onion-only. The
+// global MAX_CONNECTIONS still bounds the total; a per-onion-identity limit,
+// applied once identity is known after accept(), is the right future tool for
+// onion floods.
 static const unsigned int MAX_CONNECTIONS_PER_IP = 32;
 
 // A node marked for disconnect is normally held until its buffers drain, so