WireGuard を使用すべきではない理由

WireGuard は最近大きな注目を集めており、実際、VPN の新星です。 しかし、彼は見た目ほど優秀なのでしょうか？ WireGuard が IPsec や OpenVPN に代わるソリューションではない理由を説明するために、いくつかの観察事項について説明し、WireGuard の実装をレビューしたいと思います。

この記事では、[WireGuard に関する] 誤解のいくつかを暴きたいと思います。 はい、読むのに長い時間がかかるので、まだお茶やコーヒーを淹れていない場合は、今すぐにでも読んでください。 私の混乱した考えを正してくれたピーターにも感謝したいと思います。

私は、WireGuard 開発者の信用を傷つけ、彼らの努力やアイデアの価値を下げるという目標を自分自身に設定しているわけではありません。 彼らの製品は機能していますが、個人的には、実際のものとはまったく異なるものとして提示されていると思います。実際には現在存在していない IPsec と OpenVPN の代替として提示されています。

注意として、WireGuard のそのような位置づけに対する責任は、プロジェクト自体やその作成者ではなく、それを取り上げたメディアにあることを付け加えておきます。

最近、Linux カーネルに関する良いニュースはあまりありません。 それで、私たちはプロセッサの巨大な脆弱性について知らされ、それはソフトウェアによって平準化されましたが、リーナス・トーバルズは開発者の功利主義的な言語でそれについてあまりにも無礼で退屈に話しました。 スケジューラやゼロレベルのネットワーキング スタックも、高級雑誌ではあまり明確なトピックではありません。 そしてここにWireGuardが登場します。

机上では、すべてが素晴らしく聞こえます。エキサイティングな新テクノロジーです。

しかし、もう少し詳しく見てみましょう。

WireGuard ホワイトペーパー

この記事は以下に基づいています WireGuard の公式ドキュメントジェイソン・ドーネンフェルド著。 そこで彼は、Linux カーネルにおける [WireGuard] の概念、目的、技術的実装について説明しています。

最初の文は次のようになります。

WireGuard […] は、ほとんどのユースケースにおける IPsec と、他の一般的なユーザー空間や OpenVPN などの TLS ベースのソリューションの両方を置き換えることを目的としており、より安全でパフォーマンスが高く、使いやすい [ツール] です。

もちろん、すべての新しいテクノロジーの主な利点は、 単純さ 【先代との比較】。 しかし、VPN も同様である必要があります。 効率的かつ安全.

そして次は？

これは [VPN に] 必要なものではないという場合は、ここで読み終えても構いません。 ただし、そのようなタスクは他のトンネリング技術にも設定されていることに注意してください。

上記の引用文の中で最も興味深いのは、「ほとんどの場合」という言葉にあるが、もちろんマスコミは無視した。 そして、この記事では、この過失によって引き起こされた混乱のせいで、私たちは最終的にこのような状況に陥っています。

WireGuard は [IPsec] サイト間 VPN に代わるものですか?

いいえ。 Cisco、Juniper などの大手ベンダーが自社製品のために WireGuard を購入する可能性はまったくありません。 よほどの必要がない限り、移動中に「通過する電車に飛び乗る」ことはありません。 後で、彼らがおそらく WireGuard 製品を搭載したくても搭載できない理由のいくつかを説明します。

WireGuard は RoadWarrior をラップトップからデータセンターに持ち運べますか?

いいえ。 現時点では、WireGuard には、このようなことを実行するための重要な機能が多数実装されていません。 たとえば、トンネル サーバー側で動的 IP アドレスを使用することはできませんが、これだけでも、このような製品の使用シナリオ全体が破綻します。

IPFire は、DSL 接続やケーブル接続などの安価なインターネット リンクによく使用されます。 これは、高速ファイバーを必要としない中小企業にとっては理にかなっています。 [翻訳者からの注: 通信の点では、ロシアと一部の CIS 諸国はヨーロッパや米国よりもはるかに先を行っていることを忘れないでください。なぜなら、私たちがネットワークを構築し始めたのはかなり後になってからであり、イーサネットと光ファイバー ネットワークの出現により、標準なので、再構築するのが簡単でした。 EU や米国の同じ国々では、3 ～ 5 Mbps の速度での xDSL ブロードバンド アクセスが依然として一般的であり、光ファイバー接続には、私たちの基準からすると非現実的な金額がかかります。 したがって、この記事の著者は、DSL またはケーブル接続が昔のことではなく、標準であると述べています。] ただし、DSL、ケーブル、LTE (およびその他のワイヤレス アクセス方法) には動的 IP アドレスがあります。 もちろん、頻繁に変化しないこともありますが、変化することもあります。

