iipipou: 単なる暗号化されていないトンネルではありません

IPv6 の神に何を言いたいのでしょうか?

そう、今日は暗号の神様にも同じことを言ってみよう。

ここでは、暗号化されていない IPv4 トンネルについて説明しますが、「ウォーム ランプ」トンネルではなく、最新の「LED」トンネルについて説明します。 また、ここでは生のソケットがフラッシュされており、ユーザー空間でパケットの作業が進行中です。

あらゆる好みと色に対して N 個のトンネリング プロトコルがあります。

• スタイリッシュ、ファッショナブル、若者 ワイヤガード
• スイスナイフ、OpenVPN、SSH などの多機能
• 古くて悪くないGRE
• 最もシンプル、高速、完全に暗号化されていない IPIP
• 積極的に開発中 GENEVE
• 他の多く。

ただし、私はプログラマーなので、N をほんの一部だけ増やし、実際のプロトコルの開発はコメルサントの開発者に任せます。

一人の胎児の中で プロジェクト私が今やっていることは、外部から NAT の背後にあるホストにアクセスすることです。 これに成人向け暗号を使用したプロトコルを使用すると、大砲からスズメを撃ち出すようなものであるという感覚がぬぐえませんでした。 なぜならトンネルは、ほとんどの場合、NAT-e に穴を開けるためだけに使用され、内部トラフィックも通常は暗号化されますが、それでも HTTPS に溺れます。

さまざまなトンネリング プロトコルを研究しているときに、私の内なる完璧主義者の注意は、オーバーヘッドが最小限に抑えられている IPIP に何度も引き寄せられました。 しかし、私のタスクには XNUMX つの重大な欠点があります。

• 両側にパブリック IP が必要です。
• そしてあなたに対する認証はありません。

したがって、完璧主義者は頭蓋骨の暗い隅、またはそこに座っている場所のどこにでも追いやられました。

そしてある日、次のような記事を読んでいると、 ネイティブにサポートされるトンネル Linux で FOU (Foo-over-UDP) に遭遇しました。 UDP でラップされたものは何でも。 これまでのところ、IPIP と GUE (Generic UDP Encapsulation) のみがサポートされています。

「これが特効薬だ！ 私にとっては単純な IPIP で十分です。」 -私は思いました。

実際、弾丸は完全に銀ではないことが判明した。 UDP でのカプセル化により、最初の問題が解決されます。事前に確立された接続を使用して、外部から NAT の背後にあるクライアントに接続できますが、ここで、IPIP の次の欠点の半分が新たな光を当てます。プライベート ネットワークの誰でも、目に見えるネットワークの背後に隠れることができます。パブリック IP とクライアント ポート (純粋な IPIP ではこの問題は存在しません)。

この XNUMX つ半の問題を解決するために、ユーティリティが誕生しました イピポウ。 これは、カーネル 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 サーバー側では、トンネルは機能せず、リモート接続ポートを取得するほど賢くありません。 この場合、ipipu も役立ちます。または、WireGuard やその他の同様のツールも役立ちます。

それはどのように動作しますか？

クライアント (通常は NAT の背後にあります) は、(上の例のように) トンネルを開き、サーバー側でトンネルを構成するために認証パケットをサーバーに送信します。 設定に応じて、これは空のパケット (サーバーがパブリック IP: 接続ポートを認識できるようにするため) であることも、サーバーがクライアントを識別できるデータを含むこともできます。 データは、クリア テキストの単純なパスフレーズ (HTTP 基本認証との類似が思い浮かびます) または秘密キーで署名された特別に設計されたデータ (HTTP ダイジェスト認証に似ていますが、より強力であるだけです。関数を参照) にすることができます。 client_auth コード内)。

サーバー (パブリック IP を持つ側) では、ipipou が開始されると、nfqueue キュー ハンドラーが作成され、必要なパケットが送信されるべき場所に送信されるように netfilter が設定されます。nfqueue キューへの接続を初期化するパケット、および [ほぼ] 残りはすべてリスナーの FOU に直接送信されます。

