我的“标准解决方案”使用socat作为用户空间重定向器:

socat tcp6-listen:80,fork tcp6:8080

注意，这不会扩展，分叉是昂贵的，但这是socat工作的方式。

另外两种简单的可能性:Daemon和Proxy

守护进程

对于“一个绑定在低端口上的守护进程并将控制权交给您的守护进程”，有一个旧的(不流行的)解决方案。它被称为inetd(或xinetd)。

缺点是:

你的守护进程需要在stdin/stdout上对话(如果你不控制守护进程——如果你没有源代码——那么这可能是一个showstopper，尽管一些服务可能有inetd兼容性标志) 每个连接都会生成一个新的守护进程 这是链条上的一环

优点:

可以在任何旧的UNIX上使用 一旦系统管理员设置了配置，就可以开始开发了(当重新构建守护进程时，可能会失去setcap功能吗?然后你就得回到你的管理员那里，“请，先生……”) Daemon不需要担心网络的问题，只需要在stdin/stdout上进行对话 是否可以按照请求配置为以非根用户执行守护进程

代理

另一种替代方案:从特权端口到任意高编号端口(您可以在其中运行目标守护进程)的经过修改的代理(netcat或更健壮的代理)。(Netcat显然不是一个生产解决方案，但“只是我的开发盒”，对吧?)通过这种方式，您可以继续使用服务器的网络支持版本，只需要root/sudo启动代理(在引导时)，而不依赖复杂/潜在的脆弱功能。

您可以进行端口重定向。这就是我为运行在Linux机器上的Silverlight策略服务器所做的工作

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300

Systemd是一个sysvinit的替代品，它有一个选项来启动具有特定功能的守护进程。Options Capabilities=， CapabilityBoundingSet= in system .exec(5) manpage。

在启动时:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

然后可以绑定到您转发的端口。

TLDR:对于“答案”(如我所见)，跳到这个答案中的>>TLDR<<部分。

好吧，我已经想明白了(这次是真的)，这个问题的答案，我的这个答案也是一种道歉的方式，因为我推广了另一个我认为是“最好的”的答案(在这里和推特上)，但在尝试之后，发现我错了。孩子们，从我的错误中吸取教训吧:在你自己真正尝试过之前，不要推销任何东西!

我在这里复习了所有的答案。我已经尝试了其中的一些(而选择不尝试其他的，因为我不喜欢这些解决方案)。我认为解决方案是使用systemd及其Capabilities=和capactiesbindingset = settings。在思考了一段时间后，我发现这不是解决方案，因为:

功能旨在限制根进程!

正如OP所明智地指出的那样，最好避免这种情况(如果可能的话，对于所有守护进程!)。

You cannot use the Capabilities related options with User= and Group= in systemd unit files, because capabilities are ALWAYS reset when execev (or whatever the function is) is called. In other words, when systemd forks and drops its perms, the capabilities are reset. There is no way around this, and all that binding logic in the kernel is basic around uid=0, not capabilities. This means that it is unlikely that Capabilities will ever be the right answer to this question (at least any time soon). Incidentally, setcap, as others have mentioned, is not a solution. It didn't work for me, it doesn't work nicely with scripts, and those are reset anyways whenever the file changes.

在我微薄的辩护中，我确实说过(在我现在删除的评论中)，詹姆斯的iptables建议(OP也提到了)是“第二优解决方案”。: - p

> > TLDR < <

解决方案是将systemd与动态iptables命令结合起来，就像这样(取自DNSChain):

[Unit]
Description=dnschain
After=network.target
Wants=namecoin.service

[Service]
ExecStart=/usr/local/bin/dnschain
Environment=DNSCHAIN_SYSD_VER=0.0.1
PermissionsStartOnly=true
ExecStartPre=/sbin/sysctl -w net.ipv4.ip_forward=1
ExecStartPre=-/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=-/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStartPre=/sbin/iptables -A INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=/sbin/iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStopPost=/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStopPost=/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
User=dns
Group=dns
Restart=always
RestartSec=5
WorkingDirectory=/home/dns
PrivateTmp=true
NoNewPrivileges=true
ReadOnlyDirectories=/etc

# Unfortunately, capabilities are basically worthless because they're designed to restrict root daemons. Instead, we use iptables to listen on privileged ports.
# Capabilities=cap_net_bind_service+pei
# SecureBits=keep-caps

[Install]
WantedBy=multi-user.target

在这里，我们完成了以下工作:

守护进程侦听5333，但是由于iptables，连接成功地在53上被接受 我们可以将命令包含在单元文件本身中，从而为人们省去了麻烦。Systemd为我们清理防火墙规则，确保在守护进程未运行时删除它们。 我们从不以根用户身份运行，并且使特权升级成为不可能(至少systemd声称是这样)，即使守护进程被破坏并设置uid=0。

不幸的是，Iptables仍然是一个相当丑陋且难以使用的实用工具。例如，如果守护进程正在侦听eth0:0而不是eth0，则命令略有不同。