というサブプロジェクトがあります 「wg-ダイナミック」、この欠点を克服するためにユーザースペース デーモンを追加します。 上で説明したユーザー シナリオの大きな問題は、動的 IPv6 アドレッシングの悪化です。

ディストリビューターの観点からすると、これもあまり良いことではありません。 設計目標の XNUMX つは、プロトコルをシンプルかつクリーンに保つことでした。

残念ながら、実際にはこれらすべてがあまりにも単純かつ原始的なものになっているため、この設計全体を実際に使用できるようにするには、追加のソフトウェアを使用する必要があります。

WireGuard はとても使いやすいですか?

まだ。 WireGuard が XNUMX 点間のトンネリングに決して適した代替手段にならないとは言いませんが、今のところ、これは本来あるべき製品のアルファ版にすぎません。

しかし、それでは彼は実際に何をしているのでしょうか？ IPsec の保守は本当にそれほど難しいのでしょうか?

明らかに違います。 IPsec ベンダーはこれを考慮し、IPFire などのインターフェイスを備えた製品を出荷しています。

IPsec 経由で VPN トンネルを設定するには、構成に入力する必要がある XNUMX つのデータ セットが必要になります。それは、自分のパブリック IP アドレス、受信側のパブリック IP アドレス、パブリックにするサブネットです。この VPN 接続と事前共有キー。 したがって、VPN は数分以内にセットアップされ、どのベンダーとも互換性があります。

残念ながら、この話にはいくつかの例外があります。 IPsec 経由で OpenBSD マシンにトンネルを試みたことがある人なら、私が何を言っているのかわかるでしょう。 他にもいくつか厄介な例がありますが、実際には、IPsec を使用するための優れた実践方法がさらにたくさんあります。

プロトコルの複雑さについて

エンドユーザーはプロトコルの複雑さを心配する必要はありません。

これがユーザーの真の関心事である世界に私たちが住んでいるなら、323 年以上前に作成された、NAT ではうまく動作しない SIP、H.XNUMX、FTP、その他のプロトコルは廃止されていたでしょう。

IPsec が WireGuard よりも複雑であるのには理由があります。IPsec はより多くのことを実行します。 たとえば、ログイン/パスワードまたはEAP付きSIMカードを使用したユーザー認証です。 新しいものを追加する拡張機能があります 暗号プリミティブ.

そして、WireGuard にはそれがありません。

これは、暗号化プリミティブの XNUMX つが弱体化するか完全に侵害されるため、WireGuard がある時点で壊れることを意味します。 技術文書の著者は次のように述べています。

WireGuard は暗号に関して独自の見解を持っていることは注目に値します。 暗号やプロトコルの柔軟性を意図的に欠如しています。 基礎となるプリミティブに重大な穴が見つかった場合は、すべてのエンドポイントを更新する必要があります。 SLL/TLS の脆弱性が次々と発生していることからわかるように、暗号化の柔軟性は現在大幅に向上しています。

最後の文はまったく正しいです。

どの暗号化を使用するかについて合意に達すると、IKE や TLS などのプロトコルが作成されます。 более 複雑。 複雑すぎる？ はい、TLS/SSL では脆弱性が非常に一般的であり、それらに代わるものはありません。

現実の問題を無視することについて

世界中のどこかに 200 の戦闘クライアントを備えた VPN サーバーがあると想像してください。 これはかなり標準的な使用例です。 暗号化を変更する必要がある場合は、ラップトップやスマートフォンなど上の WireGuard のすべてのコピーに更新を配信する必要があります。 同時に 配達。 それは文字通り不可能です。 管理者がこれを実行しようとすると、必要な構成を展開するのに何か月もかかり、中規模の企業がこのようなイベントを実行するには文字通り数年かかります。

