Разрешение DNS требует беспроводного канала?

У меня есть Lenovo Thinkpad X220 под управлением Ubuntu 18.04. Это имеет порт Ethernet и беспроводную карту. Насколько сети идут, все было автоматически настроено с помощью значений по умолчанию во время установки. В получающейся установке только работает разрешение DNS, когда беспроводной интерфейс активен и подключен. Под предыдущими версиями Ubuntu DNS решил бы или по проводным или по беспроводным каналам, в зависимости от которых было активно.

Я провел довольно много времени, пытаясь понять, как сети Linux настраиваются и управляются и смотрятся много файлов и выполняют много запросов, но откровенно у меня нет требования уложить через такое большое количество детали, которая может представлять интерес только для администраторов сервера. Я получаю это, сетевая подсистема полнофункциональна и гибка, но мой - очень простой вариант использования, и я тону подробно здесь.На помощь!!

Я достиг точки, где я вижу это в выводе systemd-resolve --status :

 Link 3 (wlp3s0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 172.28.16.1

Link 2 (enp0s25)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Я думаю, что это объясняет, почему разрешение DNS происходит по беспроводной связи (wlp3s0), а не проводной канал (enp0s25). Но как я могу заставить проводной канал использоваться вместо этого (или также)? Я могу изменить некоторый конфигурационный файл или дать некоторую команду systemd-твердости, чтобы заставить его рассмотреть использование enp0s25 для DNS?

Обновление: вывод от ifconfig и arp:

mark@MESX220:~$ ifconfig -a
enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.28.16.48  netmask 255.255.255.0  broadcast 172.28.16.255
        inet6 fe80::f2de:f1ff:fe91:692b  prefixlen 64  scopeid 0x20<link>
        ether f0:de:f1:91:69:2b  txqueuelen 1000  (Ethernet)
        RX packets 4444447  bytes 6308844438 (6.3 GB)
        RX errors 0  dropped 62  overruns 0  frame 0
        TX packets 1932598  bytes 156360177 (156.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf2500000-f2520000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 303309  bytes 15241987 (15.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 303309  bytes 15241987 (15.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.28.16.168  netmask 255.255.255.0  broadcast 172.28.16.255
        inet6 fe80::85c3:619d:5f54:95df  prefixlen 64  scopeid 0x20<link>
        ether 08:11:96:58:82:bc  txqueuelen 1000  (Ethernet)
        RX packets 63862  bytes 20011006 (20.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2859  bytes 572860 (572.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

mark@MESX220:~$ arp -a
? (172.28.16.70) at dc:3a:5e:fc:e4:15 [ether] on enp0s25
POPLARDS (172.28.16.16) at 00:11:32:0e:f6:02 [ether] on enp0s25
? (172.28.16.32) at 00:15:99:ed:da:64 [ether] on enp0s25
router.asus.com (172.28.16.1) at 38:2c:4a:aa:75:18 [ether] on enp0s25
? (172.28.16.33) at 70:5a:0f:9e:c1:06 [ether] on enp0s25
? (172.28.16.70) at dc:3a:5e:fc:e4:15 [ether] on wlp3s0
? (172.28.16.144) at 34:38:b7:2a:1e:e0 [ether] on enp0s25
router.asus.com (172.28.16.1) at 38:2c:4a:aa:75:18 [ether] on wlp3s0
? (172.28.16.64) at c8:3a:6b:ac:6e:66 [ether] on wlp3s0
? (172.28.16.64) at c8:3a:6b:ac:6e:66 [ether] on enp0s25
0
задан 22 December 2018 в 07:20

1 ответ

Право, я наконец понял, какова проблема. Я установил статический IP-адрес для проводного интерфейса, но я не предоставил адрес для разрешения DNS. Я добавил адрес DNS (мой маршрутизатор) и перезапустил интерфейс, и теперь он счастливо разрешает DNS, даже когда беспроводной интерфейс снижается.

Я предполагаю, что предположил, что система предположит, что могла разрешить DNS через адрес шлюза. Это, кажется, проложило себе путь в предыдущих выпусках.

0
ответ дан 26 October 2019 в 19:15

Другие вопросы по тегам:

Похожие вопросы: