質問: 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そして、クライアントはインターネットを手に入れました。次に、この転送ルールを永続的にします。おそらくこれからは大丈夫でしょう......見てみましょう!
回答: あなたの問題の記述に基づいて、あなたはこのようなものを持っています、そうですか?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に変更すれば、問題はありません。お役に立てれば。