VPN が、ひげを生やしたシステム管理者の珍しいツールではなくなる時代が来ました。 ユーザーのタスクはさまざまですが、VPN は誰にとっても必要なものになっているのは事実です。
現在の VPN ソリューションの問題は、適切に構成するのが難しく、維持費が高くつき、品質が疑わしいレガシー コードでいっぱいであることです。
数年前、カナダの情報セキュリティ専門家であるジェイソン A. ドネンフェルドは、もう十分だと判断し、次のような取り組みを始めました。
他の VPN ソリューションに対する WireGuard の利点は次のとおりです。
- 使いやすい。
- 最新の暗号化を使用: ノイズ プロトコル フレームワーク、Curve25519、ChaCha20、Poly1305、BLAKE2、SipHash24、HKDF など。
- コンパクトで読みやすいコードなので、脆弱性の調査が容易です。
- ハイパフォーマンス。
- クリアで精巧な作り
仕様 .
特効薬は見つかったのか? OpenVPN と IPSec を廃止する時期が来たのでしょうか? 私はこれに対処することを決めましたが、同時に、
仕事の原則
動作原理は次のように説明できます。
- WireGuard インターフェイスが作成され、秘密キーと IP アドレスが割り当てられます。 他のピアの設定 (公開キー、IP アドレスなど) がロードされます。
- WireGuard インターフェイスに到着するすべての IP パケットは UDP でカプセル化され、
無事に届けられました 他の海賊たち。 - クライアントは設定でサーバーのパブリック IP アドレスを設定します。 サーバーは、正しく認証されたデータがクライアントから送信されると、クライアントの外部アドレスを自動的に学習します。
- サーバーは作業を中断することなくパブリック IP アドレスを変更できます。 同時に、接続されているクライアントに通知が送信され、クライアントはその場で構成を更新します。
- ルーティングの概念が使用されます
暗号鍵ルーティング 。 WireGuard は、ピアの公開キーに基づいてパケットを送受信します。 サーバーが正しく認証されたパケットを復号化すると、その src フィールドがチェックされます。 設定と一致していればallowed-ips
ピアが認証されると、パケットは WireGuard インターフェイスによって受信されます。 発信パケットを送信するとき、対応する手順が実行されます。パケットの dst フィールドが取得され、それに基づいて対応するピアが選択され、パケットは独自の鍵で署名され、ピアの鍵で暗号化されてリモートに送信されます。終点。
WireGuard のコア ロジック全体のコード行数は 4 行未満ですが、OpenVPN と IPSec のコード行数は数十万行です。 最新の暗号化アルゴリズムをサポートするために、Linux カーネルに新しい暗号化 API を含めることが提案されています。
Производительность
Linux システムでは WireGuard がカーネル モジュールとして実装されているため、(OpenVPN や IPSec と比較して) 最大のパフォーマンス上の利点が顕著になります。 さらに、macOS、Android、iOS、FreeBSD、OpenBSD もサポートされていますが、WireGuard はユーザー空間で実行され、その後のすべてのパフォーマンスに影響します。 Windows のサポートは近い将来追加される予定です。
ベンチマーク結果
私の使用体験
私は VPN 設定の専門家ではありません。 一度、ハンドルを使用して OpenVPN をセットアップしましたが、非常に退屈で、IPSec も試しませんでした。 決断しなければならないことが多すぎると、自分の足を撃ってしまいがちです。 したがって、私は常に既製のスクリプトを使用してサーバーを構成してきました。
したがって、私の観点から見ると、WireGuard は一般的にユーザーにとって理想的です。 すべての下位レベルの決定は仕様内で行われるため、一般的な VPN インフラストラクチャの準備プロセスには数分しかかかりません。 構成内のナファカピットはほぼ不可能です。
インストールプロセス
暗号化キーはユーティリティによって生成されます wg
:
SERVER_PRIVKEY=$( wg genkey )
SERVER_PUBKEY=$( echo $SERVER_PRIVKEY | wg pubkey )
CLIENT_PRIVKEY=$( wg genkey )
CLIENT_PUBKEY=$( echo $CLIENT_PRIVKEY | wg pubkey )
次に、サーバー構成を作成する必要があります /etc/wireguard/wg0.conf
次の内容で:
[Interface]
Address = 10.9.0.1/24
PrivateKey = $SERVER_PRIVKEY
[Peer]
PublicKey = $CLIENT_PUBKEY
AllowedIPs = 10.9.0.2/32
スクリプトでトンネルを立ち上げます wg-quick
:
sudo wg-quick up /etc/wireguard/wg0.conf
systemd を備えたシステムでは、代わりにこれを使用できます sudo systemctl start [email protected]
.
クライアント マシンで構成を作成します。 /etc/wireguard/wg0.conf
:
[Interface]
PrivateKey = $CLIENT_PRIVKEY
Address = 10.9.0.2/24
[Peer]
PublicKey = $SERVER_PUBKEY
AllowedIPs = 0.0.0.0/0
Endpoint = 1.2.3.4:51820 # Внешний IP сервера
PersistentKeepalive = 25
そして同じ方法でトンネルを上げます。
sudo wg-quick up /etc/wireguard/wg0.conf
クライアントがインターネットにアクセスできるように、サーバー上で NAT を構成する作業が残っています。これで完了です。
このような使いやすさとコード ベースのコンパクトさは、キー配布機能を排除することによって実現されました。 複雑な証明書システムはなく、この企業の恐ろしいすべての短い暗号化キーは SSH キーとほぼ同じように配布されます。 しかし、これには問題が生じます。WireGuard を既存のネットワークによっては実装するのが簡単ではないということです。
欠点の中でも、トランスポートとして UDP プロトコルしかないため、WireGuard が HTTP プロキシ経由では機能しないことは注目に値します。 プロトコルを難読化することは可能でしょうか?という疑問が生じます。 もちろん、これは VPN の直接のタスクではありませんが、たとえば OpenVPN の場合、HTTPS に偽装する方法があり、全体主義国の住民がインターネットを最大限に利用できるようになります。
所見
要約すると、これは非常に興味深く有望なプロジェクトであり、すでに個人サーバーで使用できます。 利益は何ですか? Linux システムでの高いパフォーマンス、セットアップとメンテナンスの容易さ、コンパクトで読みやすいコード ベース。 ただし、複雑なインフラストラクチャを急いで WireGuard に移行するのは時期尚早です。Linux カーネルに組み込まれるのを待つ価値があります。
私(そしてあなたの)時間を節約するために、私は
出所: habr.com