1

Я потратил несколько дней на то, чтобы настроить 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

netplan-YAML:

network:
    renderer: networkd
    ethernets:
        enp1s0:
            addresses: []
            dhcp4: true
        enp2s0:
            addresses: [192.168.1.1/24]
            gateway4: 192.168.0.1
            dhcp4: false
            nameservers:
              search: [home]
              addresses: [192.168.0.1,8.8.8.8,8.8.4.4]
    version: 2

Я уверен, что перепутал это по пути. Некоторое время я был в состоянии разрешить 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 у меня должен был быть определен только один шлюз. Я решил, что шлюз должен быть тем, который показывает выход, и обновил конфигурацию как таковую, см. Ниже:

network:
    renderer: networkd
    ethernets:
        enp1s0:
            addresses: [192.168.0.205/24]
            dhcp4: true
            gateway4: 192.168.0.1
        enp2s0:
            addresses: [192.168.1.1/24]
            dhcp4: false
            nameservers:
              search: [home]
              addresses: [192.168.0.1,8.8.8.8,8.8.4.4]
    version: 2

Это сработало некоторое время. Я мог бы даже разрешить «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

И Клиент получил интернет. Я сделаю это правило пересылки постоянным следующим. Скорее всего, теперь все будет хорошо ... посмотрим!

1 ответ1

3

Исходя из вашей постановки проблемы, у вас есть что-то вроде этого, да?

Client         <--->    LAN-Router   <--->     WAN-Router  <---> Internet
192.168.1.181   192.168.1.1    192.168.0.205   192.168.0.1

IP-адрес шлюза клиента настроен на 192.168.0.1, который является IP-адресом маршрутизатора WAN. Как клиент узнает, как добраться до 192.168.0.1?

Помните, что адреса шлюза определяются как позволяющие компьютеру знать, как отправлять трафик на следующий компьютер или маршрутизатор, следующий переход. Если необходимо указать какой-либо адрес, клиент может добраться до него, обычно в той же подсети, что и клиент. Итак, если вы измените шлюз своего клиента на 192.168.1.1, у вас все будет хорошо.

Надеюсь это поможет.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .