ipipou: 단순한 암호화되지 않은 터널 그 이상

IPv6의 신에게 우리는 무엇을 말하고 있습니까?

맞습니다. 오늘은 암호화의 신에게도 똑같이 말하겠습니다.

여기서는 암호화되지 않은 IPv4 터널에 대해 설명하지만 "따뜻한 램프" 터널이 아니라 최신 "LED" 터널에 대해 설명합니다. 그리고 여기에는 원시 소켓이 깜박이고 사용자 공간에서 패킷 작업이 진행 중입니다.

모든 취향과 색상에 맞는 N개의 터널링 프로토콜이 있습니다.

• 스타일리시한, 패셔너블한, 젊음 와이어 가드
• Swiss Knife, OpenVPN 및 SSH와 같은 다기능
• 오래되고 사악하지 않은 GRE
• 가장 간단하고 빠르며 완전히 암호화되지 않은 IPIP
• 적극적으로 발전 제네바
• 많은 다른 사람.

하지만 나는 프로그래머이기 때문에 N을 아주 조금만 늘리고 실제 프로토콜 개발은 Kommersant 개발자에게 맡길 것입니다.

아직 태어나지 않은 한 사람에게서 프로젝트지금 제가 하고 있는 일은 외부에서 NAT 뒤의 호스트에 접근하는 것입니다. 이를 위해 성인용 암호화 프로토콜을 사용하면 마치 대포에서 참새를 쏘는 듯한 느낌을 지울 수 없었다. 왜냐하면 터널은 대부분 NAT-e에 구멍을 뚫는 데에만 사용되며 내부 트래픽도 일반적으로 암호화되지만 여전히 HTTPS에 빠져 있습니다.

다양한 터널링 프로토콜을 연구하는 동안 내 내면의 완벽주의자의 관심은 최소한의 오버헤드로 인해 계속해서 IPIP에 끌렸습니다. 하지만 내 작업에는 한 가지 중요한 단점이 있습니다.

• 양쪽 모두 공용 IP가 필요합니다.
• 그리고 당신에 대한 인증은 없습니다.

그러므로 완벽주의자는 두개골의 어두운 구석이나 그가 앉는 곳으로 다시 쫓겨나게 됩니다.

그러던 어느 날, 기사를 읽다가 기본적으로 지원되는 터널 Linux에서는 FOU(Foo-over-UDP)를 발견했습니다. 무엇이든 UDP로 포장되었습니다. 지금까지는 IPIP와 GUE(Generic UDP Encapsulation)만 지원됩니다.

“여기에 은총알이 있습니다! 저는 간단한 IPIP면 충분합니다.” - 나는 생각했다.

실제로 총알은 완전한 은이 아닌 것으로 밝혀졌습니다. UDP의 캡슐화는 첫 번째 문제를 해결합니다. 미리 설정된 연결을 사용하여 외부에서 NAT 뒤의 클라이언트에 연결할 수 있지만 여기서는 IPIP의 다음 단점 중 절반이 새로운 시각으로 드러납니다. 개인 네트워크의 누구나 눈에 보이는 뒤에 숨을 수 있습니다. 공용 IP 및 클라이언트 포트(순수 IPIP에서는 이 문제가 존재하지 않습니다).

이 문제를 해결하기 위해 유틸리티가 탄생했습니다. 이피포. 커널 FOU의 작동을 방해하지 않고 원격 호스트를 인증하기 위한 자체 제작 메커니즘을 구현하여 커널 공간에서 패킷을 빠르고 효율적으로 처리합니다.

우리는 당신의 스크립트가 필요하지 않습니다!

좋아, 클라이언트의 공용 포트와 IP를 알고 있다면(예를 들어 뒤에 있는 모든 사람이 아무데도 가지 않고 NAT가 포트를 1-in-1로 매핑하려고 시도하는 경우) 다음을 사용하여 IPIP-over-FOU 터널을 생성할 수 있습니다. 스크립트 없이 다음 명령을 수행합니다.

