解決できない非常にトリッキーな問題があります。私の目標は、デフォルトルートテーブルを別のテーブルに配置し（後で複数のテーブルに複数のデフォルトルートを持つことができるように）、ポリシーに基づいて選択してデフォルトゲートウェイから分離することです。
この単純化された例では、2つのインターフェースしかありません。 eth0.2はWAN（パブリックIPを持つDSL）、eth0.3はLANです。
$ ip -4 addr
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
3: vrf_sonic: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default qlen 1000
inet 127.0.0.1/8 brd 127.255.255.255 scope host vrf_sonic
valid_lft forever preferred_lft forever
5: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vrf_sonic state UP group default qlen 1000
inet 192.184.144.21/21 brd 192.184.151.255 scope global dynamic eth0.2
valid_lft 19730sec preferred_lft 19730sec
6: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.227.79.2/24 brd 10.227.79.255 scope global eth0.3
valid_lft forever preferred_lft forever
eth0.2のデフォルトパスはDHCPを介して動的に割り当てられるため、インターフェイス/ DHCPインスタンスでVRFを使用します。私のデフォルトパスは表170にあることがわかりました。
$ sudo ip vrf
Name Table
-----------------------
vrf_sonic 170
$ sudo ip route show table 170
default nhid 38 via 192.184.144.1 dev eth0.2 proto static metric 20
broadcast 127.0.0.0 dev vrf_sonic proto kernel scope link src 127.0.0.1
127.0.0.0/8 dev vrf_sonic proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev vrf_sonic proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev vrf_sonic proto kernel scope link src 127.0.0.1
broadcast 192.184.144.0 dev eth0.2 proto kernel scope link src 192.184.144.21
192.184.144.0/21 dev eth0.2 proto kernel scope link src 192.184.144.21
local 192.184.144.21 dev eth0.2 proto kernel scope host src 192.184.144.21
broadcast 192.184.151.255 dev eth0.2 proto kernel scope link src 192.184.144.21
私の基本テーブルには多くのOSPFパスが含まれていますが、現在は1つだけが含まれています。
$ sudo ip route show table main
10.227.79.0/24 dev eth0.3 proto kernel scope link src 10.227.79.2
今私のルールは次のとおりです。
$ sudo ip rule
101: from all lookup local
102: from all lookup main
104: from all lookup vrf_sonic
1000: from all lookup [l3mdev-table]
2000: from all lookup [l3mdev-table] unreachable
まず、ローカルテーブル（=直接接続されたインターフェイス）を確認します。その後、デフォルトのルーティングテーブルがあります。その後、vrf_sonicにはデフォルトのパス（デフォルトではcatch-all）が含まれます。ルール1000/2000は自動的に挿入されますが（VRFによる）、包括的なルール104のために絶対に使用しないでください。
すべてのファイアウォールテーブルはACCEPT状態で、mangleテーブルは空で、natテーブルも空です。
今まではそんなに良くなった。 ICMP（ping）の仕組み：
$ ping 142.250.189.164
PING 142.250.189.164 56(84) bytes of data.
64 bytes from 142.250.189.164: icmp_seq=1 ttl=113 time=4.78 ms
64 bytes from 142.250.189.164: icmp_seq=2 ttl=113 time=4.59 ms
^C
--- 142.250.189.164 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 4.589/4.683/4.778/0.116 ms
$
これは、ルール104を介してテーブル170を選択すると、期待どおりに正しいデフォルトパスが選択されることを意味します。
今クレイジーな部分が出てきます。
$ telnet 142.250.189.164 80
Trying 142.250.189.164...
telnet: Unable to connect to remote host: Network is unreachable
$
これは WTF#1 です。しかし、より大きなWTFがあります。
$ sudo ip vrf exec vrf_sonic /bin/telnet 142.250.189.164 80
Trying 142.250.189.164...
Connected to 142.250.189.164.
Escape character is '^]'.
GET / HTTP/1.0
[...]
stener("click",G)});}).call(this);</script></body></html>Connection closed by foreign host.
$
これは vrf_sonic VRF の文脈で動作することを意味します。最後に（失敗した）telnetと並列にtcpdumpを起動しました。
$ sudo tcpdump -n -i eth0.2 'host 142.250.189.164'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
23:34:18.875675 IP 192.184.144.21.55124 > 142.250.189.164.80: Flags [S], seq 1179612779, win 64240, options [mss 1460,sackOK,TS val 333932630 ecr 0,nop,wscale 7], length 0
23:34:18.879471 IP 142.250.189.164.80 > 192.184.144.21.55124: Flags [S.], seq 3829270116, ack 1179612780, win 65535, options [mss 1412,sackOK,TS val 146008037 ecr 333932630,nop,wscale 8], length 0
23:34:18.879573 IP 192.184.144.21.55124 > 142.250.189.164.80: Flags [R], seq 1179612780, win 0, length 0
23:34:19.888499 IP 192.184.144.21.55124 > 142.250.189.164.80: Flags [S], seq 1179612779, win 64240, options [mss 1460,sackOK,TS val 333933643 ecr 0,nop,wscale 7], length 0
23:34:19.896597 IP 142.250.189.164.80 > 192.184.144.21.55124: Flags [S.], seq 3845107556, ack 1179612780, win 65535, options [mss 1412,sackOK,TS val 146009050 ecr 333933643,nop,wscale 8], length 0
23:34:19.896719 IP 192.184.144.21.55124 > 142.250.189.164.80: Flags [R], seq 11779612780, win 0, length 0
23:34:21.935744 IP 192.184.144.21.55124 > 142.250.189.164.80: Flags [S], seq 117], length 0n 64240, options [mss 1460,sackOK,TS val 333935690 ecr 0,nop,wscale 7
23:34:21.947596 IP 142.250.189.164.80 > 192.184.144.21.55124: Flags [S.], seq 3ecr 333935690,nop,wscale 8], length 0 options [mss 1412,sackOK,TS val 146011097 e
23:34:21.947717 IP 192.184.144.21.55124 > 142.250.189.164.80: Flags [R], seq 1179612780, win 0, length 0
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel
$
ホストがSYNを送信し、GoogleホストがSYN-ACKに応答した後私たちの所有者送ってください... RST？ ！これをきちんと見るために何度も目をこすらなければなりませんでした。 ＃3はどうなりましたか？ ？
本当に素晴らしいです。どうやって？ここで何が起こっているのでしょうか？