☰

일정 시간이 지나면 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 확인자로 사용하는 것으로 보이며 추가로 로컬 네트워크 세그먼트에서 호스트 이름을 확인하는 두 가지 방법, 즉 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.) 텔넷을 사용하여 라우터(192.168.1.1)에 연결하면 라우터에서 192.168.1.190에 액세스할 수 있습니다.

2.)와 함께 RasPi는 여전히 IPv4를 통해 작동하며 직접 쿼리할 때 응답한다는 것을 보여줍니다. 랩톱에서 ARP 확인을 방해할 수 있는 일부 방화벽 규칙을 구현했습니까? 아니면 192.168.1.190에서 IP 주소 충돌이 발생했을 수도 있습니다. 192.168.1.190이 RasPi에 정적으로 할당된 경우 DHCP를 통해 라우터가 동적으로 할당한 주소 범위를 벗어나는 것입니까, 아니면 주소 0.190이 라우터의 DHCP 서버 구성에서 RasPi용으로 예약되어 있습니까?

관련 정보