作者归档：softsim

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
	chain input {
		type filter hook input priority filter;
	}
	chain forward {
		type filter hook forward priority filter;
	}
	chain output {
		type filter hook output priority filter;
	}
}

默认是关闭的

systemctl status  nftables
○ nftables.service - nftables
     Loaded: loaded (/lib/systemd/system/nftables.service; disabled; preset: enabled)
     Active: inactive (dead)

启用它
systemctl enable nftables
systemctl start nftables

iptables的缺点

iptables框架在内核态知道的太多，以至于产生了大量的代码冗余。
iptables的rule结构设计不合理。

检查命令行规则集

 nft list ruleset

列出所有的表

nft list tables

Phantun

发表评论

https://www.v2ex.com/t/802949
https://github.com/dndx/phantun
作者： dndx

将 UDP 流量伪装成 TCP 流量的主流工具是 udp2raw

Phantun 的目标不是为了替代 udp2raw，从一开始 Phantun 就希望设计足够的简单高效，所以 udp2raw 支持的 ICMP 隧道，加密，防止重放等等功能 Phantun 都选择不实现。

Phantun 假设 UDP 协议本身已经解决了这些问题，所以整个转发过程就是简单的明文换头加上一些必要的 TCP 状态控制信息。对于我日常使用的 WireGuard 来说，Phantun 这种设计是足够安全的，因为 WireGuard 的协议已经更好的实现了这些安全功能。

Phantun 使用 TUN 接口来收发 3 层数据包，udp2raw 使用 Raw Socket + BFP 过滤器。个人感觉基于 TUN 的实现要稍微的优雅一点，而且跨平台移植也要更容易。

Phantun 的 TCP 连接是按需创建的，只启动 Client 不会主动去连接服务器，需要第一个数据包到达了后才会按需创建。每个 UDP 流都有自己独立的 TCP 连接。这一点跟 udp2raw 很不一样，udp2raw 所有的 UDP 连接共用一个 TCP 连接。这样做的坏处就是 udp2raw 需要额外的头部信息来区分连接，更加增加了头部的开销。跟纯 UDP 比较，Phantun 每个数据包的额外头部开销是 12 byte，udp2raw 根据我的测试达到了 44 bytes 。

https://icloudnative.io/posts/wireguard-over-tcp-using-phantun/

https://icloudnative.io/posts/custom-derp-servers/

0. 编译
… 过程省略 .. 参考 rust 相关帖子

1. 在服务器上配置，运行

设置转发
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4567 -j DNAT --to-destination 192.168.201.2

运行

RUST_LOG=info  ./server --local 4567 --remote 127.0.0.1:1234
 INFO  server > Remote address is: 127.0.0.1:1234
 INFO  server > 1 cores available
 INFO  server > Created TUN device tun0
 INFO  server > Listening on 4567

创建tun

tun0
    inet 192.168.201.1 peer 192.168.201.2/32 scope global tun0

让第三方的 UDP 服务，监听在 127.0.0.1的1234 端口

2. 客户端配置，运行

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

运行
RUST_LOG=info ./client --local 127.0.0.1:1234 --remote server_ip:4567

监听在本地的 127.0.0.1的1234端口

第3方客户端，直接连接到 127.0.0.1:1234 就相当于连接到远程的UDP服务

建立一个tun0

tun0: 
    inet 192.168.200.1 peer 192.168.200.2/32 scope global tun0

phantun监听在本地的 127.0.0.1:1234 UDP, 同时创建了一个 tun0设备， tun0设备的本端ip为 192.168.200.1, 对端ip为
192.168.200.2
来自于 123 udp端口的的数据，都被以 192.168.200.2的IP, 连接到 server_ip:4567 用tcp发送出去

但这个tcp连接，又被 iptable改写了源地址，从 192.168.200.2 改成了客户端自己的主机地址

3. 测试程序

#!/usr/bin/env python 

 
import socket 
import sys 
import argparse 
from time     import sleep
 
host = '127.0.0.1' 
payload_size = 2048 
 
def echo_server(peer,  bind_port, to_port): 
    sock = socket.socket(socket.AF_INET,  socket.SOCK_DGRAM) 
    server_address = (host, bind_port) 
    print ("Starting up echo server on %s port %s" % server_address) 
    sock.bind(server_address) 
    sock.settimeout(5.0)
    
    index = 1
 
    while True: 
        try:
            print ("Waiting to receive message  from client") 
            data, address = sock.recvfrom(payload_size) 
         
            print ("received %s bytes from %s" % (len(data), address)) 
            print ("Data: %s" %data) 
         
            if data: 
                #data = b'###...' + data + b'...###'
                data = b'### %i' % index
                sent = sock.sendto(data, address) 
                print ("sent %s bytes back to %s" % (sent, address))
                index = index + 1
                sleep(1)
        except socket.timeout:
            #addr = (peer, to_port)
            #data = b'count %i' % index
            #sent = sock.sendto(data, addr) 
            #print ("sent %s bytes hello to %s" % (sent, addr)) 
            index = index + 1
 
 
if __name__ == '__main__': 
    parser = argparse.ArgumentParser(description='Socket Server Example') 
    parser.add_argument('--host', action="store", dest="host", type=str, required=True)     
    parser.add_argument('--bind', action="store", dest="bind_port", type=int, required=True) 
    parser.add_argument('--to', action="store", dest="to_port", type=int, required=True) 
        
    given_args = parser.parse_args()
    peer = given_args.host    
    local_port = given_args.bind_port
    remote_port = given_args.to_port    
 
    
    echo_server(peer, local_port, remote_port)

