☰

一定時間が経過すると、LANの宛先ホストにアクセスできなくなります。

tag-icon • tag-icon networking iptables routing dd-wrt
一定時間が経過すると、LANの宛先ホストにアクセスできなくなります。

私の内部ネットワークには次の設定があります。

  • ルータ - 192.168.1.1 - dd-wrt実行中
  • rasberrypi - 192.168.1.190 (rp1.local) - Rasberry Pi オペレーティングシステムの実行
  • ノートブック - 192.168.1.185 - Ubuntu実行
  • 電話数通

すべてが期待どおりに動作します。 rp1.localまたは192.168.1.190に接続できますが、不明な奇妙な動作があります。

  1. すべてが正常です
  2. 2023-12-27 22:00 - ホスト名を解決できないため、ラップトップからrp1.localに接続できませんが、まだIPアドレス192.168.1.190に接続できます。
  3. 2023-12-28 01:00 - まだ 192.168.1.190 に接続が可能です
  4. 2023-12-28 11:00 - ラップトップはRasberry Pi IPアドレス192.168.1.190（ERR_ADDRESS_UNREACHABLE /ターゲットホストに接続できません）に接続できません（ping / http）一部の電話機はまだこのIPアドレスに接続できます。
  5. 2023-12-28 15:00 - このIPアドレスにはどの電話も接続できません

その間、ルータ192.168.1.1に接続し続け、そのルータから192.168.1.190（またはrp1）にアクセスできます。

これは何度も起こりましたが、ここ数時間で解決されました。

その他の情報：

ラップトップから：

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 74:d0:2b:0a:04:2c brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6c:71:d9:9c:82:4d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.185/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 3925466sec preferred_lft 3925466sec
    inet6 fe80::352b:2ef9:850:124e/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

-----

resolvectl
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp3s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp2s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

-----

grep hosts /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

ラズベリーパイ

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether d8:3a:dd:34:c7:01 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d8:3a:dd:34:c7:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.190/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 3927658sec preferred_lft 3927658sec
    inet6 fe80::a22e:9352:19e5:9fab/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

-----

resolvectl
Failed to get global data: Failed to activate service 'org.freedesktop.resolve1': timed out (service_start_timeout=25000ms)

# but it wasn't there, so I had installed sudo apt-get install systemd-resolved

-----

grep hosts /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

ルータから

ip addr
1: lo: <LOOPBACK,MULTICAST,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc sfq state UP qlen 1000
    link/ether 70:4f:57:8f:19:e6 brd ff:ff:ff:ff:ff:ff
3: vlan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP 
    link/ether 70:4f:57:8f:19:e6 brd ff:ff:ff:ff:ff:ff
4: vlan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 70:4f:57:8f:19:e6 brd ff:ff:ff:ff:ff:ff
    inet 10.2.236.203/24 brd 10.2.236.255 scope global vlan2
       valid_lft forever preferred_lft forever
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 70:4f:57:8f:19:e6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
12: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000
    link/ether 70:4f:57:8f:19:e8 brd ff:ff:ff:ff:ff:ff
13: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP 
    link/ether 70:4f:57:8f:19:e5 brd ff:ff:ff:ff:ff:ff

ルータでいくつかのポートを開くためのいくつかのルールを手動で追加しましたが、IPテーブルの出力からどのポートを知ることは困難です。さらに、そのような行動につながらない可能性も高いです。

どんなアイデアがありますか？

ベストアンサー1

1.）ホスト名を解決できないため、ラップトップからrp1.localに接続できない場合があります。

ラップトップはルータをDNSリゾルバとして使用しているように見え、さらにローカルネットワークセグメントでホスト名を解決する2つの方法、つまりLLMNR（にsystemd-resolved設定を介して+LLMNR）とmDNS（を介してmdns4_minimal）がありますnsswitch.conf。

systemd-resolvedこれまでRasPiにインストールしておらず、llmnrdRasPiが実行されていない限り、RasPiにLLMNRクエリに応答できるエントリはありません。したがって、mDNSがRasPiホスト名を解決するための最も可能性の高い方法です。 RasPiの回答者コンポーネントは、avahi-daemonRasPi OSと他のほとんどのLinuxディストリビューションの基本インストールの一部です。

したがって、これは mDNS 検証に問題があることを示します。 mDNSがマルチキャストを使用していることを考慮すると、いくつかの問題が発生する可能性があります。

  • UDPポート5353をフィルタリングしましたか？
  • マルチキャストアドレス範囲（224.0.0.0...239.255.255.255）をフィルタリングしましたか？
  • IGMPプロトコルをフィルタリングしましたか？それともIGMPスヌーピングを使用するネットワークスイッチはありますか？ IGMPスヌーピングが機能している場合は、IGMPクエリーも必要です。それ以外の場合は、スヌーピングするIGMPレポートがなく、スイッチは最終的に誰もマルチキャストトラフィックを転送する必要がないと結論付け、転送を中断します。

2.）1が発生すると、数時間後（ノートブックを再起動した後でも）ラップトップはrasberry pi IPアドレス192.168.1.190（ERR_ADDRESS_UNREACHABLE /ターゲットホストに接続できません）に接続できません（ping / http）。

@Bibがコメントしたように、これはWiFiスリープの結果かもしれません。 Bibの推奨事項iw dev wlan0 set power_save offは、次の再起動までオフにするか、RasPiでNetworkManagerを使用している場合は永久に無効にすることですnmcli c mod <connection name> 802-11-wireless.powersave disable。

3.) 2回発生すると、一部の電話機は引き続きアクセスできますが、一部はアクセスできません。

これは、一部の電話機のmDNS / ARPキャッシュライフサイクルが異なるためです。デフォルトでは、RasPi はスリープのため一時的に mDNS または ARP クエリに応答できなくなる可能性がありますが、誰かが既に MAC アドレスを知っていてパケットを送信すると、RasPi が起きて応答します。

4.）Telnetを使用してルーター（192.168.1.1）に接続すると、ルーターは192.168.1.190にアクセスできます。

2.）と一緒に、RasPiはまだIPv4を介して動作し、直接クエリに応答することを示しています。ラップトップでARP検証を妨げる可能性があるいくつかのファイアウォールルールを実装しましたか？あるいは、192.168.1.190でIPアドレスの競合が発生した可能性があります。 192.168.1.190がRasPiに静的に割り当てられている場合、DHCPを介してルータが動的に割り当てたアドレスの範囲外ですか？

おすすめ記事