詳しくない人のために説明すると、nfqueue (または NetfilterQueue) は、カーネル モジュールの開発方法を知らないアマチュアにとって特別なものであり、netfilter (nftables/iptables) を使用すると、ネットワーク パケットをユーザー空間にリダイレクトし、そこで次のコマンドを使用して処理できます。プリミティブとは、手元にあるものを意味します: 変更 (オプション) してカーネルに戻すか、破棄します。

一部のプログラミング言語では、nfqueue を操作するためのバインディングがありますが、bash ではバインディングがありませんでした (へー、驚くべきことではありません)。Python を使用する必要がありました。 ネットフィルターキュー.

パフォーマンスが重要でない場合は、これを使用すると、かなり低いレベルでパケットを処理するための独自のロジックを比較的迅速かつ簡単に作成できます。たとえば、実験的なデータ転送プロトコルを作成したり、非標準の動作でローカルおよびリモートのサービスを荒らしたりすることができます。

Raw ソケットは nfqueue と連携して動作します。たとえば、トンネルがすでに構成されており、FOU が目的のポートでリッスンしている場合、通常の方法では同じポートからパケットを送信できません。ビジー状態ですが、 raw ソケットを使用して、ランダムに生成されたパケットを受け取ってネットワーク インターフェイスに直接送信することもできますが、そのようなパケットを生成するにはもう少し工夫が必要になります。 これは、iipou で認証付きのパケットが作成される方法です。

iipipou は接続からの最初のパケット (および接続が確立される前にキューに漏れたパケット) のみを処理するため、パフォーマンスはほとんど低下しません。

ipipou サーバーが認証されたパケットを受信するとすぐにトンネルが作成され、接続内のすべての後続のパケットは nfqueue をバイパスしてカーネルによってすでに処理されています。 接続が失敗した場合、設定に応じて、次のパケットの最初のパケットが nfqueue キューに送信されます。認証付きのパケットではなく、最後に記憶された IP およびクライアント ポートからのものであれば、送信することができます。オンまたは破棄されます。 認証されたパケットが新しい IP およびポートから送信された場合、トンネルはそれらを使用するように再構成されます。

通常の IPIP-over-FOU には、NAT を使用する場合にもう XNUMX つ問題があります。FOU と IPIP モジュールは互いに完全に分離されているため、同じ IP を持つ UDP にカプセル化された XNUMX つの IPIP トンネルを作成することは不可能です。 それらの。 同じパブリック IP の背後にある XNUMX 組のクライアントは、この方法で同時に同じサーバーに接続できません。 将来は、 多分、それはカーネルレベルで解決されますが、これは確実ではありません。 それまでの間、NAT の問題は NAT によって解決できます。IP アドレスのペアがすでに別のトンネルによって占有されている場合、ipipou はパブリック IP から代替プライベート IP への NAT を実行します。 - ポートがなくなるまでトンネルを作成できます。

なぜなら接続内のすべてのパケットが署名されているわけではないため、この単純な保護は MITM に対して脆弱であるため、クライアントとサーバーの間のパスにトラフィックをリッスンして操作できる悪者が潜んでいる場合、彼は認証されたパケットを別のアドレスを使用して、信頼できないホストからトンネルを作成します。

トラフィックの大部分をコアに残したままこ​​の問題を解決する方法についてアイデアをお持ちの方がいらっしゃいましたら、遠慮なく声を上げてください。

ところで、UDP でのカプセル化は非常にうまく証明されています。 IP 上のカプセル化と比較すると、UDP ヘッダーの追加オーバーヘッドにもかかわらず、はるかに安定しており、多くの場合高速です。 これは、インターネット上のほとんどのホストが、TCP、UDP、ICMP という XNUMX つの最も一般的なプロトコルでのみ正常に動作するという事実によるものです。 有形部分は、これら XNUMX つに対してのみ最適化されているため、他のすべてを完全に破棄するか、処理が遅くなります。

たとえば、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