☰

特定のポートのインターフェースへのルーティングを持つホストへのルートがありません

tag-icon • tag-icon iproute wireguard
特定のポートのインターフェースへのルーティングを持つホストへのルートがありません

別のサーバー B に VPN が設定されたサーバー A があります。現在、サーバー A は VPN アドレスを使用してサーバー B に ping を実行できます10.12.0.1。

すべての HTTPS トラフィックをサーバー B 経由でルーティングし、他のトラフィックにはデフォルトのインターフェースを使用するようにしたいと思います。

そのために私はこのUnix StackExchangeの回答次のコマンドを実行しました:

# define route
echo "200 myroute" >> /etc/iproute2/rt_tables
# seems necessary
sysctl -w net.ipv4.conf.wg1.rp_filter=2
# actual routing
ip route add table 200 10.12.0.0/24 dev wg1 src 10.12.0.10
ip route add table 200 default via 10.12.0.1
# actual rule telling HTTPS traffic to use table 200
ip rule add iif lo ipproto tcp dport 443 lookup 200

その後、curl https://1.1.1.1(または他のホスト) を実行すると、エラーが発生しますFailed to connect to 1.1.1.1 port 443: No route to host。ルールを削除すると、すべてが再び機能します。

テーブル 200 のルーティングは正しくないようです。しかし、元の回答のルーティングやデフォルト インターフェイスのルーティングと一致しているようです。

問題を調査してデバッグする方法をご存知ですか?

ありがとう

追加情報:

$ ip route show table 200
default via 10.12.0.1 dev wg1 
10.12.0.0/24 dev wg1 scope link src 10.12.0.10 

$ ip route show dev wg1
10.12.0.0/24 proto kernel scope link src 10.12.0.10

$ ip route get 1.1.1.1 ipproto tcp dport 443
1.1.1.1 via 10.12.0.1 dev wg1 table 200 src 10.12.0.10 uid 1001 
    cache 

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
10.12.0.0/24 dev wg1 proto kernel scope link src 10.12.0.10 
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202

VPN は Wireguard VPN です。すべてのトラフィックを VPN 経由でルーティングするように構成すると、すべてが機能します。

答え1

1.1.1.1「ホストへのルートがありません」というエラーは、WireGuard 設定に含まれていないホスト ( ) に接続しようとしたことが原因である可能性がありますAllowedIPs。wg-quick を使用している場合は、次のようにします。

としてステップ1サーバー A の WireGuard 構成で、サーバー B のセクションAllowedIPsの設定を調整して[Peer]、接続先の IP アドレス (または IP アドレスのブロック) を含めます。

の代わりに1.1.1.1、サーバー A からブロック内の任意の HTTPS サーバーに接続できるようにするとします192.0.2.0/24(具体的には、テストに使用しているサーバーが にあるとします)。また、最初にサーバー A でサーバー B にブロックを含めるように設定192.0.2.123しているとします。この設定を次のように変更します。AllowedIPs10.12.0.0/24

AllowedIPs = 10.12.0.0/24, 192.0.2.0/24

サーバー A のテーブル 200 に以前設定したルートとルールを削除し、WireGuard (例sudo wg-quick down wg1; sudo wg-quick up wg1) を再起動して、次のコマンドを実行してこの変更をテストします。

$ curl -k https://192.0.2.123

少なくとも、「ホストへのルートがありません」というエラーは解消されるはずです。それでもエラーが発生する場合は、サーバー B のファイアウォール/ルーティング ルールを調整して、サーバー A から にパケットを転送できるようにする必要があります192.0.2.0/24。

としてステップ2サーバー A の WireGuard 構成のセクションで[Interface]、次の設定を追加します。

Table = 200

これにより、wg-quick は自動的に作成したルートを200メイン テーブルではなくカスタム ルーティング テーブルに追加します。WireGuard をもう一度再起動し、ルーティング テーブルを確認します。

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
$ ip route show table 200
10.12.0.0/24 dev wg1 scope link
192.0.2.0/24 dev wg1 scope link

次に、特別な HTTPS ポリシー ルールを追加します。

$ sudo ip rule add iif lo ipproto tcp dport 443 lookup 200

そしてテストしてみましょう:

$ curl -k https://192.0.2.123

としてステップ3HTTPS 以外のサービス (SSH など) については、WireGuard を介してサーバー A からサーバー B に直接接続できるようにしたい場合は、ブロックへのすべての接続に対してサーバー A に別のポリシー ルールを追加します10.12.0.0/24。

$ sudo ip rule add to 10.12.0.0/24 table 200 priority 201

これで、WireGuard を使用してサーバー A からサーバー B に再度接続できるようになります。

$ ssh 10.12.0.1

関連情報