在服务端运行

python3 ttt_echo_server.py  --host  cliet_peer_ip  --bind  1234  --to 9999

监听在udp的1234端口

在客户端运行

python3 ttt_echo_server.py --host 127.0.0.1 --bind 9999 --to 1234

它会往本地 127.0.0.1 的1234 udp端口发送数据，从而fake tcp转发给服务器

INFO fake_tcp > Sent SYN to server
INFO fake_tcp > Connection to 111.222.333.444:4567 established

4. 关于MTU
WireGuard MTU = Interface MTU – IPv4 header (20 bytes) – TCP header (20 bytes) – WireGuard overhead (32 bytes)
IPv4: 1500 – 20 – 20 – 32 = 1428
phantun作者介绍的，应该这么算，但我实际设置为 1480 也是通的

he tb ipv6后

ping -c 2  -M do  -4    -s  1364    10.0.0.1

ipv4 直连 (MTU居然只有1400）

ping   -c 2  -M do  -4    -s  1372  server_public_ip
1372(1400)

ipv4 udp wireguard直连

ping -c 2  -M do  -4    -s  1452    10.0.0.1

1452(1480)

ipv4 tcp wireguard

 ping -c 2  -M do  -4    -s  1396    10.0.0.1

实际浪费56个字节

IPV4 20
IPCP 16

Usually the MTU of most networks is 1500. So the MTU of IPv6 tunnel should be 1480 by removing the 20 bytes IPv4 header. To set a proper MTU that neither cause IPv6 packet be truncated nor be too small for IPv6, You’d better find the IPv4 MTU from you to your tunnel relay server by your self and set the IPv6 MTU by minus 20 bytes.

5. 几个坑点
（1）在服务器上，如果运行的是

./server --local 4567 --remote 127.0.0.1:1234

也就是转发给 127.0.0.1:1234 这个 udp监听端口，必须严格监听在 127.0.0.1:1234
监听在 0.0.0.0:1234 是不能正常工作的
（2）客户端， iptable命令的出口网卡名字必须正确指定

iptables  -t nat -A POSTROUTING -o br0  -j MASQUERADE

如果用了网桥，必须设置为网桥的名字

cjdns

发表评论

https://github.com/cjdelisle/cjdns

UDP协议

编译需要rust和nodejs环境

cd /opt
git clone https://github.com/cjdelisle/cjdns.git
cd cjdns
./do
ln -s /opt/cjdns/cjdroute /usr/bin
(umask 077 && ./cjdroute --genconf > /etc/cjdroute.conf)
cp contrib/systemd/*.service /etc/systemd/system/
systemctl enable cjdns
systemctl start cjdns

yggdrasil

发表评论

https://github.com/yggdrasil-network/public-peers
https://github.com/yggdrasil-network/yggdrasil-android
https://github.com/yggdrasil-network/crispa-android

vpncloud

发表评论

https://vpncloud.ddswd.de/
https://github.com/dswd/vpncloud/

VpnCloud 是基于 UDP 的高性能点对点网状 VPN，支持强大的加密、NAT 穿越和简单的配置。它以基于椭圆曲线密钥和 AES-256 的强大端到端加密的对等方式建立全网状自愈 VPN 网络。 VpnCloud 在主机上创建一个虚拟网络接口，并通过 UDP 将所有接收到的数据转发到目的地。它可以在 TUN 设备（基于 IP）和 TAP 设备（基于以太网）上工作

Rust开发的

最大缺点是没有Android 客户
Tinc, Nebula, Wireguard 都有

Tinc uses UDP and TCP for connections. There is no option to only use the more efficient UDP.

Tinc requires users to create a key pair for each node and then exchange the public keys with all other nodes.

Nebula has a centralized take on security: It introduces a central authority that issues certificates for all nodes. The certificates also contain an allowed IP address, that will be enforced by other nodes. Nebula supports two symmetric ciphers (AES256 and ChaCha20) but the cipher has to be the same for the whole network.

Wireguard achieves its high throughput because it uses a kernel module to do the heavy lifting.

Tinc

发表评论

Tinc

https://www.tinc-vpn.org/
https://github.com/gsliepen/tinc

nebula vpn

发表评论

https://github.com/slackhq/nebula
https://github.com/DefinedNet/mobile_nebula

Nebula is a scalable overlay networking tool with a focus on performance, simplicity and security. It lets you seamlessly connect computers anywhere in the world. Nebula is portable, and runs on Linux, OSX, Windows, iOS, and Android. It can be used to connect a small number of computers, but is also able to connect tens of thousands of computers.

Configure Nebula VPN on iOS/Android
https://willhbr.net/2021/06/22/configure-nebula-vpn-on-ios-android/

VPN mesh with Nebula
https://linuxblog.xyz/posts/slack-nebula/

在debian中安装 nebula-lighthouse-service 灯塔服务

UDP/noiseprotocol协议

软sim卡

基于高通/联发科技/紫光展锐等平台的softsim

作者归档：softsim

tailscale

tuic

在服务器上禁止对某地区的outbound流量

nftables

Phantun

cjdns

yggdrasil

vpncloud

Tinc

nebula vpn