使用すべきでない理由 WireGuard

最近 WireGuard 多くの注目を集めており、実際、それは新たな「スター」である。 VPNしかし、見た目ほど良いものなのでしょうか？いくつか気づいた点を述べ、実装について検証したいと思います。 WireGuardIPsec に取って代わるソリューションではない理由を説明するため、 OpenVPN.

この記事では、いくつかの神話を解き明かしたいと思います。 WireGuardはい、かなり長い記事なので、まだお茶やコーヒーを淹れていない方は、今がその時です。また、私のまとまりのない考えを校正してくれたピーターにも感謝したいと思います。

開発者の信用を失墜させることが私の目的ではありません。 WireGuard彼らの努力やアイデアを軽視している。彼らの製品は機能しているが、個人的には、実際とは全く異なるものとして提示されていると思う。IPsec の代替品として提示されているが、 OpenVPN実際、それは現在では存在しない。

補足として、このような位置付けの責任は WireGuard 報道したメディアによって拡散されるのであって、プロジェクト自体やその制作者によって拡散されるのではない。

最近、コアの話題について Linux 良いニュースはほとんどなかった。ソフトウェアで軽減された恐ろしいプロセッサの脆弱性について聞かされたが、開発者の実用的な言葉遣いで書かれたリーナス・トーバルズの説明はあまりにも粗雑で退屈だった。スケジューラやレベル0ネットワークスタックも、光沢のある雑誌で取り上げるには分かりやすい話題とは言えない。そして、そこに現れたのが WireGuard.

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

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

技術文書 WireGuard

この記事は以下に基づいています 公式ドキュメント WireGuardジェイソン・ドネンフェルドが執筆した記事で、彼はその概念、目的、技術的な実装について説明しています。WireGuard] コア部分 Linux.

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

WireGuard […]は、ほとんどのユースケースでIPsecだけでなく、他の一般的なユーザー空間および/またはTLSベースのソリューションも置き換えることを目指しています。 OpenVPNより安全で、より生産的で、より使いやすい[ツール]です。

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

そして次は？

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

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

それは起こるでしょうか？ WireGuard [IPsec]サイト間VPNを置き換えるべきでしょうか？

いいえ。シスコやジュニパーなどの大手ベンダーが自社製品のためにそれを取得する可能性は全くありません。 WireGuard彼らはよほどの緊急事態でもない限り、「通りすがりの列車に飛び乗る」ようなことはしません。後ほど、彼らが自社製品を車内に設置できないであろう理由についていくつか説明します。 WireGuardたとえ彼らがそうしたくても。

それは生き残れるだろうか？ WireGuard 私のRoadWarriorは、ノートパソコンからデータセンターまで移動します。

いいえ。 WireGuard このような機能を実現するには、非常に多くの重要な機能が欠けています。例えば、トンネルサーバー側で動的IPアドレスを使用できないため、それだけでこの製品の利用目的全体が損なわれてしまいます。

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

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

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

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

WireGuard そんなに簡単に使えるんですか？

まだだ。私はそうは言っていない。 WireGuard これは2点間をトンネルで結ぶための優れた代替手段には決してならないだろうが、今のところは、将来的に目指すべき製品のアルファ版に過ぎない。

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

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

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

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

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

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

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

IPsecが他の技術よりも複雑な理由はいくつかあります。 WireGuard: それだけではありません。例えば、ログインIDとパスワード、またはEAP対応のSIMカードを使用してユーザー認証を行います。さらに、新しいユーザーを追加する機能も備えています。 暗号プリミティブ.

そして、 WireGuard これは存在しません。

そしてこれはつまり WireGuard いずれは、暗号プリミティブのいずれかが弱体化したり、完全に侵害されたりするため、このシステムは機能しなくなるだろう。技術文書の著者は次のように述べている。

これは、ことは注目に値します WireGuard 暗号技術に過信している。意図的に暗号方式とプロトコルに柔軟性を持たせていない。基盤となるプリミティブに深刻な脆弱性が発見された場合、すべてのエンドポイントを更新する必要がある。SSL/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は設計上必須ではありません。そのため、現時点でVPNと併用できないのは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を上回る性能を発揮するとされていますが、この命令セット拡張は大型プロセッサでのみ利用可能であり、小型のモバイルハードウェアでは役に立たず、これらのハードウェアでは常にAES-NIの方が高速になります。

開発段階でこれが予見できたかどうかは分かりません。 WireGuardしかし今日では、一つの暗号化方式に縛られているという事実自体が既に欠点となっており、その運用にあまり良い影響を与えない可能性がある。

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

統合の問題 Linux

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

他のオペレーティングシステムでの状況はよくわかりませんが、おそらくそれほど違いはないでしょう。 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 です。

印象的です。

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

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

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

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

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

最後の希望の光

サイト WireGuard コンテナについて多くの議論が交わされ、それらが実際に何のために作られたのかが明らかになってきた。

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

これらはスループットと9000バイトを超えるパケットサイズを最適化し、コンテナ通信、バックアップ操作、スナップショット作成、コンテナ展開などのための巨大なカプセル化フレームを生成します。動的IPアドレスを使用してもパフォーマンスに影響はありません。 WireGuard 私が説明したシナリオの場合。

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

しかし、完全に制御できるデータセンター以外の世界では、それは単純に適していません。リスクを冒して使用を開始すると、 WireGuard暗号化プロトコルを設計・実装する際には、常に何らかの妥協を強いられることになるでしょう。

出力

私にとって結論を出すのは難しくない WireGuard まだ準備ができていません。

これは、既存のソリューションの多くの問題に対する軽量かつ高速なソリューションとして意図されていました。残念ながら、これらのソリューションを実現するために、ほとんどのユーザーにとって重要な多くの機能を犠牲にしました。そのため、IPsecや OpenVPN.

するために、 WireGuard 競争力を高めるためには、少なくともIPアドレス設定、ルーティング、DNS設定機能を追加する必要がある。そのためには、暗号化されたチャネルが不可欠であることは言うまでもない。

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

相互運用性は、制御できない第三者の端末と通信する場合に非常に重要です。IPsec は事実上の標準であり、ほぼすべての場所でサポートされています。そして、それは機能します。そして、理論的にはどのようなものであっても、 WireGuard 将来的には、異なるバージョンの自分自身とも互換性がなくなる可能性がある。

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

これらの事実全てを否定し、盲目的に利用したいという願望 WireGuard 接続するには iPhone 自宅にワークステーションを設置することは、現実から目を背けることの極みと言えるだろう。

出所： habr.com