注: Wireguard を使用した VPN のインストール (2024)

導入

ホーム オフィスと VPN、VPN ロケーション ネットワークは、フォーラムで VPN に関する技術的な質問の原因となることがよくあります。特に、かなり新しい Wireguard VPN に関してはそうです。
Wireguard はキーを作成する際のハードルが低く、素人でもモバイル クライアント アクセスと VPN ロケーション ネットワーキングの両方の VPN セットアップを迅速かつ簡単に行うことができます。ここでも、OpenVPN の姉妹チュートリアルと同様に、Wireguard アプリを使用して、古い廃棄 PC、Raspberry Pi 4、または NAS を使用して VPN をすばやくセットアップできます。
同様に、多くのルータとファイアウォール (pfSense、OPNsense)、および代替ルータ オペレーティング システム OpenWRT にはすでに Wireguard が搭載されており、内部 LAN の VPN サーバーを置き換えることができます (またそうすべきです)。
Raspberry Pi、Ubuntu、Windows、Mac OS、またはルーターのハードウェア自体は関係ありません。 OpenVPN と同様、VPN サーバーとクライアントの構成がすべてのプラットフォームとオペレーティング システムで同一であるという利点があります。
キー作成のシンプルさとセットアップの簡素化、そして非常に優れた VPN パフォーマンスが、Wireguard の急速な成功の理由の 1 つです。
FritzBox で使用される標準化され広く使用されている IPsec など、他の VPN プロトコルが存在することは間違いありません。さらにL2TPとOpenVPN。ただし、すべてをカバーするには、この短い Wireguard 関連の「ノートブック」の範囲を超えるため、フォーラム内の他の VPN チュートリアルを参照してください。これらのチュートリアルは、以下のリンクにあります。

VPN 設計の考慮事項

経験豊富なネットワーク管理者は、内部 LAN で VPN サーバーを運用するここで紹介した VPN 設計が、セキュリティの観点からは決して理想的ではないことを認識しています。その理由は、外部からの保護された内部 LAN への保護されていない (VPN) トラフィックを許可する必要があるためです。
ルーターやファイアウォールなどのネットワーク周辺機器上で直接 VPN を操作する場合と比べて、セキュリティ上の欠点は存在しません。 VPN トラフィックは、ファイアウォールの穴 (ポート転送) を通って内部の保護された LAN に送信される必要はありません。
周辺部の VPN は本質的に安全です。
さらに、ローカル LAN 内にいわゆる「ワン アームド」VPN サーバーがある場合、すべての VPN データ トラフィックは、VPN サーバーとの間で共通のインターフェイスを介して実行される必要があります。これにより、パフォーマンスとスケーラビリティも制限されますが、単純なホーム ネットワークでは多くの場合許容されます。
小規模なネットワークでは、これらの VPN 対応ルーターやファイアウォールが利用できない場合や、適切なネットワークのノウハウなどが不足している場合がよくあります。既存のハードウェアを置き換える理由。
このチュートリアルでは、次のインストールのヒントを使用して、両方のオプションのバランスをとることを試みます。基本はまたここのようにOpenVPN チュートリアル、古典的な VPN 標準設計:

またはとしてサイトからサイトへインストール:

