OpenVPN から WireGuard に切り替えてネットワークを 2 つの LXNUMX ネットワークに結合する

地理的に離れた 3 つのアパートのネットワーク (それぞれが OpenWRT ルーターをゲートウェイとして使用している) を 2 つの共通ネットワークに結合した私の経験を共有したいと思います。 サブネット ルーティングを使用する LXNUMX​​ とブリッジを使用する LXNUMX の間でネットワークを組み合わせる方法を選択するとき、すべてのネットワーク ノードが同じサブネット内にある場合、XNUMX 番目の方法が優先されます。これは構成がより困難ですが、より大きな機会を提供します。構築中のネットワークでは、Wake-on-Lan と DLNA によるテクノロジーの透過的な使用が計画されました。

パート 1: 背景

OpenVPN は、最初にこのタスクを実装するためのプロトコルとして選択されました。その理由は、第一に、問題なくブリッジに追加できるタップ デバイスを作成できること、第二に、OpenVPN は TCP プロトコルを介した操作をサポートしていること、これも重要でした。アパートの一部には専用の IP アドレスがあり、プロバイダーが何らかの理由でネットワークからの UDP 接続をブロックしているため STUN を使用できませんでしたが、TCP プロトコルでは SSH を使用して VPN サーバー ポートをレンタル VPS に転送できました。 はい、このアプローチではデータが XNUMX 回暗号化されるため、大きな負荷がかかりますが、第三者が VPS を制御するリスクが依然としてあったため、プライベート ネットワークに VPS を導入したくありませんでした。私のホーム ネットワークでは非常に望ましくないため、セキュリティには大きなオーバーヘッドがかかると判断されました。

サーバーを展開する予定のルーター上のポートを転送するには、sshtunnel プログラムが使用されました。 その構成の複雑さについては説明しません。非常に簡単に実行できます。そのタスクがルーターから VPS に TCP ポート 1194 を転送することであったことだけを述べておきます。 次に、br-lan ブリッジに接続された Tap0 デバイス上に OpenVPN サーバーが構成されました。 ラップトップから新しく作成されたサーバーへの接続を確認したところ、ポート転送の考えが正当であり、物理的にはルーターのネットワークに含まれていなかったにもかかわらず、ラップトップがルーターのネットワークのメンバーになったことが明らかになりました。

やるべきことは XNUMX つだけ残っています。競合しないように IP アドレスを異なるアパートに分散し、ルーターを OpenVPN クライアントとして構成する必要がありました。
次のルーター IP アドレスと DHCP サーバー範囲が選択されました。

• 192.168.10.1 範囲付き 192.168.10.2 - 192.168.10.80 サーバー用
• 192.168.10.100 範囲付き 192.168.10.101 - 192.168.10.149 アパートNo.2のルーター用
• 192.168.10.150 範囲付き 192.168.10.151 - 192.168.10.199 アパートNo.3のルーター用

また、構成に次の行を追加して、これらのアドレスを OpenVPN サーバーのクライアント ルーターに正確に割り当てる必要もありました。

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

次の行を /etc/openvpn/ipp.txt ファイルに追加します。

flat1_id 192.168.10.100
flat2_id 192.168.10.150

flat1_id と flat2_id は、OpenVPN に接続するための証明書を作成するときに指定したデバイス名です。

次に、OpenVPN クライアントがルーター上で構成され、両方の Tap0 デバイスが br-lan ブリッジに追加されました。 この段階では、0 つのネットワークすべてが相互に認識でき、XNUMX つとして機能するため、すべてがうまくいっているように見えました。 ただし、あまり愉快ではない詳細が明らかになりました。デバイスがルータからではなく IP アドレスを受け取る場合があり、その後のすべての影響が発生する可能性があります。 何らかの理由で、アパートの XNUMX つのルーターに DHCPDISCOVER への応答が間に合わず、デバイスは意図しないアドレスを受信しました。 各ルーターのtapXNUMXでそのようなリクエストをフィルタリングする必要があることに気づきましたが、結局のところ、デバイスがブリッジの一部である場合、iptablesはそのデバイスで動作できないため、ebtablesが助けになる必要があります。 残念なことに、それは私のファームウェアには含まれていなかったため、デバイスごとにイメージを再構築する必要がありました。 これを実行し、次の行を各ルーターの /etc/rc.local に追加することで、問題は解決されました。

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

この構成は XNUMX 年間続きました。

パート 2: WireGuard の紹介