서버에서:

# Подгрузить модуль ядра FOU
modprobe fou

# Создать IPIP туннель с инкапсуляцией в FOU.
# Модуль ipip подгрузится автоматически.
ip link add name ipipou0 type ipip 
    remote 198.51.100.2 local 203.0.113.1 
    encap fou encap-sport 10000 encap-dport 20001 
    mode ipip dev eth0

# Добавить порт на котором будет слушать FOU для этого туннеля
ip fou add port 10000 ipproto 4 local 203.0.113.1 dev eth0

# Назначить IP адрес туннелю
ip address add 172.28.0.0 peer 172.28.0.1 dev ipipou0

# Поднять туннель
ip link set ipipou0 up

클라이언트에서:

modprobe fou

ip link add name ipipou1 type ipip 
    remote 203.0.113.1 local 192.168.0.2 
    encap fou encap-sport 10001 encap-dport 10000 encap-csum 
    mode ipip dev eth0

# Опции local, peer, peer_port, dev могут не поддерживаться старыми ядрами, можно их опустить.
# peer и peer_port используются для создания соединения сразу при создании FOU-listener-а.
ip fou add port 10001 ipproto 4 local 192.168.0.2 peer 203.0.113.1 peer_port 10000 dev eth0

ip address add 172.28.0.1 peer 172.28.0.0 dev ipipou1

ip link set ipipou1 up

어디에서

• ipipou* — 로컬 터널 네트워크 인터페이스의 이름
• 203.0.113.1 — 공용 IP 서버
• 198.51.100.2 — 클라이언트의 공개 IP
• 192.168.0.2 — 인터페이스 eth0에 할당된 클라이언트 IP
• 10001 — FOU용 로컬 클라이언트 포트
• 20001 — FOU용 공개 클라이언트 포트
• 10000 — FOU용 공용 서버 포트
• encap-csum — 캡슐화된 UDP 패킷에 UDP 체크섬을 추가하는 옵션; 로 대체될 수 있다 noencap-csum, 말할 것도 없이 무결성은 이미 외부 캡슐화 계층에 의해 제어됩니다(패킷이 터널 내부에 있는 동안).
• eth0 — ipip 터널이 바인딩될 로컬 인터페이스
• 172.28.0.1 — 클라이언트 터널 인터페이스의 IP(비공개)
• 172.28.0.0 — IP 터널 서버 인터페이스(비공개)

UDP 연결이 살아 있는 한 터널은 정상적으로 작동하지만 터널이 끊어지면 운이 좋을 것입니다. 클라이언트의 IP: 포트가 동일하게 유지되면 작동하고 변경되면 끊어집니다.

모든 것을 되돌리는 가장 쉬운 방법은 커널 모듈을 언로드하는 것입니다. modprobe -r fou ipip

인증이 필요하지 않더라도 클라이언트의 공용 IP 및 포트는 항상 알려져 있지 않으며 예측할 수 없거나 가변적인 경우가 많습니다(NAT 유형에 따라 다름). 생략하는 경우 encap-dport 서버 측에서는 터널이 작동하지 않으며 원격 연결 포트를 사용할 만큼 똑똑하지 않습니다. 이 경우 ipipou도 도움이 될 수 있으며, WireGuard 및 이와 유사한 다른 제품도 도움이 될 수 있습니다.

어떻게 작동합니까?

일반적으로 NAT 뒤에 있는 클라이언트는 위의 예와 같이 터널을 열고 서버 측에 터널을 구성하도록 인증 패킷을 서버에 보냅니다. 설정에 따라 이는 빈 패킷일 수도 있고(서버가 공용 IP: 연결 포트를 볼 수 있도록 하기 위함) 서버가 클라이언트를 식별할 수 있는 데이터가 포함될 수도 있습니다. 데이터는 일반 텍스트의 간단한 암호(HTTP 기본 인증과 유사함)이거나 개인 키로 서명된 특별히 설계된 데이터(HTTP 다이제스트 인증과 유사하며 더 강력함, 기능 참조)일 수 있습니다. client_auth 코드에서).

