ゲスト(WindowsまたはLinux)からのすべてのトラフィックがホスト(Linux)のVPNを通過するように強制しようとしています。ゲストがVPNの外部からインターネットにアクセスできないように、ホストシステムへの接続を確立して新しいインターフェイスを作成しますtun0
。 VPN トンネルはホストシステムで正常に動作します。
設定br0
、VPNは不要
ゲストとしてVPNなしでインターネットに接続するためのブリッジデバイスを作成して接続しbr0
ましたenp7s0
。これにより、ゲスト間でインターネットを実行できます。
ip link add name br0 type bridge
ip link set br0 up
ip link set enp7s0 master br0
ホストからvnet5
デバイスが追加され、にブリッジされますbr0
。ただし、同時にホストからリモートへのpingはもう機能しません。
## On the Host
sudo ip a
# ...
# 14: vnet5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
# link/ether ab:ab:ab:ab:ab:ab brd ff:ff:ff:ff:ff:ff
# inet6 fe80::fc54:ff:fe92:5aa9/64 scope link
# valid_lft forever preferred_lft forever
ping www.google.com
# ping: www.google.com: Temporary failure in name resolution
ping 8.8.8.8
# From 192.168.1.100 icmp_seq=1 Destination Host Unreachable
その後、仮想マシンを起動しvirt-manager
て接続を確認しました。インターネット利用可能:
## On the Guest
ip a
# 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
# ...
# 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
# link/ether 52:54:00:92:5a:a9 brd ff:ff:ff:ff:ff:ff
# inet 192.168.1.221/24 brd 192.168.1.255 scope global dynamic noprefixroute enp1s0
# valid_lft 67432sec preferred_lft 67432sec
ping www.google.ch
# PING www.google.ch (172.217.168.35) 56(84) bytes of data.
# 64 bytes from zrh04s14-in-f3.1e100.net (172.217.168.35): icmp_seq=1 ttl=117 time=2.47 ms
設定に加えて、との間にルーティングルールを作成ip link set enp7s0 master br0
できるようです。br0
enp7s0
VPNとtun0
インターフェイスの使用
VPN接続を確立すると、tun0
ブリッジに割り当てられないインターフェイスが作成されます。したがって、とにかくルーティングルールを作成する必要があります。だから状況は上記と似ていると思います。まず再びenp7s0
削除しましたbr0
。
ip link set enp7s0 nomaster
sudo openvpn my_vpn_tcp.ovpn
# ...
# Initialization Sequence Completed
sudo ip a
# ...
# 3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
# link/ether ab:ab:ab:ab:ab:ab brd ff:ff:ff:ff:ff:ff permaddr ab:ab:ab:ab:ab:ab
# inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic noprefixroute enp7s0
# valid_lft 82702sec preferred_lft 82702sec
# ...
# 10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
# link/none
# inet 10.7.7.5/24 scope global tun0
# valid_lft forever preferred_lft forever
# ...
# 12: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
# link/ether 72:eb:06:e5:1e:5a brd ff:ff:ff:ff:ff:ff
# inet6 fe80::70eb:6ff:fee5:1e5a/64 scope link
# valid_lft forever preferred_lft forever
追加の処置は必要ありません。ホストでVPN接続を使用するだけです。
ping www.google.com
# PING www.google.com (172.217.168.3) 56(84) bytes of data.
# 64 bytes from lala.net (172.217.168.3): icmp_seq=1 ttl=117 time=9.64 ms
# ...
ping www.google.com -I tun0
# PING www.google.com (172.217.168.3) from 10.7.7.5 tun0: 56(84) bytes of data.
# 64 bytes from lala.net (172.217.168.3): icmp_seq=2 ttl=117 time=10.0 ms
# ...
ping www.google.com -I enp7s0
# PING www.google.com (172.217.168.3) from 192.168.1.100 enp7s0: 56(84) bytes of data.
# 64 bytes from lala.net (172.217.168.3): icmp_seq=1 ttl=115 time=4.59 ms
# ...
しかし、すでに述べたようにtun0
これに追加することはできませんbr0
。したがって、ゲストもインターネットにアクセスできません。
sudo ip link set tun0 master br0
# RTNETLINK answers: Invalid argument
私は解決策を探しましたが、うまくいく解決策が見つからないか、私の状況が少し異なり、私が持っていないネットワークについてのより多くの知識が必要です。例えばこれ(これは何もしません)またはこれ(これは私の場合には正確ではありません)。
答え1
同じ質問には2つの質問がありますが、実際には互いに依存しません。私はまだ両方に答えます。
また、noprefixroute
アドレスオプションは、ネットワーク構成の一部が、ルートを追加するためにNetworkManagerなどのいくつかの追加ツールによって管理されることを意味します。この回答は、ネットワークツールの統合に対処しようとしません。これには、正しく再構成されていない場合に将来の変更を上書きする可能性があるDHCP構成の処理が含まれます。インターフェイスを閉じたり削除したりすると、多くの設定が消えてリセットする必要があるため、さまざまな責任あるネットワークツールのさまざまなフックを介して実行するのが最善です。
設定br0
、VPNは不要
ブリッジポートとして設定されたインターフェイスは、ルーティング参加を放棄します。
ブリッジポートに設定すると、そのインターフェイスに関連付けられたパスは無視されます。住所を保存すると、まだ有害な副作用がある可能性があります。詳しくはブログでご覧いただけますLinux ブリッジの適切な分離:
- 特定のデバイスにフレームワークを引き渡すハンドラの受信、もしそうなら、
- フレームをグローバルまたは特定のデバイスに渡します。プロトコルハンドラ(例:IPv4、ARP、IPv6)。
ブリッジインターフェイスの場合、カーネルはデバイス固有の受信ハンドラを設定しました
br_handle_frame()
。この機能は、STPおよびLLDPフレームを除いて、または「ルーティング」が有効になっている場合を除き、受信インターフェイスのコンテキストで他の処理を許可しません。だから、これ プロトコルハンドラが実行されないこの場合。
ブリッジポートになるインターフェイスに設定されているIPアドレスは、br0
ルーティングに参加できる唯一のインターフェイスである特別なブリッジ自体インターフェイス(:ブリッジ自体)に移動する必要があります(他のオプションもありますが、簡単に保ちます)。 。関連路線も同じだ。
OPのデフォルトゲートウェイが192.168.1.1/24であると仮定します。最初のケースを書き直してみましょう。
ip link add name br0 up type bridge
ip link set dev enp7s0 master br0
ip address flush dev enp7s0
# previous command will also have removed all associated routes as a side effect
ip address add 192.168.1.100/24 dev br0
# previous command added the LAN route too as a side effect (no noprefixroute here)
ip route add default via 192.168.1.1
これにより、ホストと仮想マシンの両方がインターネットにアクセスできます。
VM部分の場合はvnet5
ブリッジポートでもあり、ルーティングに参加しません。ホストはVMとルーター(192.168.1.1)間でフレームを交換するだけです。ルーティングは含まれません。
VPNとtun0
インターフェイスの使用
OpenVPNはTUN / TAPドライバ(Linuxのカーネルモジュールで提供)を使用します。tun
)。ドライバーは以下を提供できます。
レイヤ 2 TAP インターフェイス
vnet5
これはイーサネットデバイスのように機能し、VMハイパーバイザーによって生成されたイーサネットブリッジポートに設定できます。またはレイヤ3 TUNインターフェイス
これにはフレーム情報(イーサネットMACアドレス)は含まれておらず、フレームを処理せずにレイヤ3以上のプロトコルであるIPv4またはIPv6のみを処理します。したがって、イーサネットブリッジポートとして設定することはできません。これは
tun0
TUNモードでOpenVPNによって生成されたOPです。
OpenVPNはブリッジ可能なTAPモードも使用できますが、これにはリモート設定を再設定する必要があります。仕える人サイドおよびフルネットワークレイアウト:リモートサーバーも192.168.1.0/24 LANの一部になります。 OPはそれを制御できないようです。
それでは、OPのTUNインターフェースが何ができるか考えてみましょう。これは、レイヤ2ではなくレイヤ3(ルーティング)で行われます。
信頼できる仮想マシンに対してのみ以前の設定を再利用します。
ホストにファイアウォールの制限やブリッジパスの変更など、高度なファイアウォールが含まれていない場合、VMは自分自身をゲートウェイとして使用することを強制できません。以前のようにブリッジされたVMは、単にホストを無視し、192.168.1.1をホストとして保持できます。ゲートウェイとトラフィックがtun0
最終的にホストインターフェイスを使用しないようにします。
VMを信頼して再構成できる場合は、上記br0
のままにして、次に基づいてOpenVPN設定を適用しbr0
(enp7s0
への参照を置き換えてbr0
)、VMが実行され(アドレス192.168.1.221で)、VPNが起動した後実行できます。
ホストから
使用ポリシー/ソースベースのルーティングこの特定のソースに対して別のルーティング結果を選択してください。
ip rule add from 192.168.1.221 lookup 1000 ip rule add iif tun0 lookup 1000 ip route add 192.168.1.0/24 dev br0 table 1000 ip route add default dev tun0 table 1000
ルーターとして設定:
sysctl -w net.ipv4.ip_forward=1
この状況を処理するための同様のNATルールがない場合:
iptables -t nat -A POSTROUTING -s 192.168.1.221 -o tun0 -j MASQUERADE
(Linux) VM では、ホストのルーターの代わりにホストをゲートウェイとして使用します。
ip route flush to default ip route add default via 192.168.1.100
信頼できない仮想マシンの推奨事項:ホストプライマリインターフェイスをブリッジポートに設定しないでください。
tun0
これにより、操作しないネットワーク部分を見ることができないため、仮想マシントラフィックをより簡単に適用できます。
独自のIPネットワークを使用するように仮想マシン設定を変更する
例:192.168.100.0/24および固定IP 192.168.100.2/24(ホストのネットワークDHCPの代わりに)、デフォルトゲートウェイ192.168.100.1。 Linux仮想マシンでは:
ip address add 192.168.100.2/24 dev enp1s0 ip route add default via 192.168.100.1
ホストの初期設定から始めます(ブリッジングなし
enp7s0
)。以下のゼロブリッジを使用することもできます(つまり、ブリッジポートに直接設定
ip address add 192.168.100.1/24 dev vnet5
しない)vnet5
ライブラリ仮想マシンこれをより難しくすることもできます。仮想マシン専用のブリッジを設定するだけです(ここでは通常アドレス192.168.100.1/24を使用してください)。ライブラリ仮想マシン基本ブリッジ
virbr0
192.168.122.1/24 提供):ip link add name br0 up type bridge ip address add 192.168.100.1/24 dev br0 ip link set dev vnet5 master br0
そしてまた使用ポリシールーティング
br0
2つの関連インターフェイス、および仮想マシンに関連するトラフィックの動作を変更しますtun0
。いつものように、バックアップルーティングテーブルの既存のパスへのいくつかのコピーと変更が含まれます。ここでは、tun0
ホストとその仮想マシンのみが提供されているとします。最終的な目標は、VM側から来るすべてがトン側にルーティングされ、TUN側から来るすべてがVM側にルーティングされ、不要な側は無視されることです。ip rule add iif br0 lookup 2000 ip rule add iif tun0 lookup 2000 ip route add 192.168.100.0/24 dev br0 table 2000 ip route add default dev tun0 table 2000 # layer 3 interfaces don't need a gateway
注:
tun0
ホストからの着信パケット(ルーティングされていないなど)はホストによって処理されました。地元のルーティングテーブル、テーブル2000の追加パスは必要ありません。ルーターとして設定:
sysctl -w net.ipv4.ip_forward=1
その後、リモートOpenVPNサーバーが192.168.100.0/24を知らないため、NATを完了します。
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE
仮想マシンがまだ192.168.1.0/24 LANにアクセスできる場合:
これに対応するために、テーブル2000を再度更新してください。
プライマリテーブルのLANパスをテーブル2000にコピーします。
ip route add 192.168.1.0/24 dev enp7s0 table 2000
適切なMASQUERADEルールを再追加してください。
...今、VMは他のシステムが知らない別のLAN上にあるからです。
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o enp7s0 -j MASQUERADE
(いくつかのiptablesルールの分解を行うことができます)。