IPsec と OpenVPN は暗号ネゴシエーション機能を提供します。 したがって、新しい暗号化をオンにしてからしばらくの間は、古い暗号化も機能します。 これにより、現在の顧客は新しいバージョンにアップグレードできるようになります。 アップデートが展開されたら、脆弱な暗号化を無効にするだけです。 以上です！ 準備！ あなたは素晴らしいです！ クライアントもそれに気づきません。

これは実際には大規模な展開では非常に一般的なケースであり、OpenVPN でもこれには多少の困難があります。 下位互換性は重要であり、たとえ弱い暗号化を使用していても、多くの場合、これはビジネスを閉鎖する理由にはなりません。 なぜなら、仕事ができなくなり、何百人もの顧客の仕事が麻痺してしまうからです。

WireGuard チームはプロトコルをよりシンプルにしましたが、トンネル内の両方のピアを常に制御できない人にはまったく使用できません。 私の経験では、これが最も一般的なシナリオです。

暗号！

しかし、WireGuard が使用するこの興味深い新しい暗号化とは何でしょうか?

WireGuard は、キー交換に Curve25519、暗号化に ChaCha20、データ認証に Poly1305 を使用します。 また、ハッシュ キーには SipHash、ハッシュには BLAKE2 も使用できます。

ChaCha20-Poly1305 は、IPsec および OpenVPN (TLS 経由) 用に標準化されています。

ダニエル・バーンスタインの開発が非常に頻繁に使用されていることがわかります。 BLAKE2 は、SHA-3 との類似性のために SHA-2 ファイナリストに選ばれなかった BLAKE の後継です。 SHA-2 が破られた場合、BLAKE も侵害される可能性が十分にあります。

IPsec と OpenVPN は、その設計により SipHash を必要としません。 したがって、現在使用できないのは BLAKE2 だけであり、それは標準化されるまでの間だけです。 VPN は整合性を確保するために HMAC を使用するため、これは大きな欠点ではありません。HMAC は MD5 と組み合わせても強力なソリューションであると考えられています。

そこで私は、ほぼ同じ暗号化ツールのセットがすべての VPN で使用されているという結論に達しました。 したがって、暗号化や送信データの完全性に関しては、WireGuard は他の現行製品と比べて安全性が高いわけではありません。

しかし、これさえも最も重要なことではありません。プロジェクトの公式ドキュメントによると、これは注意を払う価値があります。 結局のところ、重要なのはスピードです。

WireGuard は他の VPN ソリューションよりも高速ですか?

要するに、いいえ、速くはありません。

ChaCha20 は、ソフトウェアへの実装が容易なストリーム暗号です。 一度に 128 ビットずつ暗号化します。 AES などのブロック プロトコルは、ブロックを一度に XNUMX ビット暗号化します。 ハードウェア サポートを実装するにはさらに多くのトランジスタが必要となるため、大型のプロセッサには、暗号化プロセスのタスクの一部を実行して高速化する命令セット拡張機能である AES-NI が搭載されています。

AES-NI がスマートフォンに採用されることは決してないと予想されていましたが、実際には採用されました。 あたり。]。 このため、ChaCha20 は軽量でバッテリー節約の代替品として開発されました。 したがって、現在購入できるすべてのスマートフォンには何らかの AES アクセラレーションが搭載されており、この暗号化を使用すると ChaCha20 よりも高速かつ低消費電力で動作するというニュースが届くかもしれません。

明らかに、ここ数年で購入されたほぼすべてのデスクトップ/サーバー プロセッサには AES-NI が搭載されています。

したがって、私は、AES があらゆるシナリオで ChaCha20 を上回るパフォーマンスを発揮すると期待しています。 WireGuard の公式ドキュメントには、AVX512 では ChaCha20-Poly1305 が AES-NI よりも優れたパフォーマンスを発揮すると記載されていますが、この命令セット拡張は大型の CPU でのみ利用可能であり、小型でモバイル性の高いハードウェアには役に立ちません。AES を使用すると常に高速になります。 - N.I.

WireGuard の開発中にこれが予見できたかどうかはわかりませんが、現在では、暗号化のみに釘付けになっているという事実がすでに欠点となっており、その動作にはあまり影響を及ぼさない可能性があります。

