Я потратил несколько дней на то, чтобы настроить DNS и DHCP с помощью dnsmasq и новый способ работы с netplan.
WAN-router is on 192.168.0.1 - works fine LAN-router (Ubuntu 18.04) received 192.168.0.205 on enp1s0 and is serving addresses on enp2s0; 192.168.1.1 - DHCP works fine, handing out 192.168.1.x addresses as it should. Can ping google.com Client laptop is on 192.168.1.181 - Gets IP, can ping LAN-router, can ping IP addresses directly (such as 8.8.8.8) but traceroute and DNS does not work
Это мой конфиг dnsmasq:
bogus-priv strict-order filterwin2k expand-hosts domain=home no-resolv listen-address=127.0.0.1 listen-address=192.168.1.1 #DHCP range dhcp-range=192.168.1.1,192.168.1.254,72h dhcp-option=option:router,192.168.0.1 # Upstream name servers server=192.168.0.1 server=8.8.4.4 server=8.8.8.8
Состояние dnsmasq, ботинки нормально:
Nov 15 06:54:17 router systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... Nov 15 06:54:17 router dnsmasq[2000]: dnsmasq: syntax check OK. Nov 15 06:54:17 router dnsmasq[2030]: started, version 2.79 cachesize 150 Nov 15 06:54:17 router dnsmasq[2030]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify Nov 15 06:54:17 router dnsmasq-dhcp[2030]: DHCP, IP range 192.168.1.1 -- 192.168.1.254, lease time 3d Nov 15 06:54:17 router dnsmasq[2030]: using nameserver 8.8.8.8#53 Nov 15 06:54:17 router dnsmasq[2030]: using nameserver 8.8.4.4#53 Nov 15 06:54:17 router dnsmasq[2030]: using nameserver 192.168.0.1#53 Nov 15 06:54:17 router dnsmasq[2030]: read /etc/hosts - 7 addresses Nov 15 06:54:17 router systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
IP-адрес шоу:
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:e8:4c:68:61:52 brd ff:ff:ff:ff:ff:ff inet 192.168.0.205/24 brd 192.168.0.255 scope global dynamic enp1s0 valid_lft 1962sec preferred_lft 1962sec inet6 fe80::2e8:4cff:fe68:6152/64 scope link valid_lft forever preferred_lft forever 3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:e8:4c:68:61:53 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global enp2s0 valid_lft forever preferred_lft forever inet6 fe80::2e8:4cff:fe68:6153/64 scope link valid_lft forever preferred_lft forever
Я уверен, что перепутал это по пути. Некоторое время я был в состоянии разрешить DNS для имен с клиентского ноутбука, но фактическая передача данных была невозможна, поэтому фактически не было возможности фактически достичь Интернета.
Это все немного ново для меня, поэтому буду признателен за любые указатели.
редактировать--
Топология - обновлено:
Client (192.168.1.2) -> Unifi AP (192.168.1.71) -> Lan-Router [192.168.1.1 -> 192.168.0.205] -> WAN-router (192.168.0.1) -> Internet
Когда я узнал больше о Netplan и dnsmasq против маршрутизации / сетей в целом, я понял, что в конфигурации Netplan у меня должен был быть определен только один шлюз. Я решил, что шлюз должен быть тем, который показывает выход, и обновил конфигурацию как таковую, см. Ниже:
Это сработало некоторое время. Я мог бы даже разрешить «router: xxxx» в браузере клиента.
Затем, без изменений в Lan-Router, он перестал работать. Это произошло, может быть, через 30-60 минут после начала работы.
Ping on Client разрешает DNS, но не может принимать пакеты, что указывает на некоторые проблемы с маршрутизацией:
PING google.com (172.217.20.78): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 ^C --- google.com ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss
Traceroute на клиенте не идет дальше, чем LAN-Router:
traceroute to google.com (172.217.20.78), 64 hops max, 52 byte packets 1 * router (192.168.1.1) 1.391 ms 2.486 ms 2 *^C
IP-маршрут на Lan-Router:
default via 192.168.0.1 dev enp1s0 proto static default via 192.168.0.1 dev enp1s0 proto dhcp src 192.168.0.205 metric 100 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.205 192.168.0.1 dev enp1s0 proto dhcp scope link src 192.168.0.205 metric 100 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.1
маршрут -n на LAN-маршрутизаторе:
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 enp1s0 0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 enp1s0 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 enp1s0 192.168.0.1 0.0.0.0 255.255.255.255 UH 100 0 0 enp1s0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp2s0
Возможно, в тот период произошел перезапуск, но я не помню, чтобы это было именно то, что вызвало падение.
Любые указатели относительно того, как устранить неполадки, будут оценены.
редактировать
Решено - пока. Отсутствовал оператор маршрутизации (должно быть после перезагрузки)
Я добавил это: phil @ router: ~ $ sudo iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE
И Клиент получил интернет. Я сделаю это правило пересылки постоянным следующим. Скорее всего, теперь все будет хорошо ... посмотрим!
Рад, что вы смогли найти проблему и исправить ее.
Lewis M 5 лет назад
1
1 ответ на вопрос
3
Lewis M
Исходя из вашей постановки проблемы, у вас есть что-то вроде этого, да?
IP-адрес шлюза клиента настроен на 192.168.0.1, который является IP-адресом маршрутизатора WAN. Как клиент узнает, как добраться до 192.168.0.1?
Помните, что адреса шлюза определяются как позволяющие компьютеру знать, как отправлять трафик на следующий компьютер или маршрутизатор, следующий переход. Если необходимо указать какой-либо адрес, клиент может добраться до него, как правило, в той же подсети, что и клиент. Итак, если вы измените шлюз своего клиента на 192.168.1.1, у вас все будет хорошо.
Надеюсь это поможет.
Спасибо за ваш ответ. Мне нужно убедиться, что шлюз клиента действительно 192.168.0.1. Если это так, возможно ли во время соединения принудить клиента использовать 192.168.1.1 в качестве шлюза?
Phil 5 лет назад
0
Я вижу сейчас. «Option: router» указывает шлюз по умолчанию для клиента, да? Я изменю это сегодня вечером, спасибо за головы :)
Phil 5 лет назад
0
Я изменил клиентский шлюз на 192.168.1.1, но безрезультатно. Хороший улов, хотя, я уверен, что это был один шаг в правильном направлении
Phil 5 лет назад
0
Какие команды вы выполняете? Какие сообщения об ошибках вы получаете? Не могли бы вы отредактировать свой оригинальный пост, чтобы включить их?
Lewis M 5 лет назад
0
обновил вопрос с некоторым прогрессом, почти там чувствую
Phil 5 лет назад
0