☰

작동하는 인터넷 연결을 설정하는 데 필요한 것(ubuntu 22.04 및 systemd)

tag-icon • tag-icon linux ubuntu networking networkmanager
작동하는 인터넷 연결을 설정하는 데 필요한 것(ubuntu 22.04 및 systemd)

나 거기 가봤 어약간의 문제가 있습니다.내 우분투 22.04 상자에.

이는 인터넷 연결이 어떻게 작동하는지 이해하는 데 몇 가지 질문을 제기합니다. 내가 이해하는 바에 따르면 인터넷 연결이 작동하려면 다음이 필요합니다.

  1. 게이트웨이 역할을 하는 라우터에 연결
  2. DHCP를 통해 라우터가 할당한 IP 주소
  3. DNS 이름 서버 주소는 DHCP를 통해 라우터에서도 제공됩니다.

이는 필요하지만 충분하지 않은 것 같습니다. 또 무엇이 필요합니까?

systemd에서 NetworkManager는 "네트워크 연결을 활성화합니다". 이는 최소한 1-3점을 다룹니다.

나는 다음과 같은 상황을 보았습니다.

  • 연결이 "활성화"되었습니다
  • 할당된 IP 주소가 정확합니다.
  • 할당된 DNS 서버가 정확합니다.

하지만 복구 모드를 사용하거나 동일한 LAN에 있는 다른 PC를 사용하지 않는 한 인터넷과 통신할 수 없습니다.

  • 핑 시간 초과
  • nslookup 시간 초과
  • LAN 아이콘에는 물음표가 겹쳐져 있습니다.

나는 "그냥 일하는 것"에 너무 익숙해서 다음과 같이 물어볼 필요가 있습니다.

Q: 네트워크가 실제로 작동하려면 "네트워크 연결 활성화" 외에 무엇을 해야 합니까?

네트워크 아이콘의 물음표는 무엇을 의미하나요? (시스템 업데이트 이후에는 더 이상 나타나지 않습니다)

"네트워크 연결 활성화"가 실제로 무엇을 의미하는지 묻고 있습니까?

이것은 의도적으로 일반적인 질문입니다. 구체적인 예시 질문은 첫 번째 줄에 링크된 질문을 참조하세요.

작업 사례의 주요 차이점은 다음 줄입니다 route.

default         _gateway        0.0.0.0         UG    100    0        0 enp0s31f6

자세한 내용은 아래를 참조하세요.

다음은 관련 없는 세부정보일 수 있습니다.

핑 추적 쇼의 경우:

socket()
connect()  - "8.8.8.8"
setsockopt()
newfsstatat()
ioctl(TCGETS)
ioctl(TIOCGWINSZ)
sendto() "8.8.8.8"
recvmsg()

그리고 recvmsg()는 시간이 초과될 때까지 EAGAIN과 함께 실패합니다. 그래서 어떤 의미에서 커널은 connect() 호출이 성공하도록 허용하지만 연결이 데이터 흐름을 허용하지 않는 것 같습니다.

그러나 nslookup strace의 경우 다음이 표시됩니다.

connect("127.0.0.53")

올바른 네임서버가 아닙니다.이것관련성이 있을 수 있습니다. 이를 토대로 보면 뭔가가 127.0.0.53 에서 듣고 있는 것 같습니다 ss.

>tracepath -n -p 55 8.8.8.8.8
1?: [LOCALHOST]   pmtu 1500
1: no reply
...

그리고 그 recvmesg()가 다시 시간 초과됩니다(EAGAIN을 반복한 후).

특정 문제에 대한 자세한 내용:

작동 안함:

> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    100    0        0 enp0s31f6
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 virbr0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
> 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: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:4d:7b:64:62:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 854001sec preferred_lft 854001sec
    inet6 fe80::ba46:11c7:b4d1:16b3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlx503eaa945dc9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 50:3e:aa:94:5d:c9 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ed:8b:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:fe:8d:1b:aa brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

# inxi -N
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB driver: r8188eu

# netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0   1500        0      0      0 0             0      0      0      0 BMU
enp0s31f  1500    27075      0      0 0          1608      0      0      0 BMRU
lo       65536     5441      0      0 0          5441      0      0      0 LRU
virbr0    1500        0      0      0 0             0      0      0      0 BMU

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s31f6
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 virbr0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0

이후 작업 사례:

  • 복구 모드로 부팅
  • 네트워크 활성화
  • 정상적인 시작 복원

