Ich ziehe hier tagelang an den Haaren, DNS und DHCP mit dnsmasq einrichten und die neue Art, mit netplan etwas zu tun.
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
Dies ist meine Dnsmasq-Konfiguration:
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
Status von Dnsmasq, Stiefel fein:
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-Adresse anzeigen:
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
Ich bin sicher, ich habe es auf dem Weg verwirrt. Ich konnte DNS-Namen für einige Zeit vom Client-Laptop auflösen, aber es war kein tatsächlicher Datentransport möglich, daher war es praktisch nicht möglich, das Internet praktisch zu erreichen.
Es ist alles ein bisschen neu für mich, ich würde mich über alle Hinweise freuen.
bearbeiten--
Topologie - aktualisiert:
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
Als ich mehr über Netplan vs Dnsmasq vs Routing / Networking im Allgemeinen erfahren habe, habe ich verstanden, dass ich in der Netplan-Konfiguration nur ein Gateway definieren sollte. Ich habe mir gedacht, dass das Gateway der Ausweg sein muss und die Konfiguration als solche aktualisiert hat, siehe unten:
Das hat eine Weile funktioniert. Ich könnte sogar "Router: xxxx" im Browser des Clients auflösen.
Nachdem der Lan-Router nicht geändert wurde, funktionierte er nicht mehr. Dies geschah vielleicht 30-60 Minuten nachdem es angefangen hatte zu arbeiten.
Ping auf Client löst das DNS auf, kann jedoch keine Pakete empfangen, was auf ein Routing-Problem hinweist:
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 on Client kommt nicht weiter als 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-Route am 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
route -n am LAN-Router:
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
In diesem Zeitraum gab es möglicherweise einen Neustart, aber ich kann mich nicht daran erinnern, dass genau dies den Rückgang verursacht hat.
Hinweise zur Fehlerbehebung werden gebeten.
bearbeiten
Gelöst - jetzt. Es war eine Routing-Anweisung fehlt (muss nach dem Neustart gewesen sein)
Ich habe folgendes hinzugefügt: phil @ router: ~ $ sudo iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE
Und der Kunde hat Internet. Ich werde diese Weiterleitungsregel als nächstes dauerhaft machen. Höchstwahrscheinlich wird es von nun an gut sein ... mal sehen!
Ich bin froh, dass Sie das Problem finden und beheben konnten.
Lewis M vor 5 Jahren
1
1 Antwort auf die Frage
3
Lewis M
Basierend auf Ihrer Problemstellung haben Sie so etwas, ja?
Die Gateway-IP des Clients ist auf 192.168.0.1 konfiguriert. Dies ist die IP des WAN-Routers. Wie kann der Kunde wissen, wie er 192.168.0.1 erreicht?
Denken Sie daran, dass Gateway-Adressen definiert sind, damit ein Computer weiß, wie er Datenverkehr an den nächsten Computer oder Router, den nächsten Hop, weiterleiten soll. Wenn es sich um eine Adresse handeln muss, an die der Client gelangen kann, normalerweise in demselben Subnetz wie der Client. Wenn Sie also das Gateway Ihres Clients in 192.168.1.1 ändern, sollten Sie gut sein.
Hoffe das hilft.
Danke für deine Antwort. Ich muss überprüfen, ob das Gateway des Clients tatsächlich 192.168.0.1 ist. Wenn ja, kann der Client zur Verbindungszeit 192.168.1.1 als Gateway verwenden?
Phil vor 5 Jahren
0
Ich sehe jetzt. Die "Option: Router" gibt das Standardgateway für den Client an. Ich werde das heute Abend ändern, danke für die Köpfe nach oben :)
Phil vor 5 Jahren
0
Ich habe das Client-Gateway in 192.168.1.1 geändert, jedoch ohne Erfolg. Guter Fang, ich bin mir sicher, dass dies ein Schritt in die richtige Richtung war
Phil vor 5 Jahren
0
Welche Befehle führen Sie aus? Welche Fehlermeldungen erhalten Sie? Könnten Sie Ihren ursprünglichen Beitrag bearbeiten, um sie aufzunehmen?
Lewis M vor 5 Jahren
0
Ich habe die Frage mit einigen Fortschritten aktualisiert
Phil vor 5 Jahren
0