最近、インターネット上の人々はますます WireGuard について話し始め、その構成のシンプルさ、高い伝送速度、低い ping と同等のセキュリティを賞賛しています。 詳しい情報を検索したところ、ブリッジ メンバーとしての動作も TCP プロトコルでの動作もサポートされていないことが明らかになったため、私にとって OpenVPN に代わる選択肢はまだないのではないかと考えました。 そのため、WireGuard について知るのを先延ばしにしました。

数日前、WireGuard がバージョン 5.6 から Linux カーネルに最終的に含まれるというニュースが IT に関係するリソースに広まりました。 いつものように、ニュース記事は WireGuard を賞賛しました。 私は再び、古き良き OpenVPN に代わる方法の模索に取り組みました。 今回遭遇したのは この記事。 GRE を使用して L3 上にイーサネット トンネルを作成する方法について説明しました。 この記事は私に希望を与えてくれました。 UDP プロトコルをどうするかは不明のままでした。 検索の結果、socat を SSH トンネルと組み合わせて使用​​して UDP ポートを転送する方法に関する記事が見つかりました。ただし、このアプローチは単一接続モードでのみ機能する、つまり、複数の VPN クライアントで機能することは不可能であると記載されていました。 VPS に VPN サーバーをインストールし、クライアント用に GRE を設定するというアイデアを思いつきましたが、結局のところ、GRE は暗号化をサポートしていないため、第三者がサーバーにアクセスすると、私のネットワーク間のすべてのトラフィックは彼らの手に渡りますが、これは私にはまったく適していませんでした。

ここでも、次のスキームを使用して VPN over VPN を使用することにより、冗長暗号化を支持する決定が下されました。

レベル XNUMX VPN:
VPS です サーバ 内部アドレス 192.168.30.1
MS です クライアント 内部アドレス 192.168.30.2 の VPS
MK2 です クライアント 内部アドレス 192.168.30.3 の VPS
MK3 です クライアント 内部アドレス 192.168.30.4 の VPS

第 XNUMX レベルの VPN:
MS です サーバ 外部アドレス 192.168.30.2 と内部アドレス 192.168.31.1
MK2 です クライアント MS アドレスは 192.168.30.2 で、内部 IP は 192.168.31.2 です。
MK3 です クライアント MS アドレスは 192.168.30.2 で、内部 IP は 192.168.31.3 です。

* MS — アパート 1 のルーターサーバー、 MK2 - アパート2のルーター、 MK3 - アパートのルーター 3
※端末構成は記事末尾のネタバレにて掲載しております。

ネットワーク ノード 192.168.31.0/24 間で ping が実行されているため、GRE トンネルの設定に進みます。 その前に、ルーターへのアクセスを失わないようにするために、ポート 22 を VPS に転送するように SSH トンネルを設定する価値があります。これにより、たとえば、アパート 10022 のルーターが VPS のポート 2 でアクセスできるようになり、アパート 11122 のルーターは、ポート 3 でアクセスできます。アパート XNUMX のルーターは、同じ sshtunnel を使用して転送を設定するのが最善です。これは、障害が発生した場合にトンネルを復元するためです。

トンネルが構成され、転送されたポートを介して SSH に接続できます。

ssh root@МОЙ_VPS -p 10022

次に、OpenVPN を無効にする必要があります。

/etc/init.d/openvpn stop

次に、アパート 2 のルーターに GRE トンネルを設定しましょう。

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

そして、作成したインターフェイスをブリッジに追加します。

brctl addif br-lan grelan0

サーバールーターでも同様の手順を実行してみましょう。

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

また、作成したインターフェイスをブリッジに追加します。

brctl addif br-lan grelan0

この瞬間から、ping が新しいネットワークに正常に送信され始め、満足してコーヒーを飲みに行きます。 次に、回線の相手側でネットワークがどのように動作しているかを評価するために、アパート 2 のコンピュータの 22 台に SSH 接続しようとしましたが、SSH クライアントはパスワードの入力を求めるプロンプトを表示せずにフリーズしました。 ポート XNUMX の Telnet 経由でこのコンピュータに接続しようとすると、接続が確立されていること、SSH サーバーが応答していることを理解できる行が表示されますが、何らかの理由でログを求めるプロンプトが表示されません。で。

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

VNC 経由で接続しようとしましたが、黒い画面が表示されます。 このアパートからは内部アドレスを使用して簡単にルーターに接続できるため、問題はリモート コンピューターにあると自分自身に納得させます。 しかし、ルーターを介してこのコンピューターの SSH に接続することにしたところ、接続は成功し、リモート コンピューターは正常に動作しているのに、私のコンピューターにも接続できないことに気づきました。