IPsec を使用すると、ケースに最適な暗号化を自由に選択できます。 もちろん、これは、たとえば VPN 接続を通じて 10 GB 以上のデータを転送する場合に必要です。

Linux での統合の問題

WireGuard は最新の暗号化プロトコルを選択しましたが、これはすでに多くの問題を引き起こしています。 そのため、カーネルでサポートされているものをそのまま使用する代わりに、Linux にはこれらのプリミティブが欠如しているため、WireGuard の統合は何年も遅れてきました。

他のオペレーティング システムでの状況がどうなっているかは完全にはわかりませんが、おそらく Linux の場合とそれほど変わらないでしょう。

現実はどのように見えますか？

残念ながら、クライアントから VPN 接続のセットアップを依頼されるたびに、古い認証情報と暗号化が使用されているという問題に遭遇します。 3DES と MD5 を組み合わせた使用は、AES-256 や SHA1 と同様に、依然として一般的に行われています。 後者の方が若干優れていますが、これは 2020 年に使用すべきものではありません。

鍵交換の場合 常に RSA が使用されます。これは遅いですがかなり安全なツールです。

私のクライアントは、税関やその他の政府機関や機関、さらには世界中で名前が知られている大企業と関係しています。 これらはすべて、数十年前に作成されたリクエスト フォームを使用しており、SHA-512 を使用する機能はまったく追加されていませんでした。 それが何らかの形で技術の進歩に明らかに影響を与えているとは言えませんが、明らかに企業プロセスを遅らせます。

IPsec は 2005 年以来、楕円曲線を直接サポートしているため、これを見ると心が痛みます。Curve25519 も新しくなり、使用できるようになります。 Camellia や ChaCha20 などの AES の代替手段もありますが、明らかにそれらすべてが Cisco などの主要ベンダーによってサポートされているわけではありません。

そして人々はそれを利用します。 Cisco キットは数多くあり、Cisco と連携するように設計されたキットも数多くあります。 彼らはこの分野の市場リーダーであり、いかなる種類のイノベーションにもあまり興味がありません。

はい、（法人部門の）状況はひどいものですが、WireGuard のおかげで変化は見られません。 ベンダーはおそらく、すでに使用しているツールや暗号化にパフォーマンスの問題が発生することはなく、IKEv2 にも問題が発生しないため、代替手段を探していません。

一般的に、Cisco をやめることを考えたことはありますか?

ベンチマーク

それでは、WireGuard ドキュメントのベンチマークに移りましょう。 この[ドキュメント]は科学論文ではありませんが、それでも開発者がより科学的なアプローチを取るか、科学的なアプローチを参考にすることを期待していました。 どのようなベンチマークも再現できなければ役に立ちませんが、実験室で得られたものであればさらに役に立ちません。

WireGuard の Linux ビルドでは、GSO (汎用セグメンテーション オフロード) を利用します。 彼のおかげで、クライアントは 64 キロバイトの巨大なパケットを作成し、それを一度に暗号化/復号化します。 したがって、暗号化操作の呼び出しと実装のコストが削減されます。 VPN 接続のスループットを最大化したい場合、これは良い考えです。

しかし、いつものように、現実はそれほど単純ではありません。 このような大きなパケットをネットワーク アダプタに送信するには、パケットを多数の小さなパケットに分割する必要があります。 通常の送信サイズは 1500 バイトです。 つまり、64 キロバイトの巨大なパケットは 45 のパケット (1240 バイトの情報と 20 バイトの IP ヘッダー) に分割されます。 その後、それらは一緒に一度に送信する必要があるため、しばらくの間、ネットワーク アダプターの動作が完全にブロックされます。 その結果、優先順位が急上昇し、VoIP などのパケットがキューに入れられることになります。

したがって、WireGuard が大胆に主張する高スループットは、他のアプリケーションのネットワーク速度を低下させるという犠牲を払って実現されています。 そして、WireGuard チームはすでに 確認済み これが私の結論です。

しかし、先に進みましょう。

技術ドキュメントのベンチマークによると、接続のスループットは 1011 Mbps です。

印象的です。

