☰

Linux OpenVPN タップルーティングは単一の IP では機能しますが、すべてのトラフィックでは機能しません。

tag-icon • tag-icon linux networking routing openvpn
Linux OpenVPN タップルーティングは単一の IP では機能しますが、すべてのトラフィックでは機能しません。

休暇で旅行する前に、自宅の VPN を設定しようとしています。

TAP セットアップを使用した OpenVPN サーバーが正常に実行されており、クライアントを使用して接続できます。

しかし、クライアント トラフィックをルーティングする際に問題が発生します。

このredirect-gatewayオプションは私には機能しません。今のところ、私はそれをあきらめて、ルートを手動で設定しようとしています。

私のアプローチは、まずタップ インターフェイスに対して DHCP クライアント (dhcpcd) を実行し、次に手動でルートを追加しようとすることです。

# dhcpcd tap0
dhcpcd-9.4.1 starting
...
tap0: rebinding lease of 192.168.1.137
tap0: probing address 192.168.1.137/24
tap0: leased 192.168.1.137 for 86400 seconds
tap0: adding route to 192.168.1.0/24
forked to background, child pid 11185

DHCP クライアントが設定したルートは、内部 IP では正常に機能します。自宅のネットワーク上のコンピューターに ping/ssh を実行できます。テザリングされたセル接続からこれをテストしています。

# ip route
default via 192.168.149.13 dev wlan0 proto dhcp src 192.168.149.193 metric 600
192.168.1.0/24 dev tap0 proto dhcp scope link src 192.168.1.137 metric 1052
192.168.149.0/24 dev wlan0 proto kernel scope link src 192.168.149.193 metric 600

# ping 192.168.1.136 # another IP on my network
PING 192.168.1.136 (192.168.1.136) 56(84) bytes of data.
64 bytes from 192.168.1.136: icmp_seq=1 ttl=64 time=104 ms
64 bytes from 192.168.1.136: icmp_seq=2 ttl=64 time=83.5 ms
...

ホーム ネットワークのゲートウェイ IP を使用してインターネット ホストの IP ルートを手動で追加すると、OpenVPN 経由でそれらにアクセスできるようになります。

(注: 175.55.55.55 は私のテザリングされた携帯電話接続であり、72.33.33.33 は私の自宅の IP です)

# curl -4 https://icanhazip.com
175.55.55.55

# host -t a icanhazip.com
icanhazip.com has address 104.18.115.97
icanhazip.com has address 104.18.114.97

# ip route add 104.18.115.97 via 192.168.1.1
# ip route add 104.18.114.97 via 192.168.1.1

# curl -4 https://icanhazip.com
72.33.33.33

問題は、これをすべてのトラフィックに一般化する方法がよくわからないことです。

VPN 経由でトラフィックを渡すために、キャッチオール ルートを追加しようとしました。

# ip route add 0.0.0.0/1 via 192.168.1.1 dev tap0
# ip route add 128.0.0.0/1 via 192.168.1.1 dev tap0

icanhazip.com に再度アクセスしようとすると、タイムアウトになり、OpenVPN クライアント ログに次のように表示されます。

2022-12-15 15:27:38 us=127602 Recursive routing detected, drop tun packet to [AF_INET]72.33.33.33:2445
2022-12-15 15:27:38 us=122602 Recursive routing detected, drop tun packet to [AF_INET]72.33.33.33:2445
2022-12-15 15:27:38 us=147702 Recursive routing detected, drop tun packet to [AF_INET]72.33.33.33:2445

役に立つ場合は、クライアント (またはサーバー) からのログまたは構成を提供することもできますが、これはルーティングの問題である可能性が高いと思います。

答え1

ああ、当然だ。

@TomYan がそれを理解するのを手伝ってくれました。

OpenVPN クライアントはwlan0デバイスを介して OpenVPN サーバーと通信していました。

wlan0ルートをデフォルト（または、アドレスを使用して実質的にデフォルト）として0.0.0.0/1上書きし128.0.0.0/1、すべてのトラフィックを VPNtap0デバイス経由で送信しようとすると、OpenVPN トラフィックも含まれていました。

「再帰ルーティング」メッセージは確かに正しかったです。

TCP を使用していた場合は、ルートを設定するとすぐに接続がタイムアウトになるため、おそらくもっと早く問題に気付いていたでしょう。

解決策は、OpenVPN クライアントがサーバーに到達できるようにする単一のアドレス ルートを明示的に追加することです。

したがって、DHCP の直後のルートは次のようになります。

# ip route
default via 192.168.149.13 dev wlan0 proto dhcp src 192.168.149.193 metric 600
192.168.1.0/24 dev tap0 proto dhcp scope link src 192.168.1.137 metric 1052
192.168.149.0/24 dev wlan0 proto kernel scope link src 192.168.149.193 metric 600

私の OpenVPN サーバーのアドレスは なので72.33.33.33、上記のデフォルトで説明した wlan0 ゲートウェイを経由して手動でルートを追加します。

# ip route add 72.33.33.33 via 192.168.149.13 dev wlan0

そして、私の 2 つの包括的なルートが機能するようになります。

# ip route add 0.0.0.0/1 via 192.168.1.1 dev tap0
# ip route add 128.0.0.0/1 via 192.168.1.1 dev tap0
# curl -4 https://icanhazip.com
73.33.33.33

関連情報