grelan0 デバイスをブリッジから削除し、アパート 2 のルーターで OpenVPN を実行し、ネットワークが再び期待どおりに動作し、接続が切断されていないことを確認します。 検索すると、同じ問題について苦情を訴える人々がいて、MTU を上げるようアドバイスされているフォーラムを見つけました。 否や言うほどない。 ただし、MTU が十分に高く設定されるまで (gretap デバイスの 7000)、TCP 接続のドロップまたは低い転送速度が観察されました。 gretap の MTU が高いため、レイヤ 8000 およびレイヤ 7500 WireGuard 接続の MTU はそれぞれ XNUMX と XNUMX に設定されました。

アパート 3 のルーターでも同様の設定を実行しましたが、唯一の違いは、grelan1 という名前の XNUMX 番目の gretap インターフェイスがサーバー ルーターに追加され、br-lan ブリッジにも追加されたことです。

すべてが機能しています。 これで、gretap アセンブリをスタートアップに入れることができます。 このために：

アパート 2 のルーターの /etc/rc.local に次の行を配置しました。

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

これをアパート 3 のルーターの /etc/rc.local に追加しました。

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

そしてサーバールーターでは次のようになります。

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1

クライアントルーターを再起動した後、何らかの理由でサーバーに接続していないことがわかりました。 SSH に接続すると (幸いなことに、このために以前に sshtunnel を構成していました)、何らかの理由で Wi​​reGuard がエンドポイントのルートを作成していることが判明しましたが、それは間違っていました。 したがって、192.168.30.2 の場合、ルート テーブルは pppoe-wan インターフェイス、つまりインターネットを経由するルートを示していましたが、そのルートへのルートは wg0 インターフェイスを経由するはずでした。 このルートを削除すると、接続が復元されました。 WireGuard にこれらのルートを作成させないようにする方法に関する説明はどこにも見つかりませんでした。 さらに、これが OpenWRT の機能なのか、それとも WireGuard 自体の機能なのかさえわかりませんでした。 この問題に長い間対処する必要はなく、単にこのルートを削除する時間指定スクリプトの行を両方のルーターに追加しました。

route del 192.168.30.2

要約

私はまだ OpenVPN を完全に放棄することはできません。ラップトップや携帯電話から新しいネットワークに接続する必要があり、それらに gretap デバイスを設定することは通常不可能であるためです。しかし、それにもかかわらず、速度の点で利点がありました。アパート間のデータ転送が容易になり、たとえば VNC を使用することも不便ではなくなりました。 Ping はわずかに低下しましたが、より安定しました。

OpenVPN を使用する場合:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

WireGuard を使用する場合:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

VPS への高い ping (約 61.5 ミリ秒) の影響がより大きくなります。

ただし、速度は大幅に向上しました。 したがって、サーバールーターのあるアパートではインターネット接続速度が30 Mビット/秒ですが、他のアパートでは5 Mビット/秒です。 同時に、OpenVPN を使用している間、iperf の測定値によれば、ネットワーク間のデータ転送速度は 3,8 Mbit/秒を超えることができませんでしたが、WireGuard はそれを同じ 5 Mbit/秒に「高速化」しました。

VPS での WireGuard 構成[Interface] Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
AllowedIPs = 192.168.30.2/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
AllowedIPs = 192.168.30.3/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
AllowedIPs = 192.168.30.4/32

MS 上の WireGuard 設定 (/etc/config/network に追加)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3

        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

MK2 の WireGuard 設定 (/etc/config/network に追加)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

MK3 の WireGuard 設定 (/etc/config/network に追加)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

説明した第 51821 レベル VPN の設定では、WireGuard クライアントをポート 0 に向けます。クライアントは空いている特権のないポートから接続を確立するため、理論的にはこれは必要ありませんが、接続を禁止できるようにしました。ポート 51821 への受信 UDP 接続を除く、すべてのルーターの wgXNUMX インターフェイス上のすべての受信接続。

この記事が誰かの役に立てば幸いです。

PS また、ネットワーク上に新しいデバイスが表示されたときに、WirePusher アプリケーションで携帯電話に PUSH 通知を送信するスクリプトを共有したいと考えています。 スクリプトへのリンクは次のとおりです。 github.com/r0ck3r/device_discover.

UPDATE： OpenVPN サーバーとクライアントの構成

OpenVPNサーバー

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

OpenVPN クライアント

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

easy-rsaを使用して証明書を生成しました

出所： habr.com