서버(공용 IP가 있는 쪽)에서 ipipou가 시작되면 nfqueue 대기열 핸들러를 생성하고 필요한 패킷이 있어야 할 위치로 전송되도록 netfilter를 구성합니다. 패킷은 nfqueue 대기열에 대한 연결을 초기화하고 [거의] 나머지는 모두 청취자 FOU로 바로 전달됩니다.

잘 모르는 사람들을 위해 설명하자면, nfqueue(또는 NetfilterQueue)는 커널 모듈 개발 방법을 모르는 아마추어를 위한 특별한 것입니다. netfilter(nftables/iptables)를 사용하면 네트워크 패킷을 사용자 공간으로 리디렉션하고 이를 처리할 수 있습니다. 기본 수단은 수정(선택 사항)하여 커널에 다시 제공하거나 폐기하는 것입니다.

일부 프로그래밍 언어에는 nfqueue 작업을 위한 바인딩이 있지만 bash에는 아무것도 없었습니다(흥, 놀랍지도 않습니다). Python을 사용해야 했습니다. ipipou는 다음을 사용합니다. 넷필터큐.

성능이 중요하지 않은 경우 이 기능을 사용하면 실험적인 데이터 전송 프로토콜을 만들거나 비표준 동작으로 로컬 및 원격 서비스를 트롤링하는 등 상당히 낮은 수준에서 패킷 작업을 위한 자체 논리를 상대적으로 빠르고 쉽게 만들 수 있습니다.

원시 소켓은 nfqueue와 함께 작동합니다. 예를 들어 터널이 이미 구성되어 있고 FOU가 원하는 포트에서 수신 대기 중인 경우 일반적인 방법으로 동일한 포트에서 패킷을 보낼 수 없습니다. 사용 중이지만 무작위로 생성된 패킷을 원시 소켓을 사용하여 네트워크 인터페이스로 직접 가져와 보낼 수 있습니다. 하지만 이러한 패킷을 생성하려면 약간의 수정이 필요합니다. 이것이 ipipou에서 인증이 포함된 패킷이 생성되는 방식입니다.

ipipou는 연결의 첫 번째 패킷(및 연결이 설정되기 전에 대기열로 누출된 패킷)만 처리하므로 성능이 거의 저하되지 않습니다.

ipipou 서버가 인증된 패킷을 수신하자마자 터널이 생성되고 연결의 모든 후속 패킷은 이미 nfqueue를 우회하는 커널에 의해 처리됩니다. 연결이 실패하면 설정에 따라 다음 패킷의 첫 번째 패킷이 nfqueue 대기열로 전송됩니다. 인증된 패킷이 아닌 경우 마지막으로 기억된 IP 및 클라이언트 포트에서 전달될 수 있습니다. 켜거나 폐기합니다. 인증된 패킷이 새 IP 및 포트에서 오는 경우 이를 사용하도록 터널이 재구성됩니다.

일반적인 IPIP-over-FOU에는 NAT로 작업할 때 한 가지 문제가 더 있습니다. FOU와 IPIP 모듈이 서로 상당히 격리되어 있기 때문에 동일한 IP를 사용하여 UDP로 캡슐화된 두 개의 IPIP 터널을 생성하는 것은 불가능합니다. 저것들. 동일한 공용 IP 뒤에 있는 한 쌍의 클라이언트는 이런 방식으로 동일한 서버에 동시에 연결할 수 없습니다. 앞으로는, 어쩌면, 커널 수준에서 해결될 예정이지만 확실하지 않습니다. 그동안 NAT 문제는 NAT를 통해 해결할 수 있습니다. IP 주소 쌍이 이미 다른 터널에서 사용되고 있는 경우 ipipou는 공용에서 대체 개인 IP로 NAT를 수행합니다. 짜잔! - 포트가 다 떨어질 때까지 터널을 생성할 수 있습니다.