새로운 출력:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s31f6
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp0s31f6
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp0s31f6
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp0s31f6
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0   1500        0      0      0 0             0      0      0      0 BMU
enp0s31f  1500    85232      0      1 0         46876      0      0      0 BMRU
lo       65536     4250      0      0 0          4250      0      0      0 LRU
virbr0    1500        0      0      0 0             0      0      0      0 BMU

$ inxi -N
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB
    driver: r8188eu

$ 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: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:4d:7b:64:62:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 862734sec preferred_lft 862734sec
    inet6 fe80::ba46:11c7:b4d1:16b3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlx503eaa945dc9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 50:3e:aa:94:5d:c9 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ed:8b:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:05:f9:90:04 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

답변1

귀하의 라우터는 귀하의 인터넷 서비스 공급자에 대한 활성 업스트림 연결이 없더라도 귀하가 나열한 세 가지 기능을 모두 제공할 수 있습니다. 이렇게 하면 라우터의 인터넷 연결이 제대로 구성되지 않은 경우에도 웹 브라우저를 사용하여 라우터의 구성 인터페이스(사용 가능한 경우)에 액세스할 수 있습니다.

따라서 라우터 자체에서 몇 가지 진단 정보를 얻으려고 노력해야 합니다. 표시등이 있으면 어떻게 작동합니까? 라우터의 웹 인터페이스에 액세스할 수 있는 경우 상태 페이지에 인터넷 연결이 정상이라고 표시됩니까?

또한 라우터가 "어린이 보호" 기능을 갖추고 있거나 특정 클라이언트 시스템에 대한 인터넷 연결만 허용하도록 제한될 가능성도 있습니다. 예를 들어, 라우터의 지나치게 엄격한 방화벽 규칙으로 인해 증상이 나타날 수 있습니다.

최신 운영 체제에서 "네트워크 연결 활성화"에는 일반적으로 테스트가 포함됩니다. 운영 체제는 연결이 실제로 작동하는지 확인하기 위해 일부 운영 체제 공급업체가 관리하는 클라우드 서비스에 연결을 시도합니다. 그렇지 않은 경우 시스템은 업데이트 다운로드를 시도하지 않으며 일반적으로 인터넷 연결이 부족하다는 것을 나타냅니다(예: 연결 아이콘 위에 물음표 표시).

NetworkManager에서 이러한 연결 테스트는 구성 가능하고 선택 사항이지만 Ubuntu에서는 기본적으로 이를 활성화하는 것 같습니다.

귀하의 라우터는 귀하의 인터넷 서비스 공급자에 대한 활성 업스트림 연결이 없더라도 귀하가 나열한 세 가지 기능을 모두 제공할 수 있습니다. 이렇게 하면 라우터의 인터넷 연결이 제대로 구성되지 않은 경우에도 웹 브라우저를 사용하여 라우터의 구성 인터페이스(사용 가능한 경우)에 액세스할 수 있습니다.

따라서 라우터 자체에서 몇 가지 진단 정보를 얻으려고 노력해야 합니다. 표시등이 있으면 어떻게 작동합니까? 라우터의 웹 인터페이스에 액세스할 수 있는 경우 상태 페이지에 인터넷 연결이 정상이라고 표시됩니까?

또한 라우터가 "어린이 보호" 기능을 갖추고 있거나 특정 클라이언트 시스템에 대한 인터넷 연결만 허용하도록 제한될 가능성도 있습니다. 예를 들어, 라우터의 지나치게 엄격한 방화벽 규칙으로 인해 증상이 나타날 수 있습니다.

최신 운영 체제에서 "네트워크 연결 활성화"에는 일반적으로 테스트가 포함됩니다. 운영 체제는 연결이 실제로 작동하는지 확인하기 위해 일부 운영 체제 공급업체가 관리하는 클라우드 서비스에 연결을 시도합니다. 그렇지 않은 경우 시스템은 업데이트 다운로드를 시도하지 않으며 일반적으로 인터넷 연결이 부족하다는 것을 나타냅니다(예: 연결 아이콘 위에 물음표 표시).

NetworkManager에서 이러한 연결 테스트는 구성 가능하고 선택 사항이지만 Ubuntu에서는 기본적으로 이를 활성화하는 것 같습니다.

소켓() 연결() - "8.8.8.8" setockopt() newfsstatat() ioctl(TCGETS) ioctl(TIOCGWINSZ) sendto() "8.8.8.8" recvmsg()

따라서 성공한다면 connect()커널 sendto()이 아는 한 핑 패킷은예전에는보내다.

에 따르면 man 2 recvmsgEAGAIN 오류는 다음을 의미합니다.

