отсутствующий маршрут для модема Wi-Fi в человечности
После разъединения моего openvpn клиента на Гостеприимных 16,04 машинах я испытываю затруднения при соединении с Интернетом, и кажется, что я пропускаю маршрут на своей таблице маршрутизации IP Ядра.
На машине, которая не работает, я имею:
> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.1 0.0.0.0 UG 600 0 0 wlp4s0
192.168.10.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp4s0
У меня есть очень похожая машина, работающая 16.04, который работает и те же возвраты команды:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.1 0.0.0.0 UG 600 0 0 wlp3s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp3s0
192.168.10.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
Я предполагаю, что они настраиваются автоматически с Wi-Fi и конфигурациями DHCP
Кто-то может сказать мне, как настроить "не рабочую" машину так, чтобы это получило все маршруты?
Следующие команды дают следующие ответы (согласно запросу в комментариях)
> cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search Belkin
и
> ping 127.0.1.1
PING 127.0.1.1 (127.0.1.1) 56(84) bytes of data.
64 bytes from 127.0.1.1: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 127.0.1.1: icmp_seq=2 ttl=64 time=0.040 ms
64 bytes from 127.0.1.1: icmp_seq=3 ttl=64 time=0.044 ms
64 bytes from 127.0.1.1: icmp_seq=4 ttl=64 time=0.038 ms
64 bytes from 127.0.1.1: icmp_seq=5 ttl=64 time=0.038 ms
64 bytes from 127.0.1.1: icmp_seq=6 ttl=64 time=0.044 ms
64 bytes from 127.0.1.1: icmp_seq=7 ttl=64 time=0.044 ms
^C
--- 127.0.1.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 5997ms
rtt min/avg/max/mdev = 0.035/0.040/0.044/0.006 ms
1 ответ
Хм, я удалил тот маршрут из своей машины и все еще могу достигнуть Интернета. Следовательно я не так уверен, что это - то, что предотвращает Вас от "соединения до Интернета".
Возможно, Вы просто не способны разрешать имена?
Можно проверить это с dig. Это то, как dig твердость www.google.com для меня:
$ dig www.google.com A +short
108.177.126.105
108.177.126.106
108.177.126.99
108.177.126.103
108.177.126.104
108.177.126.147
Править:
Если это не решает, проверьте, что у Вас есть один или несколько настроенных серверов имен и что Вы можете (IP) достигать по крайней мере одного из них:
$ cat /etc/resolv.conf
...
nameserver 10.20.30.41
nameserver 10.20.30.42
В этом примере машины в 10.20.30.41 и 10.20.30.42 настроены для разрешения имен (т.е.: выройте получит доступ к тем тем машинам на порте 53 по умолчанию для разрешения www.cisco.com к IP-адресу).
Таким образом те две машины, как ожидают, будут достижимы и иметь сервис DNS, слушающий на порте 53.
Теперь попытайтесь проверить с помощью ping-запросов те две машины, чтобы видеть, достижимы ли они:
$ ping 10.20.30.41
...
64 bytes from 10.20.30.41: icmp_seq=1 ttl=255 time=0.194 ms
64 bytes from 10.20.30.41: icmp_seq=2 ttl=255 time=0.209 ms
64 bytes from 10.20.30.41: icmp_seq=3 ttl=255 time=0.235 ms
^C
Предыдущий вывод показывает, что машина в 10.20.30.41 достижима. Если бы это не были Вы, то не видел бы вывода (до Вас ^C).
Edit2:
В Ubuntu 16.04 файл /etc/resolv.conf содержит a nameserver 127.0.1.1 запись, что означает, должна быть сервером DNS на локальной машине.
Действительно Ubuntu 16.04 выполняет Dnsmasq, который действует как маленький локальный сервер DNS. Dnsmasq обрабатывается NetworkManager по умолчанию.