ブリッジトラフィックをVPNトンネルにルーティングする（AWSクライアントVPNエンドポイント）
eth0とwlan0の間にブリッジを作成しました。以下はifconfigです
root@ubuntu:~ $ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.24.11.15 netmask 255.255.255.0 broadcast 10.24.11.255
inet6 fe80::1fd4:f47a:59d2:1de8 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:8e:38:ee txqueuelen 1000 (Ethernet)
RX packets 2571 bytes 308138 (300.9 KiB)
RX errors 0 dropped 230 overruns 0 frame 0
TX packets 2511 bytes 289807 (283.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether b8:27:eb:db:6d:bb txqueuelen 1000 (Ethernet)
RX packets 6268 bytes 1641477 (1.5 MiB)
RX errors 0 dropped 39 overruns 0 frame 0
TX packets 7141 bytes 1630895 (1.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<Host>
loop txqueuelen 1000 (Local Loopback)
RX packets 454 bytes 30843 (30.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 454 bytes 30843 (30.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.20.1.226 netmask 255.255.255.224 destination 10.20.1.226
inet6 fe80::ea4d:bb87:d649:5308 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1407 bytes 94382 (92.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether b8:27:eb:8e:38:ee txqueuelen 1000 (Ethernet)
RX packets 5095 bytes 1401614 (1.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5124 bytes 1660553 (1.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ルートテーブル：
root@ubuntu:~ $ Sudo ip route
0.0.0.0/1 via 10.20.1.225 dev tun0
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 204
10.20.1.224/27 dev tun0 proto kernel scope link src 10.20.1.226
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 204
52.36.18.24 via 10.24.11.1 dev br0
128.0.0.0/1 via 10.20.1.225 dev tun0
そして
root@ubuntu:~ $ Sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.20.1.225 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 10.24.11.1 0.0.0.0 UG 204 0 0 br0
10.20.1.224 0.0.0.0 255.255.255.224 U 0 0 0 tun0
10.24.11.0 0.0.0.0 255.255.255.0 U 204 0 0 br0
52.36.18.24 10.24.11.1 255.255.255.255 UGH 0 0 0 br0
128.0.0.0 10.20.1.225 128.0.0.0 UG 0 0 0 tun0
サブネット10.2.0.0/16は、トンネルtun0を介して到達可能であり、このボックスからIP 10.2.1.145にpingを実行できます。ただし、10.2.1.145のこのボックスに接続されているデバイスからwlan0にpingを実行することはできません。 10.24.11.15のこのボックスに接続されているデバイスからwlan0にpingを実行することもできます
このボックスに接続されているtraceroute 10.2.1.145デバイスをwlan0で実行すると、接続はeth0を介してパブリックIP経由で送信されます。
eth0には10.24.11.15がありますが、ブリッジを作成した後、br0に移行しました
10.2.0.0/16トラフィックをtun0にプッシュするためにここで欠落しているルートは何ですか？
これがより多くの出力です：
root@ubuntu:~ $ ip route get 10.2.1.145 from 10.24.11.23 iif br0
10.2.1.145 from 10.24.11.23 via 10.20.0.225 dev tun0
cache iif br0
root@ubuntu:~ $ Sudo ip netconf show dev tun0
ipv4 dev tun0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
root@ubuntu:~ $
root@ubuntu:~ $ Sudo ip netconf show dev br0
ipv4 dev br0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
WiFiクライアントからpingし、ubuntuからtcpdump：
root@client:~# ping 10.2.1.145
root@ubuntu:~ $ Sudo tcpdump -ni br0 'icmp and ip Host 10.2.1.145'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:30:56.903893 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 8, length 64
15:30:57.904278 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 9, length 64
15:30:58.904826 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 10, length 64
root@client:~# ping 10.2.1.145
root@ubuntu:~ $ Sudo tcpdump -nei eth0 'icmp and ip Host 10.2.1.145'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:26:55.356091 ac:bc:32:bf:ad:57 > 18:b1:69:75:7a:f4, ethertype IPv4 (0x0800), length 98: 10.24.11.147 > 10.2.1.145: ICMP echo request, id 5646, seq 169, length 64
iptables-保存：
root@ubuntu:~ $ Sudo iptables-save
# Generated by iptables-save v1.6.0 on Mon May 6 15:37:25 2019
*nat
:PREROUTING ACCEPT [1299:221082]
:INPUT ACCEPT [290:32450]
:OUTPUT ACCEPT [4762:319088]
:POSTROUTING ACCEPT [680:45560]
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May 6 15:37:25 2019
root@ubuntu:~ $ uname -a
Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
root@ubuntu:~ $ Sudo ip rule ls
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
root@ubuntu:~ $ Sudo ip route ls table all
0.0.0.0/1 via 10.20.2.129 dev tun0
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 204
10.20.2.128/27 dev tun0 proto kernel scope link src 10.20.2.130
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 204
52.37.118.218 via 10.24.11.1 dev br0
128.0.0.0/1 via 10.20.2.129 dev tun0
broadcast 10.20.2.128 dev tun0 table local proto kernel scope link src 10.20.2.130
local 10.20.2.130 dev tun0 table local proto kernel scope Host src 10.20.2.130
broadcast 10.20.2.159 dev tun0 table local proto kernel scope link src 10.20.2.130
broadcast 10.24.11.0 dev br0 table local proto kernel scope link src 10.24.11.15
local 10.24.11.15 dev br0 table local proto kernel scope Host src 10.24.11.15
broadcast 10.24.11.255 dev br0 table local proto kernel scope link src 10.24.11.15
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope Host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope Host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
fe80::/64 dev br0 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::1fd4:f47a:59d2:1de8 dev br0 table local proto kernel metric 0 pref medium
local fe80::54bf:cf69:4385:4b1c dev tun0 table local proto kernel metric 0 pref medium
ff00::/8 dev br0 table local metric 256 pref medium
ff00::/8 dev tun0 table local metric 256 pref medium
root@ubuntu:~ $ Sudo ip -4 a ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope Host lo
valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.24.11.15/24 brd 10.24.11.255 scope global br0
valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
inet 10.20.2.130/27 brd 10.20.2.159 scope global tun0
valid_lft forever preferred_lft forever
root@ubuntu:~ $
VPNの反対側はopenvpn serverではありません。これはAWSクライアントVPNエンドポイントここで試しているためです。私はubuntuホストでSudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEを実行しました。 VPNサーバーにアクセスできません。
更新：
Wi-Fiクライアント上
root@client:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:d2:02:8c txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<Host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.24.11.201 netmask 255.255.255.0 broadcast 10.24.11.255
inet6 fe80::f9e2:e7af:ab5f:7865 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:87:57:d9 txqueuelen 1000 (Ethernet)
RX packets 86 bytes 7978 (7.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 97 bytes 16637 (16.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@client:~ $ ip -4 route list
default via 10.24.11.1 dev wlan0 src 10.24.11.201 metric 303
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201 metric 303
Wi-FiクライアントでSudo route del default gw 10.24.11.1 wlan0を削除し、Sudo route add default gw 10.24.11.15 wlan0を追加しました
root@client:~ $ ip -4 route list
default via 10.24.11.15 dev wlan0
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201 metric 303
次に試してみました
root@client:~# ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145): 56 data bytes
root@ubuntu:~ $ Sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:40:03.832209 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 121, length 64
13:40:04.879329 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 122, length 64
13:40:05.911833 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 123, length 64
root@ubuntu:~ $ Sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
13:40:49.539044 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 1, length 64
13:40:50.553286 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 2, length 64
13:40:51.597073 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 3, length 64
Ubuntuで実行
1 iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
2 Sudo iptables -A FORWARD -i br0 -o tun0 -j ACCEPT
3 Sudo iptables -A FORWARD -i tun0 -o br0 -j ACCEPT
root@ubuntu:~ $ Sudo iptables-save -c
# Generated by iptables-save v1.6.0 on Mon May 13 20:30:31 2019
*filter
:INPUT ACCEPT [32:2202]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [49:4174]
[0:0] -A FORWARD -i br0 -o tun0 -j ACCEPT
[0:0] -A FORWARD -i tun0 -o br0 -j ACCEPT
COMMIT
# Completed on Mon May 13 20:30:31 2019
# Generated by iptables-save v1.6.0 on Mon May 13 20:30:31 2019
*nat
:PREROUTING ACCEPT [7:1109]
:INPUT ACCEPT [2:144]
:OUTPUT ACCEPT [20:1340]
:POSTROUTING ACCEPT [4:268]
[0:0] -A POSTROUTING -o eth0 -j MASQUERADE
[16:1072] -A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May 13 20:30:31 2019
root@client:~ $ ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145) 56(84) bytes of data.
root@ubuntu:~ $ Sudo iptables-save -c
# Generated by iptables-save v1.6.0 on Mon May 13 20:31:24 2019
*filter
:INPUT ACCEPT [119:7998]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [218:19046]
[0:0] -A FORWARD -i br0 -o tun0 -j ACCEPT
[0:0] -A FORWARD -i tun0 -o br0 -j ACCEPT
COMMIT
# Completed on Mon May 13 20:31:24 2019
# Generated by iptables-save v1.6.0 on Mon May 13 20:31:24 2019
*nat
:PREROUTING ACCEPT [10:1331]
:INPUT ACCEPT [5:366]
:OUTPUT ACCEPT [45:3015]
:POSTROUTING ACCEPT [9:603]
[0:0] -A POSTROUTING -o eth0 -j MASQUERADE
[36:2412] -A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May 13 20:31:24 2019
次に：
root@client:~ $ ping 10.20.1.225
root@ubuntu:~ $ Sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:42:07.498023 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 208, length 64
09:42:08.537648 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 209, length 64
09:42:09.577700 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 210, length 64
root@ubuntu:~ $ Sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
そして
root@client:~ $ ping 10.2.1.145
root@ubuntu:~ $ Sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:43:32.055291 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 12, length 64
09:43:33.099422 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 13, length 64
09:43:34.135264 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 14, length 64
root@ubuntu:~ $ Sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
ICMP echo requestパッケージがtun0に転送されないようです。
だから、あなたの問題を解決してみましょう。理解を深めるために、ネットワークトポロジ図を作成しました。何が起こるかを明確にするために、ubuntuホスト内でl2とl3の処理をグラフィカルに分割しました-それはさらなる推論に役立ちます。
次の手順を確認してください。
Wi-Fiクライアントのルーティングを確認します（こことさらに-
10.24.11.X-このデバイスの実際のIPアドレスに置き換えます）。あなたのスキームは2つの可能性のいずれかを必要とします：default route via 10.24.11.15またはそれ以上（私は思う）10.2.0.0/16 via 10.24.11.15。ip route get 10.2.1.145 from 10.24.11.X iif br0およびip route get 10.24.11.X from 10.2.1.145 iif tun0コマンドを使用して、ubuntuホストでの転送を確認します。10.2.1.145 from 10.24.11.X via 10.20.1.225 dev tun0（有効なルート）のようなものを返す必要があります。RTNETLINK answers: No route to Hostのようなものが返される場合は、IP転送を（グローバルにまたはインターフェイスごとに）有効にしていないことを意味します。sysctlコマンドで有効にします。また、コマンドtun0を使用してbr0およびip netconf show dev ...インターフェイスの転送を確認します（forwarding on文字列が必要です）。Wi-Fiクライアントで
ping 10.2.1.145コマンドを実行し、ubuntuホストでtcpdump -ni br0 'icmp and ip Host 10.24.11.X'とtcpdump -ni tun0 'icmp'を実行します。 Wi-Fiクライアントからicmp echo requestホストへの10.2.1.145のパケットがいくつか表示されます。表示されない場合は、iptables-saveコマンドでファイアウォールを確認してください（質問に出力を貼り付けて、ケースのヘルプを取得してください）。icmp echo requestが表示されているが、tcpdumpにicmp echo replyが表示されていない場合は、リモートサイトを確認する必要があります。スキームには、リモート側（
openvpn server）でのルーティング設定も必要です。 openvpnサーバー自体にルート10.24.11.0/24 via 10.20.1.226があり、some remote Hostからopenvpn serverまでの同じサブネットへのルートがあるはずです。接続を確立する他の方法-ubuntuホストでNATを使用します（ただし、後で説明します）。Openvpnサーバーで、
ip route get 10.2.1.145 from 10.24.11.X iif tunXおよびip route get 10.24.11.X from 10.2.1.145 iif ethZコマンドを実行します（ここで、tunXおよびethZは、open vpnサーバーに対応するインターフェースです）。どちらのコマンドも有効なルートを表示する必要があります。そうでない場合は、ip netconf showコマンドで転送の有効化を確認してください（そしてsysctlで有効にしてください）。Openvpnサーバーで
tcpdump -ni tunX 'icmp and ip Host 10.2.1.145'コマンドを実行します。リモートwifiクライアントからの着信icmp echo requestsと、icmp echo replyホストからの発信10.2.1.145が表示されます。icmp echo replyが表示されない場合は、some remote Hostでtcpdump（またはwireshark）を実行し、ファイアウォール設定を確認してください。反対側への管理アクセス権がなく、ルーティングを設定できない場合は、ubuntuホストでNAT）を使用する必要があります。ファイアウォールルールに次のルールを追加する必要があります。 set（安全のために
iptables-saveおよびiptables-applyコマンドを使用することをお勧めします）：
iptables -t nat -A POSTROUTING \
-o tun0 \
-j MASQUERADE
- 最後のステップはファイアウォールのチェックです。セットアップでは、ubuntuホストを介したパケットの転送を許可する必要があります。ルールの簡素化：
iptables -A FORWARD -i br0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o br0 -j ACCEPT
次に、
iptables-save -cコマンドの出力でファイアウォールルールカウンターを確認します。角括弧内の数字は、[packets:bytes]形式のルールの一致するカウンターです。pingを再起動して確認します。少なくともNATルールを適用する必要があります。ルールの順序は非常に重要です！上記の手順で問題を解決できない場合は、質問に追加情報を追加してください。問題のトラブルシューティングを行うための追加の手順をいくつか紹介します。