왜냐하면 연결의 모든 패킷이 서명되지 않은 경우 이 간단한 보호는 MITM에 취약하므로 트래픽을 듣고 조작할 수 있는 클라이언트와 서버 사이의 경로에 숨어 있는 악당이 있는 경우 인증된 패킷을 다음을 통해 리디렉션할 수 있습니다. 다른 주소를 사용하고 신뢰할 수 없는 호스트에서 터널을 만듭니다.

트래픽의 대부분을 코어에 남겨두면서 이 문제를 해결하는 방법에 대한 아이디어가 있는 사람이 있다면 주저하지 말고 알려주세요.

그건 그렇고, UDP의 캡슐화는 매우 잘 입증되었습니다. IP를 통한 캡슐화와 비교하면 UDP 헤더의 추가 오버헤드에도 불구하고 훨씬 더 안정적이고 더 빠른 경우가 많습니다. 이는 인터넷의 대부분의 호스트가 가장 널리 사용되는 세 가지 프로토콜인 TCP, UDP, ICMP에서만 잘 작동하기 때문입니다. 유형적인 부분은 이 세 가지에만 최적화되어 있기 때문에 다른 모든 것을 완전히 버리거나 더 느리게 처리할 수 있습니다.

예를 들어, HTTP/3의 기반이 되는 QUICK이 IP가 아닌 UDP 위에 만들어진 이유가 여기에 있습니다.

글쎄요, 이제 그것이 "실제 세계"에서 어떻게 작동하는지 알아볼 시간입니다.

전투

실제 세계를 에뮬레이트하는 데 사용됩니다. iperf3. 현실과의 친밀도 측면에서 이것은 Minecraft에서 현실 세계를 에뮬레이트하는 것과 거의 동일하지만 지금은 그렇게 할 것입니다.

대회 참가자:

• 참조 메인 채널
• 이번 글의 주인공은 이피포입니다
• 인증은 있지만 암호화는 없는 OpenVPN
• 포괄적 모드의 OpenVPN
• PresharedKey가 없는 WireGuard, MTU=1440(IPv4 전용 이후)

괴짜를 위한 기술 데이터
측정항목은 다음 명령을 사용하여 가져옵니다.

클라이언트에서:

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2 -u -b 12M; tail -1 "$CPULOG"
# Где "-b 12M" это пропускная способность основного канала, делённая на число потоков "-P", чтобы лишние пакеты не плодить и не портить производительность.

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2; tail -1 "$CPULOG"

ICMP 대기 시간

ping -c 10 SERVER_IP | tail -1

서버에서(클라이언트와 동시에 실행됨):

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

터널 구성

이피포
서버
/etc/ipipou/server.conf:

server
number 0
fou-dev eth0
fou-local-port 10000
tunl-ip 172.28.0.0
auth-remote-pubkey-b64 eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-secret topsecret
auth-lifetime 3600
reply-on-auth-ok
verb 3

systemctl start ipipou@server

클라이언트
/etc/ipipou/client.conf:

client
number 0
fou-local @eth0
fou-remote SERVER_IP:10000
tunl-ip 172.28.0.1
# pubkey of auth-key-b64: eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-key-b64 RuBZkT23na2Q4QH1xfmZCfRgSgPt5s362UPAFbecTso=
auth-secret topsecret
keepalive 27
verb 3

systemctl start ipipou@client

openvpn(암호화 없음, 인증 포함)
서버

openvpn --genkey --secret ovpn.key  # Затем надо передать ovpn.key клиенту
openvpn --dev tun1 --local SERVER_IP --port 2000 --ifconfig 172.16.17.1 172.16.17.2 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

클라이언트

openvpn --dev tun1 --local LOCAL_IP --remote SERVER_IP --port 2000 --ifconfig 172.16.17.2 172.16.17.1 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