これは、単一ギガビット イーサネット接続の理論上の最大スループットが 966 バイトから IP ヘッダーの 1500 バイト、UDP ヘッダーの 20 バイト、およびヘッダーの 8 バイトを引いたパケット サイズで 16 Mbps であるという事実により、特に印象的です。 WireGuard 自体。 カプセル化されたパケットにはもう 20 つの IP ヘッダーがあり、TCP には XNUMX バイトの IP ヘッダーがもう XNUMX つあります。 では、この追加の帯域幅はどこから来たのでしょうか?

巨大なフレームと上で説明した GSO の利点を考慮すると、フレーム サイズ 9000 バイトの理論上の最大値は 1014 Mbps になります。 通常、このようなスループットは大きな困難を伴うため、現実には達成できません。 したがって、理論上の最大値が 64 Mbps で、一部のネットワーク アダプタでのみサポートされる、1023 キロバイトのさらに太い特大フレームを使用してテストが実行されたとしか考えられません。 しかし、これは実際の状況ではまったく適用できず、直接接続された XNUMX つのステーション間でのみ、テストベンチ内でのみ使用できます。

ただし、VPN トンネルはジャンボ フレームをまったくサポートしないインターネット接続を使用して XNUMX つのホスト間で転送されるため、ベンチで得られた結果をベンチマークとして採用することはできません。 これは単に実験室での非現実的な成果であり、実際の戦闘状況では不可能であり、適用できません。

データセンターに座っていても、9000 バイトを超えるフレームを転送できませんでした。

実生活への適用性の基準は完全に違反されており、私が思うに、実行された「測定」の作成者は、明白な理由で自分自身の信用を著しく傷つけました。

最後の希望の光

WireGuard の Web サイトではコンテナについて多くのことが語られており、コンテナが実際に何を目的としているのかが明らかになります。

シンプルで高速な VPN は構成を必要とせず、Amazon がクラウドに備えているような大規模なオーケストレーション ツールを使用して展開および構成できます。 具体的には、Amazon は、AVX512 など、前述した最新のハードウェア機能を使用しています。 これは、x86 やその他のアーキテクチャに縛られず、作業を高速化するために行われます。

これらは、スループットと 9000 バイトを超えるパケットを最適化します。これらは、コンテナーが相互に通信したり、バックアップ操作、スナップショットの作成、同じコンテナーのデプロイを行うための巨大なカプセル化されたフレームになります。 私が説明したシナリオの場合、動的 IP アドレスであっても、WireGuard の動作にはまったく影響しません。

よくやった。 優れた実装と非常に薄い、ほぼ参照プロトコル。

しかし、それは完全に制御できるデータセンターの外の世界には適合しません。 リスクを負って WireGuard の使用を開始する場合は、暗号化プロトコルの設計と実装において常に妥協する必要があります。

出力

WireGuard はまだ準備ができていないと結論付けるのは簡単です。

これは、既存のソリューションの多くの問題に対する軽量かつ迅速なソリューションとして考案されました。 残念ながら、これらのソリューションを実現するために、ほとんどのユーザーに関係する多くの機能を犠牲にしました。 このため、IPsec や OpenVPN を置き換えることはできません。

WireGuard が競争力を発揮するには、少なくとも IP アドレス設定、ルーティング、DNS 構成を追加する必要があります。 明らかに、これが暗号化チャネルの目的です。

セキュリティは私の最優先事項であり、現時点では、IKE または TLS が何らかの形で侵害されたり破損したりしていると信じる理由はありません。 どちらでも最新の暗号化がサポートされており、数十年の運用によって証明されています。 何かが新しいからといって、それが優れているというわけではありません。

相互運用性は、ステーションを制御していないサードパーティと通信する場合に非常に重要です。 IPsec は事実上の標準であり、ほぼどこでもサポートされています。 そして彼は働いています。 そして、見た目がどうであれ、理論的には、将来の WireGuard はそれ自体の異なるバージョンとさえ互換性がなくなる可能性があります。

暗号化保護は遅かれ早かれ破られるため、交換または更新する必要があります。

これらの事実をすべて否定し、盲目的に WireGuard を使用して iPhone を自宅のワークステーションに接続したいと考えるのは、まさに首を突っ込むマスタークラスです。

出所： habr.com