`ip route get` and `traceroute` display conflicting information

I have a host machine and a guest VM. I am running a WireGuard VPN tunnel on the VM and would like to forward all traffic from the host to the VM and eventually through the VPN tunnel. The production setup will be more complex, but for now, I just want to make sure I am configuring the routes correctly on the host. On the host:

# ip route show table all
default via 10.0.0.1 dev enp1s0 table lan
default via 10.1.0.20 dev virbr0 metric 128
default via 10.0.0.1 dev enp1s0 proto dhcp src 10.0.0.100 metric 1024
10.0.0.0/24 dev enp1s0 proto kernel scope link src 10.0.0.100 metric 1024
10.0.0.1 dev enp1s0 proto kernel scope link src 10.0.0.100 metric 1024


# ip rule
0:      from all lookup local
32764:  from 10.1.0.0/24 lookup lan
32766:  from all lookup main
32767:  from all lookup default

# ip route get 1.1.1.1
1.1.1.1 via 10.1.0.20 dev virbr0 src 10.1.0.1 uid 0
    cache

# traceroute 1.1.1.1
1 _gateway (10.0.0.1) ...
...

So it appears that the result of ip route get 1.1.1.1 does not agree with the actual route chosen when I use traceroute 1.1.1.1. What might be the cause of this? --- **EDIT** It turns out ping 1.1.1.1 was quite helpful because I noticed the message "Redirect Host(New nexthop: 10.1.0.1)". This is part of IP that I was not familiar with, but apparently gateways will try to be efficient and send ICMP messages if there is a more direct route. The working configuration:

# ip route show table all
default via 10.0.0.1 dev enp1s0 table lan
10.0.0.1 dev enp1s0 table lan scope link
default via 10.1.0.20 dev virbr0 metric 128
default via 10.0.0.1 dev enp1s0 proto dhcp src 10.0.0.100 metric 1024
10.0.0.0/24 dev enp1s0 proto kernel scope link src 10.0.0.100 metric 1024
10.0.0.1 dev enp1s0 proto dhcp scope link src 10.0.0.100 metric 1024
10.1.0.0/24 dev virbr0 proto kernel scope link src 10.1.0.1

So it looks like the missing components were:

10.0.0.1 dev enp1s0 table lan scope link
10.1.0.0/24 dev virbr0 proto kernel scope link src 10.1.0.1

Although I'm still not sure why packets were routed to wrong gateway instead of being returned as unroutable. --- **EDIT 2** The configuration mistake was having ip rule add from 10.1.0.0/24 table lan instead of ip rule from 10.1.0.20 table lan. Because the host has the IP address 10.1.0.1 which is in 10.1.0.0/24, packets sent from the host were hitting that table. Still unsure of why 10.0.0.1 was not reported by ip route get. Maybe I needed to use ip route get from 10.0.0.100 to 1.1.1.1?