openvpn (암호화, 인증, UDP를 통한 모든 것이 예상대로)
다음을 사용하여 구성됨 openvpn-관리

와이어 가드
서버
/etc/wireguard/server.conf:

[Interface]
Address=172.31.192.1/18
ListenPort=51820
PrivateKey=aMAG31yjt85zsVC5hn5jMskuFdF8C/LFSRYnhRGSKUQ=
MTU=1440

[Peer]
PublicKey=LyhhEIjVQPVmr/sJNdSRqTjxibsfDZ15sDuhvAQ3hVM=
AllowedIPs=172.31.192.2/32

systemctl start wg-quick@server

클라이언트
/etc/wireguard/client.conf:

[Interface]
Address=172.31.192.2/18
PrivateKey=uCluH7q2Hip5lLRSsVHc38nGKUGpZIUwGO/7k+6Ye3I=
MTU=1440

[Peer]
PublicKey=DjJRmGvhl6DWuSf1fldxNRBvqa701c0Sc7OpRr4gPXk=
AllowedIPs=172.31.192.1/32
Endpoint=SERVER_IP:51820

systemctl start wg-quick@client

조사 결과

축축하고 추한 간판
서버 CPU 로드는 그다지 지표가 되지 않습니다. 왜냐하면... 거기에는 다른 많은 서비스가 실행되고 있으며 때로는 리소스를 소모합니다.

proto bandwidth[Mbps] CPU_idle_client[%] CPU_idle_server[%]
# 20 Mbps канал с микрокомпьютера (4 core) до VPS (1 core) через Атлантику
# pure
UDP 20.4      99.80 93.34
TCP 19.2      99.67 96.68
ICMP latency min/avg/max/mdev = 198.838/198.997/199.360/0.372 ms
# ipipou
UDP 19.8      98.45 99.47
TCP 18.8      99.56 96.75
ICMP latency min/avg/max/mdev = 199.562/208.919/220.222/7.905 ms
# openvpn0 (auth only, no encryption)
UDP 19.3      99.89 72.90
TCP 16.1      95.95 88.46
ICMP latency min/avg/max/mdev = 191.631/193.538/198.724/2.520 ms
# openvpn (full encryption, auth, etc)
UDP 19.6      99.75 72.35
TCP 17.0      94.47 87.99
ICMP latency min/avg/max/mdev = 202.168/202.377/202.900/0.451 ms
# wireguard
UDP 19.3      91.60 94.78
TCP 17.2      96.76 92.87
ICMP latency min/avg/max/mdev = 217.925/223.601/230.696/3.266 ms

## около-1Gbps канал между VPS Европы и США (1 core)
# pure
UDP 729      73.40 39.93
TCP 363      96.95 90.40
ICMP latency min/avg/max/mdev = 106.867/106.994/107.126/0.066 ms
# ipipou
UDP 714      63.10 23.53
TCP 431      95.65 64.56
ICMP latency min/avg/max/mdev = 107.444/107.523/107.648/0.058 ms
# openvpn0 (auth only, no encryption)
UDP 193      17.51  1.62
TCP  12      95.45 92.80
ICMP latency min/avg/max/mdev = 107.191/107.334/107.559/0.116 ms
# wireguard
UDP 629      22.26  2.62
TCP 198      77.40 55.98
ICMP latency min/avg/max/mdev = 107.616/107.788/108.038/0.128 ms

20Mbps 채널

1개 낙관적 Gbps당 채널

모든 경우에 있어서 ipipou는 성능 면에서 기본 채널과 매우 유사하며 이는 훌륭합니다!

암호화되지 않은 openvpn 터널은 두 경우 모두 매우 이상하게 작동했습니다.

누구든지 테스트하려고 한다면 피드백을 듣는 것이 흥미로울 것입니다.

IPv6와 NetPrickle이 우리와 함께하길 바랍니다!

출처 : habr.com