ここでも、インターネット ルーターの設定は、FritzBox を使用する他のルーター ハードウェアの代表として説明されています。
AVM ルーターの明確な設定は、他のすべてのルーター モデルの代表としてここに適用されます。
上記の例の Wireguard サーバーを備えたローカル LAN は、IP ネットワーク アドレス 192.168.188.0 /24 および内部 Wireguard IP ネットワーク 100.64.64.0 /24 で動作します。 100.64.0.0 /10 アドレス ブロックはインターネット上でルーティングされません (RFC 6598）。
このアドレス指定は単なる例であり、もちろん独自の IP アドレス指定に適合させることができます。常にプロアクティブな VPN IP アドレス指定を使用する必要があります (例:ここ） 観察する！

VPN トンネルにおける NAT/マスカレード (アドレス変換)

独自の内部 LAN では、IP アドレス変換 (NAT) は常に逆効果であり、透過的なルーティングが不可能になることを意味します。インターネット上の一部の説明では、必要に応じてパブリック VPN が地理位置情報の境界 (ストリーミングなど) を克服することを前提としていることがよくあります。このような設計では、チュートリアルのようなプライベートな場所やクライアント VPN では常に誤動作が発生します。このトピックに関する多数のフォーラム スレッドがこれを証明しています...
以下はプライベート VPN に適用されます。トンネル インターフェイスでは NAT/マスカレードをアクティブにしないでください。 (iptablesまたはnftables)
一部の設計では、トンネル内の NAT/マスカレードが依然として必要な場合があります。たとえば、クライアントが単一サーバー上でのみ集中的に動作する企業 VPN などです。ここでは双方向ルーティングは必要なく、これはセキュリティの観点から利点となります。最終的には、常に自社のセキュリティ ポリシーと要件が問題になります。
さあ行こう...！

ルーターやファイアウォールの設定

このチュートリアルは、デフォルトのポートを使用した従来の Wireguard インストールに基づいています。UDP 51820。セットアップでこれを変更した場合は、それに応じて構成ファイルで調整する必要があります。
セキュリティ上の理由から標準ポートを使用したくない場合は、IANA による世界的に標準化されたポート割り当てにより、いわゆるフリー ポートを常に使用する必要があります。エフェメラルポート49152～65535のエリアは避けてください。これらのポートは通常、攻撃者によってほとんど、またはまったくスキャンされません。
多くの場合、上流のファイアウォールによってポートも制限されます。ここで、ポート 443 (HTTPS) または 22 (SSH) に切り替えることができます。ただし、Wireguard は常に UDP カプセル化を強制するため、正しく構成されたファイアウォール (TCP) ではこのようなポート変更は解決策になりません。

Wireguard サーバーの IP アドレス指定

内部 Wireguard サーバーを使用した上記の設計では、インターネット ルーターの固定静的 IP ルートは、ローカルの Wireguard サーバーの IP アドレスとその内部 VPN IP ネットワークを指します。したがって、常に Wireguard サーバーに静的で信頼性の高い IP アドレスを割り当てることが合理的です。動的 DHCP IP アドレスが変更されると、このルートは失敗し、VPN は接続を失います。避けるべきもの！
したがって、VPN サーバーに静的 IP アドレスを割り当てることは常に良い考えです。ある意味、これは VPN ルーターであり、ルーターは基本的にインターフェイス上で静的 IP アドレスを取得します。
これは、ネットワーク設定のサーバー自体で手動で行うことができます。使用するサーバー ハードウェア (ネットワーク カード) のハードウェア MAC アドレスを使用して、ルーター (Fritzbox など) の DHCP サーバーに固定 IP を割り当てる方が簡単です。
これは、サーバーが柔軟に DHCP 動作 (通常はすべての OS のデフォルト) を維持できる一方で、この固定 Mac アドレス割り当てを通じて常に固定 IP アドレスを受け取ることを意味します。
スクリーンショットの例は、FritzBox DHCP サーバーでのこの設定を示しています。

サーバー上のコマンドにより、サーバーが使用しているハードウェア アドレス (Mac) が明らかになります。ipconfig -all(Windows) またはifconfig(Linux、MacOS)。
Mac アドレスベースの割り当てにこのオプションがない場合は、常にルーターの DHCP アドレス範囲外の静的サーバー IP を割り当てる必要があります。

内部 Wireguard IP アドレス指定

VPN トンネル自体は、OpenVPN と同様に、Wireguard で独自の IP ネットワークを使用し、config コマンドでアクティブ化されます (例)。アドレス = 100.64.64.1/24サーバー構成ファイル内。それについては後で詳しく説明します。
ルーティング環境では常にそうであるように、この VPN 内部 IP ネットワークはネットワーク全体で一意である必要があるため、簡単ではありません。ここでも、無数の標準的な日常ネットワークとの重複を避けることが重要です。 (こちらも参照ここ）。

❗️ここで使用されている内部 Wireguard アドレス指定についてもう 1 つ説明します。
サーバーは内部 IP として .1 を取得し、クライアント領域は .100 から始まります。
サーバーのアドレス指定を .1 から開始し、クライアントを「上から下へ」割り当てるのが常に理にかなっています。
もちろんその逆も機能しますIP化粧品さらにエレガントに。
/24 ネットワークでは、サーバーに対して内部的に .254 で始まり、クライアントには「上向き」に .1 の番号が付けられます。
これにより、クライアント ブロックが表面的に分離され、トラブルシューティングの際に連続したクライアント IP アドレスを確認できるようになります。.1xyすぐに非常に明確に識別します。
明確にするために、この IP アドレス指定は純粋に表面的なものであり、誰もが自分の裁量で行うことができます。
ただし、Wireguard IP アドレスを計画する際に少しの「構造」を設定しておけば、決して害を及ぼすことはなく、後の管理が容易になります。 😉

ルーターでのポート転送またはポート転送または解放

VPN クライアントが外部から内部 Wireguard VPN サーバーにアクセスできるようにするには、ルーターの外部保護ファイアウォールを乗り越える必要があります。適切なポート転送がなければ (上記の VPN 設計に関する説明を参照してください!)、ルーターの NAT ファイアウォールは常にそのような外部接続をブロックし、VPN クライアントが内部 VPN サーバーに到達できなくなります。
ポート転送リリースにより、ルーターのファイアウォールは、ポート UDP 51820 の受信 IP パケットを内部サーバーの IP アドレス (ここでは 192.168.188.254 = Wireguard VPN サーバー) に通過させるように「指示」します。

この設定により、UDP 51820 を使用した受信 Wireguard トラフィック (およびこのトラフィックのみ!) が、ルーターのインターネット ポート上の内部 Wireguard VPN サーバー IP 192.168.188.254 に通過できるようになります。
これは、クライアントで設定する必要がある VPN ターゲット IP が、常にルーターの WAN ポート/インターネット IP と VPN サーバーのローカル LAN IP である必要があることを意味します。

⚠️ この時点で、すでに上で述べたようなものの重大な欠点がわかります内部VPNソリューション！
いつものベスト プラクティスのように、VPN サーバーがインターネット ルーターまたはファイアウォールに直接オンボードされている場合は、ファイアウォールにこれらの「穴」を開けて、保護されていないトラフィックを内部ネットワークに誘導する必要はありません。 VPN の概念ははるかに安全になります。そのため、VPN の黄金ルールが常に適用されます。「VPN は周辺部に属します」そして社内LANへ!!

リモート LAN および内部 VPN IP ネットワークへの静的ルートを構成する

すでに上で説明したように、Wireguard VPN サーバーは独自の内部 IP ネットワークを作成します。外部 VPN クライアントがローカル LAN 上のすべてのデバイスに到達できるようにするには、当然ながら、インターネット ルーターが内部 Wireguard IP ネットワークに到達する方法を認識している必要があります。
これは、インターネット ルーターの固定静的ルートによって行われ、Wireguard IP ネットワーク (ここでは 100.64.64.0 /24) のすべてのトラフィックが Wireguard VPN サーバー (192.168.188.254) に送信されます。
この例の静的ルートは 18 ビットのプレフィックス (255,255.192.0マスク) は、192.168.0.0 から 192.168.63.0 までのすべてのリモート IP ネットワークを Wireguard サーバーにルーティングします。これを独自の IP アドレスに適合させる必要がある場合があります。

(上記のネットワーク スケッチも参照してください)。

Wireguard サーバーとクライアントの構成

繰り返しますが、OpenVPN と同様に、サーバーとクライアントは単純なテキスト ファイルで構成されます。 Windows およびその他のグラフィカル オペレーティング システムの場合、これはグラフィカル Wireguard クライアントに統合されます。理想的には、テキスト エディタを使用して拡張子を付けてこの構成ファイルを作成します。.confそして、インポート機能を使用してグラフィカルな Wireguard セットアップに簡単にインポートできます。
スマートフォンやタブレットなどのモバイル デバイスの場合は、このクライアント構成を QR コードとしてエクスポートする QR コード ツールが利用できるため、オンボード カメラを介してこれらのデバイスに簡単にインポートできます。それについては後で詳しく説明します。
次の章では、サーバーとクライアントの基本的なセットアップについて説明します。

Wireguard サーバーで IP 転送 (ルーティング) を有効にする

IP の観点から見ると、Wireguard VPN サーバーは常にローカル LAN と内部 Wireguard トンネル IP ネットワーク (この例では 100.64.64.0 /24) の間でルーティングを行うため、ルーターでもあります。
通常、サーバー上のルーティング (IP 転送) は、オペレーティング システムに関係なく、デフォルトでは常に無効になっています。
サーバーが IP パケットをローカル LAN から VPN IP ネットワークに、またはその逆にルーティングできるようにするには、オペレーティング システムの Wireguard サーバー コンピュータでルーティング (IP 転送) をアクティブにする必要があります。忘れられがちな事実は、フラストレーションにつながります。

Windows では、これはレジストリまたはサービス管理に干渉することによって発生します。
(IPEnableRouterパラメーター1) 以下も参照してください。https://www.edv-lehrgang.de/ip-routing-aktivieren/

Linux/Raspberry Piなどで編集できます。ナノファイルを編集する/etc/sysctl.confそしてそこのエントリに対して次のようにコメントしました。

# 次の行のコメントを解除して、IPv4net.ipv4.ip_forward=1 のパケット転送を有効にします。

行の前に「#」を入れることでnet.ipv4.ip_forward=1削除されたため、IP 転送/ルーティングがアクティブ化されました。
次に、このファイルを保存し、Linux コンピュータを再起動します。

Wireguard サーバーの構成

最初に、VPN サーバーと VPN クライアント (ピア) のキーが常に生成されます。キー ペアは常に、渡すことができる公開キーと、それに応じて保護する必要がある秘密キーで構成されます。キーは単純なテキスト文字列であり、任意のテキスト エディタでカット アンド ペーストを使用して処理できます。
これは、オンボードの Wireguard ツールを使用して Linux ですばやく実行できます。

umask 077wg ゲンキー |ティーサーバー_プライベート.キー | wg 公開鍵 > server_public.key wg genkey |ティーpeer1_private.key | wg 公開鍵 >peer1_public.key

その後、追加の VPN クライアント (ピア) キーのみを生成できます。wgゲンキー |ティーピア2_プライベートキー | wg 公開鍵 > ピア2_公開.鍵等
何をキーと呼ぶかは任意です。次のような明確な名前wgゲンキー |ティー HerrMeier_private.key | wg 公開鍵 > HerrMeier_public.keyももちろん可能です。
キー ファイルは、内容を表示できる単純なテキスト ファイルです。たとえば、猫のサーバー_プライベート.キー表示できる。

Windows では、クリックします「空のトンネルを追加」これにより、対応するキー ペアが生成され、テキスト フィールドでのセットアップが完了します。

あるいは、ここで拡張子が付いている完全に完成した構成ファイルをインポートすることもできます。.conf

⚠️ 秘密キーは常にローカル デバイス上に排他的に残ります。リモート デバイスでは公開キーのみが構成されます (ピア定義)。クラシック非対称キー方式。

シンプルなサーバー/クライアント構成ロジックは、

[インターフェース]
アドレス =
PrivateKey =
ListenPort =
[ピア]
パブリックキー =
AllowedIPs =

彼にとっても同様です

[インターフェース]
アドレス =
PrivateKey =
[ピア]
パブリックキー =
エンドポイント = <サーバー_IP_FQDN>:
許可された IP =
永続キープアライブ = 25

サーバー構成 Linux

サーバー構成ファイルは次の場所にあります。/etc/wireguard/wg0.conf非常にスリムで、セットアップが簡単です。ナノ編集者。ファイルは、wg0.conf存在しない場合は、次のコマンドを使用して作成します。ナノ編集者。

• アドレス = 内部 VPN サーバーのトンネル アドレス
• PrivateKey = 上記で生成された秘密サーバーキー
• ListenPort = サーバーがリッスンする UDP ポート。 (これはポート転送で設定されたものと同一である必要があります。)
• ピア領域にはクライアントの公開キーが含まれ、「AllowedIPs」には Wireguard サーバーがトンネルにルーティングするアドレスが含まれます。ワイヤーガードはこれを呼び出します「暗号鍵ルーティング」Wireguard サーバーとクライアントがリモート IP ネットワークのルーティングをルーティング テーブルに自動的に転送する原因は何ですか。

⚠️ピアの IP アドレス/32下のサブネットマスク（ホストマスク）「許可されたIP」これにより、Wireguard Cryptokey Routing はこれらのピアをクライアントに明確に割り当てることができます。 (こちらも参照ここ!)
この点は無視されることが非常に多いため、誤って設定されることが多く、VPN での誤ったルーティングにつながります。

[インターフェイス]アドレス = 100.64.64.1/24プライベートキー = AB1234P6j2O0PH1838gYnv5p5n27HVmVWJRjZr12345=ListenPort = 51820[ピア]パブリックキー = 4321Abc06YX3gA4P0sQzywNX8c1sHSeu+oqsrI843 21=許可されたIP = 100.64.64.100/32、192.168.188.0/24

とwg-クイックアップ wg0Wireguard サーバーを起動します。それに応じて停止しますwg-クイックダウン wg0彼。
トンネルが建設されているかどうかを確認できますWGショー(unixoid OS)。

Wireguard サーバーの自動起動 (Linux)

このコマンドは、起動時に Wireguard サーバーを自動的に起動します。

systemctl を有効にする wg-quick@wg0.service

その後、Wireguard サーバーの構成を変更する場合は、Wireguard サーバーも含める必要がありますsystemctl 再起動 wg-quick@wg0.service再開される！

⚠️ リダイレクトとスプリット トンネリング

この重要な点は、ほとんどの場合間違って行われるため、それに応じて考慮する必要があります。
許可される IP 0.0.0.0/0= リモート ローカル LAN のトラフィックのみを送信するのではなく、常にクライアント トラフィックを VPN トンネルに送信します。その後、Clinet のデフォルト ゲートウェイが VPN トンネルにリダイレクトされます。
これを有効にすると、別の IP ネットワークがその配下に存在する必要があります。許可されたIP定義します！！
なぜそうすべきかというと、0.0.0.0/0 は「ルート」を意味するからです。アレントンネル内のクライアント トラフィック」。"すべて"論理的にはすべての IP ネットワークが含まれるため、DNS (名前解決)、NTP (時間) などのシステム関連のトラフィックも含まれます。

原則として、リダイレクトは、トラフィック量に応じて、よりリーンなスプリット トンネリング方法よりもパフォーマンスの点でトンネルに大幅に大きな負荷をかけます。これを常に念頭に置いておかなければなりません。
残念ながら、これは、リモート ターゲット ネットワークの関連トラフィックを VPN にルーティングするだけの場合に、ルーティングを無視したためによく発生する設定エラーです。
本当にリモート LAN の関連トラフィックのみをリダイレクトおよびスプリット トンネリング経由でトンネルにルーティングしたい場合は、/32 マスクを使用したサーバー IP に加えて、それぞれのリモートを入力するだけです。n) IP ネットワークとマスク。まとめ ここでは、インテリジェント サブネット化を使用して 1 つのマスクで複数の IP ネットワークをキャプチャするために、サブネット マスクももちろん許可されます。
スプリット トンネリングでは、リモート LAN のトラフィックのみがトンネルに送信されます。ローカル インターネット トラフィックは常にローカルに留まり、トンネルに負担をかけません。
❗️パフォーマンスの点では、スプリット トンネリングの方がはるかに優れた選択肢です。

ただし、セキュリティ上の理由から、たとえばパブリック WLAN ホットスポットや安全でないゲスト ネットワークを移動するときに保護するためにクライアント トラフィックを暗号化したい場合は、ゲートウェイ リダイレクト セットアップを避けることはできません。

これら 2 つの手順のどちらが意味があるかは、常に VPN のアプリケーション プロファイルに依存し、各ネットワーク管理者は常にケースバイケースで決定する必要があります。
リダイレクト設定では、その場合のみ0.0.0.0/0間で「許可されたIP」定義されていますが、もうそうではありません。
⚠️ したがって、常に許可されるのは分割トンネルとゲートウェイ リダイレクトのみです。
両方の方法を組み合わせると、ないゲートウェイ リダイレクトはその名前が示すようにトラフィックをルーティングするため、これは可能ですが、ルーティングの観点からはまったく無意味です。

サーバー構成 Windows

Windowsファイアウォール

⚠️ まず最初に、ローカル Windows ファイアウォールに関するメモです。これは常にフォーラムの問い合わせにつながるためです。
Windows ファイアウォールは通常、すべてをブロックしますICMP(Ping) を実行し、IP ネットワークからのローカル サーバー サービスへのアクセスを禁止します。
Wireguard はルーティングされた VPN プロセスであるため、外部の送信者 IP アドレスが常に使用され、Windows ファイアウォールで一般的なブロックが行われます。
ping 経由でエンドデバイスまたはサービスにアクセスしたい人VPN アクセスを有効にするこれを行う場合は、Windows ファイアウォールでこれを許可する必要があります。

上記によると、Windows セットアップのサーバー構成は次のようになります。

ここで「アクティブ化」をクリックして Wireguard サーバーを起動します。

Wireguard クライアントの構成

クライアント設定は完全に同一に見えます。

• PrivateKey = クライアントの秘密鍵
• [Peer] で PublicKey = VPN サーバーの公開キー

さらに、エントリーはこちらエンドポイント = :51820これは、VPN サーバーの IP アドレスまたはホスト名とその UDP ポートを定義します。

ローカル LAN ネットワークに VPN サーバーをインストールする場合は、常にローカル DynDNS ホスト名またはそのパブリック WAN ポート IP アドレスを使用することに注意してください。終点構成が指定されています。これのみがインターネットからアクセスでき、上で説明したように、ポート転送を介して VPN トンネルを内部 Wireguard サーバーに転送します。
例は次のとおりです。エンドポイント = meinrouter.dyndns.org:51820DynDNS ホスト名の場合、またはエンドポイント = 85.1.2.3:51820またはパブリック IP を持つ IPv6 アドレス。
ルーターやファイアウォールなどの周辺機器にインストールすると、安全でないポート転送は当然必要なくなります。
内部 VPN サーバーを使用した VPN セットアップは、保護されていないインターネット トラフィックがファイアウォールのポート転送ホールを通ってローカル ネットワークに侵入するため、常に潜在的に安全ではありません。したがって、可能であれば、VPN は常にルーターやファイアウォールなどの周辺機器に属します。

[インターフェイス]アドレス = 100.64.64.101/24プライベートキー = OMjSCv6e/iXECZwq0ZVL5Ywf/KzZvdsGpYKv1512345=# DNS = 172.16.2.1[ピア]パブリックキー = cA+mynt84tVH1gPaUN66E8K0nfzvpsQMohrEbz 54321=# エンドポイント = X.Y.Z.H:51820 エンドポイント = router.myfritz.de:51820 許可された IP = 100.64 .64.1/32、192.168.2.0/24PersistentkeepAlive = 25

⚠️上記はここにも当てはまります警告通知「許可された IP」の下の内部ピアと内部共有アドレスの /32 マスクについて。

Windows セットアップでは、構成は再び次のようになります。

スマートフォンクライアントの設定

QR コードを使用して Wireguard クライアント構成をモバイル デバイスにエクスポート

Linux でインストールするapt インストール qrencode単純な QR エンコーダを使用して、次のように生成します。

qrencode -t png -o qrbild.png -r Wireguard.conf

(-t = グラフィック形式、-o = 出力画像ファイル、-r = 読み取り、入力構成ファイル)

Wireguard クライアントの QR コードは、カメラで写真を撮ってスマートフォンやタブレットに簡単にインポートできます。

AVM Fritzbox Wireguard 構成要素とそのソリューション

AVM Fritzbox 上の完全には標準に準拠していない Wireguard 実装の特殊な機能について説明します。Fritzbox Wireguard チュートリアルを分離します！
FritzBox Wireguard カップリングとそのソリューションに関して考慮する必要があるすべての詳細を強調表示します。特に Linux vServer、Mikrotik、pfSense / OPNsense ファイアウォール上で顕著です。

Wireguard VPN 接続を確認する

Windows では、まず IP アドレスを確認します。ipconfigおよびルーティング テーブルを参照して、すべての IP 設定が適切であることを確認します。
次に、VPN トンネル経由でリモート ネットワークに ping を送信します。 (ここでは、反対側の FritzBox 192.168.188.1 の例を示します)
モバイルデバイス用の非常に優れたツールは次のとおりですHE.NET_ネットワーク_ツール関連するアプリストアから。

C:\User\>ipconfigWindows IP ConfigurationAdapter wg-win10: 接続固有の DNS サフィックス: IPv4 アドレス。 。 。 。 。 。 。 。 。 。 : 100.64.64.101 サブネットマスク。 。 。 。 。 。 。 。 。 。 : 255.255.255.0 デフォルト ゲートウェイ。 。 。 。 。 。 。 。 。 :イーサネット アダプタ イーサネット: 接続固有の DNS サフィックス: lan IPv4 アドレス。 。 。 。 。 。 。 。 。 。 : 192.168.40.147 サブネットマスク。 。 。 。 。 。 。 。 。 。 : 255.255.255.0 デフォルト ゲートウェイ。 。 。 。 。 。 。 。 。 : 192.168.40.1

C:\User\>route printIPv4 ルート テーブル======================================= ==================================アクティブ ルート: ネットワーク宛先ネットワーク マスク ゲートウェイ インターフェイス メトリック 0.0.0.0 0.0.0.0 192.168 .40.1 192.168.40.147 35 100.64.64.0 255.255.255.0 接続時 100.64.64.101 261 100.64.64.1 255.255.255.255 接続時 100.64.64.101 5 100.64.64.101 255.255.255.255 接続中 100.64.64.101 261 100.64.64.255 255.255.255.255 オン接続 100.64.64.101 261 192.168.40.0 255.255.255.0 接続時 192.168.40.147 291 192.168.40.147 255.255.255.255 接続時 192.168.40.147 291 192。 1 68.40.255 255.255.255.255 接続中 192.168.40.147 291 192.168.188.0 255.255.255.0 接続中100.64. 64.101 5 192.168.188.255 255.255.255.255 接続時 100.64.64.101 261================================= = ======================================

リモート クライアントから VPN 経由でルーター (FritzBox) への ping チェックを行います。

C:\User\>ping 192.168.188.1Ping は 32 バイトのデータで 192.168.188.1 に対して実行されます:192.168.188.1 からの応答: バイト = 32 時間 = 218 ミリ秒 TTL=63192.168.188.1 からの応答: バイト = 32 時間 = 9 ミリ秒 TTL = 63 192.168.188.1 からの応答: バイト = 32 時間 = 2 ミリ秒 TTL = 63 192.168.188.1 の Ping 統計: パケット: 送信 = 4、受信 = 4、損失 = 0 (損失 0%)、約ミリ秒単位の時間情報: 最小 = 2ms、最大 = 218ms、平均 = 78ms

それは本当に安全ですか?

安全な暗号化に疑問がある場合は、Wireshark トレースを Wireguard サーバーに送信してください。以下は、リモート VPN クライアントから FritzBox への ping の例です。

スクリーンショットではっきりとわかるように、どのデータが VPN トンネル経由で送信されるかについて、データから結論を引き出すことはできません。

OPNsense ファイアウォール上の Wireguard サーバーのセットアップ例

OPNsense Wireguard のセットアップは、上記の標準セットアップの手順に従います。次の GUI スクリーンショットは、Wireguard サーバー (VPN レスポンダー) としての OPNsense ファイアウォールの正しい構成を示しています。
(構成手順は、pfSense ファイアウォールに同様に転送できます。ここ)
サブネット マスクを使用して作業を簡単にしたい場合は、この例で使用されている内部 /27 トンネル ネットワークを /24 マスク (またはその他のマスク) で運用することもできます。 /27 ネットワークでは、.1 ～ .30 の内部 VPN IP ネットワーク (29 の VPN クライアントとサーバー) で 30 のクライアント アドレスを操作できます。 (こちらも参照対処のヒントこのチュートリアルの冒頭で!)

サーバーのセットアップ

ローカル設定が表示されます (ローカル構成) サーバーが使用する UDP ポート、キー、および VPN トンネルの内部 IP アドレスを含む Wireguard サーバーの情報。
ここで構成された UDP サーバー ポートは、以下のスクリーンショットの WAN ファイアウォール ルールに対応する必要があります。
⚠️大切なのはクライアントです(終点) のサブネットマスクに許可されたIP注意すること！内部アドレスは常にここで取得されます/32erホストマスク！残念ながら、この点は非常に多くの場合間違って行われ、暗号鍵のルーティングに問題を引き起こします。

⚠️ 設定ポイントもまったく重要でないわけではありません「ルートを無効にする」！
pfSense とは対照的に、OPNsense では、オプションでクライアントまたはピア ルートを自動的に追加できます (無効)。たとえば、OSPF、RIP、または BGP を使用して大規模な VPN ネットワークで動的にルーティングする場合、これをオフにすると便利です。その後、動的ルーティング プロセスがルーティングの更新を引き継ぎます。 (次の章を参照動的ルーティング)
ただし、少数のクライアントまたはサイト間での一般的な共有インストールでは、アクティブ化されたままにします (空、チェックが入っています!)。

トンネルインターフェースの割り当て

⚠️ 忘れられがちなもう 1 つのポイントは、Wireguard トンネル インターフェイスを「インターフェイスの割り当て」に追加することです。これは、基本設定でサーバーにすでに割り当てられている静的サーバー トンネル IP アドレスで発生します。

ファイアウォールルール

設定するファイアウォール ルールが 2 つあります。

• 外部から WAN ポートの IP アドレスに着信する Wireguard UDP トラフィックを許可する WAN ポート ルール
• VPN トンネル内で Wireguard トラフィックを許可するトンネル ルール。(ここでは一例として挙げます"納屋のドア"すべてを許可するルール)

⚠️ 後者の場合、このルールを (グループ) システム トンネル インターフェイスで設定するように注意する必要がありますが、常にインターフェイス割り当てで追加したトンネル インターフェイスで設定する必要があります。 (システムインターフェイスは常に空のままです!)

OPNsense サーバーのクライアント構成

ここでも、/32 ホスト マスクを持つ内部トンネル アドレスです。
192.168.2.0 /24 は、OPNsense ファイアウォール上のローカル LAN です。

[インターフェイス]アドレス = 100.64.65.30/27プライベートキー = SLxmZLKxKUh0uiqWU+epIA8Ca263uTv5QYJGtdjE123=[ピア]公開キー = 3Dbuc2uigSRVdjAFh1HEJvI/e530MbeQOQUGOMbCYFg=エンドポイント = 80.1.10 .98:57821AllowedIPs = 100.64.65.1/32、192.168.2.0/24PersistentkeepAlive = 25

ピアと Ping チェック

root@client-1:# wg showinterface: wg0 公開キー: qCrmg226byI0w9x63hi5Oo17KFU68oQo211n9S3MUwU= 秘密キー: (非表示) リスニング ポート: 54733 ピア: 3Dbuc2uigSRVdjAFh1HEJvI/e530MbeQOQUGOMbCYFg= エンドポイント: 80.1。 10.98:57821 許可される IP: 100.64.65.1/32、192.168.2.0 /24 最新のハンドシェイク: 14 秒前転送: 4.14 KiB 受信、9.89 KiB 送信永続キープアライブ: 25 秒ごとroot@client-1:# ping -c 3 192.168.2.1PING 192.168.2.1 (192.168.2.1) 56(84) バイト192.168.2.1 からの data.64 バイト: icmp_seq=1 ttl=64 time=1.19 ms 192.168.2.1 からの 64 バイト: icmp_seq=2 ttl=64 time=1.31 ms 192.168.2.1 からの 64 バイト: icmp_seq=3 ttl=64 time= 1.56 ミリ秒 --- 192.168.2.1 ping 統計 ---送信 3 パケット、受信 3 パケット、パケット損失 0%、時間 2003msrtt min/avg/max/mdev = 1.185/1.351/1.55​​6/0.153 ms

ステータスチェックOPNsense

Wireguard 経由の BGP、OSPF、または RIPv2 による動的ルーティング

興味深い点は、BGP、OSPF、RIPv2 などの動的ルーティングで WireGuard を使用することです。これは、完全または部分的にメッシュ化された VPN 設計を使用して、異なる場所間で自動ルーティング冗長性を使用する場合に意味があります。これにより、可用性の高い VPN ロケーション接続を実装できます。
通常、Cisco、pfSense / OPNsense、Mikrotik などの統合ダイナミック ルーティング プロトコルを備えた VPN ルーターを使用します。this_forumチュートリアル基本的に説明されています。
ただし、外部サーバーを使用して実装することもできます。これには、Raspberry Pi クレジット カード電卓でも十分です。
すべてを詳細に説明するのはこのチュートリアルの範囲を超えているため、ここでは、そのような設計で最も重要な To-Do ステップのみをリストします。

Mikrotik ルーターを使用した実用的な OSPF ソリューションが見つかります。ここ
OSPF ではなく BGP を使用したい人は誰でも、ここそれを見つけた。

基本はそれらと同様の Quagga ルーティング ソフトウェアですここはすでに説明されています。このチュートリアルでは、既存の基本インストールを前提とし、ルーティング プロトコルの例として OSPF を使用します。

設定ファイル

対応する構成ファイルは次のようになります。
ゼブラ.conf

ホスト名 routerpassword 管理可能なパスワード adminlog ファイル /var/log/quagga.loglog stdout!インターフェイス eth0!インターフェイス wg0!インターフェイス wlan0 shutdown!ip forwarding!line vty

ospfd.conf

ホスト名 routerpassword 管理可能なパスワード adminlog ファイル /var/log/quagga.log!interface eth0!interface wg0 ip ospf network point-to-multipoint ip ospf mtu-ignore!interface wlan0!router ospf log-adjacency-changes auto-cost Reference-bandwidth 10000 パッシブ インターフェイス デフォルト パッシブ インターフェイスなし eth0 パッシブ インターフェイスなし wg0 ネットワーク 100.64.64.0/24 エリア 0.0.0.0 ネットワーク 192.168.188.0/24 エリア 0.0.0.0!line vty

wg0.conf

[インターフェイス]アドレス = 100.64.64.1/24プライベートキー = 2GIsoO70....ListenPort = 51820[ピア]# OSPF RasPiPublicKey = 4ES9Aen....AllowedIPs = 100.64.64.100/32、224.0.0.5/32、224.0.0.6/32 、192.168.40.0/24[ピア]PublicKey = HVanaU....AllowedIPs = 100.64.64.101/32、192.168.8.0/24

ここで重要なのは両側のエントリです「224.0.0.5/32」(および .6) 「許可された IP」の下で、VPN トンネル内の OSPF ノード間のローカル マルチキャストを許可します。

関連リンク

ワイヤーガードのダウンロード:
https://www.wireguard.com/install/

Windows 標準ユーザー向けに Wireguard クライアントをセットアップします。
https://www.heise.de/ratgeber/Windows-WireGuard-VPN-fuer-Standardbenutze ...

「許可された IP」サブネット計算ツール:
https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculat ...

ワイヤーガードの性能比較:
https://www.wireguard.com/パフォーマンス/

フリッツボックス付きワイヤーガード

Mikrotik、pfSense/OPNsense、Linux、およびその他の Wireguard ルーター上の Fritzbox Wireguard VPN:
S2S ワイヤーガード: AVM から Mikrotik
AVM の特別な機能:
Wireguard Lan to Lan Fritzbox Raspberry Pi
https://www.heise.de/select/ct/2022/23/2225809105962410605
Fritzbox Wireguard および GL.inet モバイル ルーター
Beryl クライアントへの Fritzbox VPN Wireguard 接続

pfSense および OPNsense ファイアウォールに Wireguard トンネル インターフェイスを正しく割り当てます。
openVPN を使用したミニ トラベル ルーターの背後にあるクライアント
スプリット トンネルを備えた OPNsense 複数の Wireguard インターフェイス
スプリット トンネルを備えた OPNsense 複数の Wireguard インターフェイス

Mikrotik と OPNsense/pfSense によるワイヤーガード

pfSense / OPNsense および Mikrotik を使用した LAN 間 VPN のワイヤーガード:
Mikrotik の Wireguard VPN pfSense

Wireguard トンネル経由の BGP ルーティング:
ワイヤーガード BGP ルーティング

Wireguard と Mikrotik を使用した OSPF ルーティング
MikroTik ルーター (RouterOS) での OSPF ルーティングに関する質問について

実践例

Wireguard ロケーション ネットワーキングとモバイル クライアントを使用した実際の例:
ワイヤーガード サイト 2 ロードウォリアーとのサイト

ローカル LAN 内で WG クライアントとサーバーを別々に配置:
WGクライアントu.サーバーはLAN内にあります

DS-Lite 接続と VPN: 仲介サーバーと固定 IP によるソリューション:
Fritzbox カップリングを使用した vServer Jumphost
2 台のモバイル ルーター (TP-Link MR200) を VPN 経由で、場合によっては外部 VPN ゲートウェイ (VPS サーバー) 経由で接続します。
WireGuard トンネル経由の pfsense の自宅の固定 IP
GRE トンネル経由の pfsense の自宅の固定 IP
WireGuard VPN トンネルでのリモート ポート転送の落とし穴に注意してください。
2 つの相互接続された pfSense を介してポート転送を実装する方法

ゲートウェイのリダイレクトの概念には注意してください。多くの場合、スプリット トンネリングの方が良い選択となります。
ワイヤーガード トラフィック (ゲートウェイ リダイレクト)
ワイヤーガードの動作が「奇妙な」

WG および vServer 経由でローカル Web サーバーにアクセスできるようにします。
すべてのネットワーク トラフィック (受信および送信) を Wireguard および V-Server 経由でインターネットにルーティングします。

VPN トンネル MTU を正しく処理します。
Ubuntu Server 20.04 への opnsense ワイヤーガードのアップロードが遅い (0.26 mb 秒)

Wireguard VPN サーバーのグラフィカル設定インターフェイス:
https://adminforge.de/linux-allgemein/vpn/wireguard-vpn-server-mit-web-i ...

代替の VPN プロトコル:

すべての Windows、Apple、スマートフォン VPN クライアントおよびスマートフォン用の Linux VPN サーバー:
Raspberry Pi を搭載した Windows および Apple クライアント用の IKEv2 VPN サーバー

OpenVPN インストールの「メモ」:
注: OpenVPN を使用した VPN のインストール

pfSense/OPNsense ファイアウォールを使用するオンボード VPN クライアントを備えた L2TP VPN サーバー:
モバイル ユーザー向けの L2TP (IPsec) プロトコルを使用した PfSense VPN

Mikrotik ルーター上のオンボード VPN クライアントを備えた L2TP VPN サーバー:
MikroTik を使用した IPsec VPN の障害

pfSense/OPNsense ファイアウォール上のすべての VPN クライアント用の IPsec IKEv2 VPN サーバー:
pfSense または OPNsense ファイアウォールでモバイル ユーザー向けに IPsec IKEv2 VPN をセットアップする

OSPF または RIPv2 を使用した動的 VPN ルーティング:
Cisco、Mikrotik、pfSense ダイナミック ルーティングを使用した VPN ロケーション ネットワーキング

安価な Wireguard および OpenVPN ルーター ハードウェア:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...

Raspberry Pi 4 ハードウェア:
https://www.reichelt.de/raspberry-pi-4-b-4x-1-5-ghz-2-gb-ram-wlan-bt-ras ...
https://www.reichelt.de/raspberry-pi-4-b-4x-1-5-ghz-4-gb-ram-wlan-bt-ras ...
電源アダプタ：
https://www.reichelt.de/raspberry-pi-netzteil-5-1-v-3-0-a-usb-type-c-eu- ...
受動的冷却を備えた適切なハウジング:
https://www.amazon.de/iuniker-Raspberry-Gehäuse-Kühlkörpe ...