EAGAIN 또는 EWOULBlock

소켓이 비차단으로 표시되어 수신 작업이 차단되거나, 수신 시간 초과가 설정되어 데이터를 수신하기 전에 시간 초과가 만료되었습니다. POSIX.1은 이 경우 오류 중 하나가 반환되는 것을 허용하고 이러한 상수가 동일한 값을 가질 것을 요구하지 않으므로 이식 가능한 응용 프로그램은 두 가지 가능성을 모두 확인해야 합니다.

다시 말해서,응답을 받지 못했습니다. 원인을 설명하는 ICMP 오류 패킷이 함께 제공되지 않으면 시스템은 추가 설명을 제공할 수 없습니다. 일반적으로 이는 일부 오류 또는 구성된 제한(예: 방화벽 규칙)으로 인해 나가는 핑 패킷이나 들어오는 핑 응답이 라우터 또는 라우터의 특정 지점에서 삭제된다는 의미입니다.

이 경우 가능한 테스트 중 하나는 입니다 traceroute. 방화벽은 현대 네트워크 어디에나 존재하기 때문에 작동할 것으로 예상되는 특정 포트로 연결되는 TCP 또는 UDP 기반 추적 경로를 특별히 사용하는 것이 유용하다는 것을 알았습니다. 따라서 이 경우:

sudo traceroute -n -T -p 53 8.8.8.8

Google의 잘 알려진 DNS 서버의 포트 53에 대한 TCP 기반 추적 경로를 시도합니다. DNS 프로토콜은 TCP와 UDP를 모두 사용하고 TCP 포트는 Traceroute에 대해 보다 강력한 응답을 제공하므로 나가는 패킷이 응답 수신을 중단하기 전에 도달할 수 있는 거리를 알려줄 수 있습니다.

패킷 전송 시간과 함께 출력에 표시되는 마지막 IP 주소가 traceroute라우터의 IP 주소인 경우 문제는 라우터에 있거나 라우터와 ISP의 라우터 사이에 있는 것입니다.

라우터의 IP 주소 뒤에 다른 IP 주소가 표시되면 문제는 ISP의 장비 내부(가능성이 높음) 또는 ISP와 다른 조직 간의 인터넷 백본 연결(일반적으로 다중 중복이므로 가능성은 낮음)에 있는 것입니다. 두 경우 모두 직접 해결하기 위해 할 수 있는 일은 없습니다. 최선의 방법은 ISP에 문제를 보고하고 ISP가 문제를 해결하거나 문제가 발생한 트래픽을 다시 라우팅할 때까지 기다리는 것입니다.

그러나 nslookup strace의 경우 다음이 표시됩니다.

연결("127.0.0.53")

올바른 서버 이름이 아닙니다.이것관련성이 있을 수 있습니다.

링크된 질문에 대한 답변을 읽지 않으셨나요? 귀하의 시스템은 를 사용하고 있습니다 systemd-resolved. 대부분의 애플리케이션은 glibc의 호스트 이름 확인 API를 사용하며, hosts: ...resolve...귀하의 키워드는 /etc/nsswitch.conf직접 통신하도록 지시합니다 systemd-resolved. 이전 버전과의 호환성 과 일부 레거시 애플리케이션 및 DNS 관련 도구(예: DNS)의 경우 DNS 확인자 프록시는 nslookup포트 53(즉, 대체 IP 주소) 127.0.0.53에서 유지 관리됩니다 . 실행하여 시스템의 실제 DNS 설정을 확인하고 이전 설정은 무시해야 합니다 .systemd-resolved/etc/resolv.conflocalhostresolvectl/etc/resolv.conf

그러나 여기에 문제가 있습니다. IP로 8.8.8.8을 핑할 수도 없기 때문에 DNS 확인에 대해 걱정하기 전에 IP 연결 문제를 해결해야 합니다.

여러분을 실망시킬 수 있는 새로운 점은 최신 운영 체제가 개인 정보 보호를 위해 부팅할 때마다 기본적으로 MAC 주소를 무작위로 지정할 수 있다는 것입니다. 이러한 유형의 무작위화는 라우터가 시스템별 IP 예약 또는 기타 호스트별 설정으로 구성된 경우 문제를 일으킬 수 있습니다.

NetworkManager 설정에는 MAC 주소 무작위화를 비활성화하는 옵션이 포함되어야 합니다. 네트워크를 시작하기 위해 단순화된 프로세스를 사용할 수 있으므로 복구 모드에서는 무작위화를 건너뛸 수 있습니다.

관련 정보