NetworkManager共有接続のデフォルトパスエラー

NetworkManager共有接続のデフォルトパスエラー

私のRPiは4G USBアダプタを介してインターネットに接続されており、モデム接続は/ dev / ttyUSB0を使用してNetworkManager(Raspbian / debian 10)で管理されています。 OpenVPNトンネルも有効にしました。これで、Ethernet eth0(ケーブル経由のWi-Fi AP)を介してこのインターネット接続を共有したいと思います。だから新しいNetworkManager接続を追加しましたnmcli connection add type ethernet ifname eth0 ipv4.method shared con-name ethShared。しかし、eth0に何でも接続すると、NetworkManagerが何らかの理由でeth0を介してデフォルトゲートウェイを追加するため、RPiのインターネットアクセスが失われます。

root@rpi3meteo:~# ip route
default dev eth0 scope link src 169.254.15.88 metric 202
default via 100.94.218.129 dev wwan0 proto static metric 700
10.5.6.0/24 via 10.5.6.5 dev tun0
10.5.6.5 dev tun0 proto kernel scope link src 10.5.6.6
10.42.0.0/24 dev eth0 proto kernel scope link src 10.42.0.1 metric 100
100.94.218.128/25 dev wwan0 proto kernel scope link src 100.94.218.191 metric 700
169.254.0.0/16 dev eth0 scope link src 169.254.15.88 metric 202

また、何らかの理由で、eth0は2つのIPアドレス、つまり10.42.0.1(内部DHCPサーバーでも使用)と169.254.15.88(偽のルーティングテーブルエントリに使用されます)を取得しました。 169.254.0.0/16がローカルリンクであり、DHCPサーバーなしで使用できることを知っていますが、NetworkManagerがこれを「共有」タイプの接続として構成する理由はわかりません。この接続には、NetworkManagerが自動的に提供するDHCPがあります。

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:20:80:80 brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.1/24 brd 10.42.0.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 169.254.15.88/16 brd 169.254.255.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
3: wwan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:1e:10:1f:00:00 brd ff:ff:ff:ff:ff:ff
    inet 100.94.218.191/25 brd 100.94.218.255 scope global noprefixroute wwan0
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.5.6.6 peer 10.5.6.5/32 scope global tun0
       valid_lft forever preferred_lft forever

偽のパスを手動で削除すると、RPiおよびWifiクライアントへのインターネットアクセスが機能し始めましたroute del default dev eth0。ただし、ラズベリーパイはリモートの場所にあるため、再起動後も手動介入なしで動作する必要があります。

パラメータを設定しようとしましたが、ipv4.never-default役に立ちません。また、IPアドレス範囲を手動で設定してみましたipv4.addresses。デフォルトのパス(ipv4.route-metric )とDNS()の優先順位を変更する解決策も見つかりましipv4.dns-priorityたが、まだテストする時間はありませんが、もともとこれが発生しないようにしたり、NetworkManagerを使用することに興味があります。毎日のパスの削除この操作は、接続が最初にアクティブになると自動的に発生します。

connection.id:                          ethShared
connection.stable-id:                   --
connection.type:                        802-3-ethernet
connection.interface-name:              eth0
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.multi-connect:               0 (default)
connection.auth-retries:                -1
connection.master:                      --
connection.slave-type:                  --
connection.autoconnect-slaves:          -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.metered:                     unknown
connection.lldp:                        default
connection.mdns:                        -1 (default)
connection.llmnr:                       -1 (default)
802-3-ethernet.port:                    --
802-3-ethernet.speed:                   0
802-3-ethernet.duplex:                  --
802-3-ethernet.auto-negotiate:          no
802-3-ethernet.mac-address:             --
802-3-ethernet.cloned-mac-address:      --
802-3-ethernet.generate-mac-address-mask:--
802-3-ethernet.mac-address-blacklist:   --
802-3-ethernet.mtu:                     auto
802-3-ethernet.s390-subchannels:        --
802-3-ethernet.s390-nettype:            --
802-3-ethernet.s390-options:            --
802-3-ethernet.wake-on-lan:             default
802-3-ethernet.wake-on-lan-password:    --
ipv4.method:                            shared
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       ""
ipv4.dns-priority:                      0
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.dad-timeout:                       -1 (default)
GENERAL.NAME:                           ethShared
GENERAL.DEVICES:                        eth0
GENERAL.STATE:                          activated
GENERAL.DEFAULT:                        yes
GENERAL.DEFAULT6:                       no
GENERAL.SPEC-OBJECT:                    --
GENERAL.VPN:                            no
GENERAL.ZONE:                           --
GENERAL.MASTER-PATH:                    --
IP4.ADDRESS[1]:                         10.42.0.1/24
IP4.ADDRESS[2]:                         169.254.15.88/16
IP4.GATEWAY:                            0.0.0.0
IP4.ROUTE[1]:                           dst = 10.42.0.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[2]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 202
IP4.ROUTE[3]:                           dst = 0.0.0.0/0, nh = 0.0.0.0, mt = 202

ベストアンサー1

私は解決策を見つけることができませんでしたが、少なくともうまくいく解決策を見つけました。この提案に従ってルートインジケータを変更してみました。回答

ipv4.route-metric接続をethSharedより高い値(低い優先順位)に設定すると、169.254.15.88を介した偽のパスにはまったく影響を与えないため、何の影響もありません。

そのため、最終的にipv4.route-metric4Gモデム接続をデフォルトの700から99に設定しました(今はEthernetの202優先順位よりも高い優先順位を持ちます)。

おすすめ記事