web-dev-qa-db-ja.com

dnsmasqDNS解決の問題

ここで何日も髪を引っ張って、dnsmasqでDNSとDHCPを設定し、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構成ではゲートウェイを1つだけ定義することになっていることがわかりました。ゲートウェイは、出口を示すものである必要があると考え、構成を更新しました。以下を参照してください。

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を実行すると、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

Lan-RouterのIPルート：

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

lAN上のroute-n-ルーター：

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

そして、クライアントはインターネットを手に入れました。次に、この転送ルールを永続的にします。おそらくこれからは大丈夫でしょう……見てみましょう！

linuxnetworkingdhcpdnsmasqubuntu-18.04
1
Phil

あなたの問題の記述に基づいて、あなたはこのようなものを持っています、そうですか？

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

クライアントのゲートウェイIPは、WANルーターのIPである192.168.0.1に構成されています。クライアントは192.168.0.1に到達する方法をどのように知っていますか？

ゲートウェイアドレスは、次のコンピューターまたはルーター、ネクストホップにトラフィックを送信する方法をコンピューターに通知することとして定義されていることを忘れないでください。クライアントが到達できるアドレスが必要な場合、通常はクライアントと同じサブネット上にあります。したがって、クライアントのゲートウェイを192.168.1.1に変更すれば、問題はありません。

お役に立てれば。

3
Lewis M