|
trisaster
Anmeldungsdatum:
12. April 2020
Beiträge: Zähle...
|
Ich nutze Wireguard primär, um auf ein NAS an einem anderen Standort (statische IP) zuzugreifen, gelegentlich noch auf einen Web-Server im gleichen Netzwerk. So weit ich das verstanden habe, läuft das wie im Wiki beschrieben so ab, dass ich eine Verbindung zum Server in dem lokalen Netz aufbaue und der das dann intern an die anderen Geräte entsprechend der IP weiterleitet. Das hat mit Kubuntu 20.04 super funktioniert. Zugriffe auf IPs in lokalen Netzwerk hat WireGuard an das VPN weitergeleitet, alles andere ging normal raus ins Internet. Das heißt, wenn ich im Browser eine Seite aufrief, sah die Seite die IP von meinem Router. Seit dem Upgrade auf Kubuntu 22.04 funktioniert der Zugriff auf das NAS weiterhin problemlos, aber ich habe keinen Zugriff mehr auf das Internet. Die Ursache kann ich einfach nicht finden. Hab schon viel recherchiert, auf einem Zweitrechner Kubuntu 22.04 neu installiert und die WireGuard-Verbindung neu eingerichtet, aber gleiches verhalten. Liegt also nicht an einem Defekt in der Konfiguration durch das Upgrade. Mit der Gegenstelle dürfte es nach meinem Verständnis nichts zu tun haben, denn die sollte von den Zugriffen auf das "normale" Internet ohnehin nichts mitbekommen. An den DNS-Einstellungen liegt es vermutlich auch nicht. Wenn ich eine IP-Adresse anpinge, läuft das ins Leere. Komischerweise konnte ich 8.8.8.8 erreichen, aber 4.4.4.4 zum Beispiel nicht. Ergibt irgendwie keinen Sinn. Wie habe ich die VPN-Verbindung eingerichtet? Das Schlüsselpaar ist schon erzeugt und da die Kommunikation funktioniert, lasse ich das an der Stelle weg. In den Netzwerkeinstellungen der GUI habe ich eine neue Verbindung vom Typ "WireGuard" erstellt. Im Feld "Privater Schlüssel" habe ich meinen privaten Schlüssel eingetragen. Bei "Gegenstelle":
Öffentlicher Schlüssel: den öffentlichen Schlüssel der Gegenstelle Zulässige IPs: 198.18.7.0/24 Endpunkt-Adresse: Die öffentliche IP-Adresse, über die der Server erreichbar ist Port des Endpunkts: Der entsprechende Port
Im Reiter "IPv4":
Methode: Manuell DNS-Server: 8.8.8.8 Mein Rechner:
Beispielbilder sind angehangen. Wo liegt nun das Problem, hat da jemand eine Idee? Viele Dank im Voraus! Wenn weitere Informationen gebraucht werden, einfach fragen.
Moderiert von kB: Aus dem Forum „Netzwerk und Internetzugang einrichten“ in einen besser passenden Forenbereich verschoben. Bitte beachte die als wichtig markierten Themen („Welche Themen gehören hier her und welche nicht?“) im jeweiligen Forum! Danke.
- Bilder
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
trisaster schrieb: ..., aber ich habe keinen Zugriff mehr auf das Internet. Die Ursache kann ich einfach nicht finden.
Wie sind die Ausgaben von:
ip r g 1.1.1.1
ip r
ping -c 3 1.1.1.1
?
|
|
kB
Supporter, Wikiteam
Anmeldungsdatum:
4. Oktober 2007
Beiträge: 9837
|
Was wurde aktualisiert?
ein Wireguard-Client alle Wireguard-Clients der Wireguard-Server etwas anderes
Es geht um Router/Routing-Funktion. Zeige also bitte die Routen
auf dem Wireguard-Server, auf einem Wireguard-Client, der über den Wireguard-Server Zugang zum Internet hat, auf einem Wireguard-Client, der vor dem Update über den Wireguard-Server Zugang zum Internet hatte, jetzt aber nicht mehr.
|
|
trisaster
(Themenstarter)
Anmeldungsdatum:
12. April 2020
Beiträge: 58
|
Vielen Dank für die Antworten! lubux schrieb: Wie sind die Ausgaben von:
ip r g 1.1.1.1
ip r
ping -c 3 1.1.1.1
?
Hier die Ausgabe: ~$ ip r g 1.1.1.1
1.1.1.1 via 192.168.178.1 dev enp5s0 src 192.168.178.20 uid 1001
cache ~$ ip r
default via 192.168.178.1 dev enp5s0 proto dhcp metric 100
169.254.0.0/16 dev enp5s0 scope link metric 1000
192.168.178.0/24 dev enp5s0 proto kernel scope link src 192.168.178.20 metric 100
198.18.7.0/24 dev VPN-WG proto static scope link metric 50
198.18.7.0/24 dev VPN-WG proto kernel scope link src 198.18.7.3 metric 50 ~$ ping -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=25.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=24.8 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=25.1 ms
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 24.785/25.110/25.426/0.261 ms kB schrieb: Was wurde aktualisiert?
ein Wireguard-Client alle Wireguard-Clients der Wireguard-Server etwas anderes
Die Linux-Distribution auf meinem Rechner und damit mein WireGuard-Client. Die anderen Clienten und der Server wurden nicht verändert. kB schrieb: Es geht um Router/Routing-Funktion. Zeige also bitte die Routen
auf dem Wireguard-Server, auf einem Wireguard-Client, der über den Wireguard-Server Zugang zum Internet hat, auf einem Wireguard-Client, der vor dem Update über den Wireguard-Server Zugang zum Internet hatte, jetzt aber nicht mehr.
Das ist teilweise schwierig, denn auf den Server habe ich keinen Zugriff. Über den sollte mein Internetverkehr aber ohnehin nicht laufen. Da mein Rechner der einzige Linux-Rechner ist, auf dem WireGuard genutzt wird, habe ich noch einmal Kubuntu 20.04 in einer WM installiert und es zusätzlich in Windows 10 in einer VM eingerichtet. Die Ausgabe unter Kubuntu 20.04:
~$ ip -4 route list table all
default via 10.0.2.2 dev enp0s3 proto dhcp metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
169.254.0.0/16 dev enp0s3 scope link metric 1000
198.18.7.0/24 dev VPN-WG proto static scope link metric 50
198.18.7.0/24 dev VPN-WG proto kernel scope link src 198.18.7.3 metric 50
local 10.0.2.15 dev enp0s3 table local proto kernel scope host src 10.0.2.15
broadcast 10.0.2.255 dev enp0s3 table local proto kernel scope link src 10.0.2.15
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 198.18.7.3 dev VPN-WG table local proto kernel scope host src 198.18.7.3
broadcast 198.18.7.255 dev VPN-WG table local proto kernel scope link src 198.18.7.3 Unter Windows 10:
>netstat -rn
===========================================================================
Schnittstellenliste
24...........................WireGuard Tunnel
10...08 00 27 b4 c3 cc ......Intel(R) PRO/1000 MT Desktop Adapter
1...........................Software Loopback Interface 1
===========================================================================
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 10.0.2.2 10.0.2.15 25
10.0.2.0 255.255.255.0 Auf Verbindung 10.0.2.15 281
10.0.2.15 255.255.255.255 Auf Verbindung 10.0.2.15 281
10.0.2.255 255.255.255.255 Auf Verbindung 10.0.2.15 281
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
198.18.7.0 255.255.255.0 Auf Verbindung 198.18.7.3 5
198.18.7.3 255.255.255.255 Auf Verbindung 198.18.7.3 261
198.18.7.255 255.255.255.255 Auf Verbindung 198.18.7.3 261
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.0.2.15 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.0.2.15 281
===========================================================================
Ständige Routen:
Keine
IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
10 281 fe80::/64 Auf Verbindung
10 281 fe80::7b62:d730:18d6:d735/128
Auf Verbindung
1 331 ff00::/8 Auf Verbindung
10 281 ff00::/8 Auf Verbindung
===========================================================================
Ständige Routen:
Keine
Sowohl mit Kubuntu 20.04, als auch mit Windows 10, habe ich Zugriff auf das Internet. Als IP wird mir die IP meines Routers angezeigt. Das heißt, der Internetverkehr läuft nicht über WireGuard. Den Server im entfernten Netzwerk (198.18.7.1) konnte ich anpingen. Der dritte Punkt wäre mein Rechner. Da habe ich es einmal mit und ohne WireGuard ausgeführt. Die folgende Ausgabe war mit WireGuard. Ohne WireGuard fehlen die markierten Zeilen, sonst ist es identisch.
~$ ip -4 route list table all
default via 192.168.178.1 dev enp5s0 proto dhcp metric 100
169.254.0.0/16 dev enp5s0 scope link metric 1000
192.168.178.0/24 dev enp5s0 proto kernel scope link src 192.168.178.20 metric 100
198.18.7.0/24 dev VPN-WG proto static scope link metric 50
198.18.7.0/24 dev VPN-WG proto kernel scope link src 198.18.7.3 metric 50
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 192.168.178.20 dev enp5s0 table local proto kernel scope host src 192.168.178.20
broadcast 192.168.178.255 dev enp5s0 table local proto kernel scope link src 192.168.178.20
local 198.18.7.3 dev VPN-WG table local proto kernel scope host src 198.18.7.3
broadcast 198.18.7.255 dev VPN-WG table local proto kernel scope link src 198.18.7.3
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
trisaster schrieb: ~$ ip r g 1.1.1.1
1.1.1.1 via 192.168.178.1 dev enp5s0 src 192.168.178.20 uid 1001
cache ~$ ping -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=25.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=24.8 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=25.1 ms
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 24.785/25.110/25.426/0.261 ms
Internetzugang funktioniert aber.
|
|
trisaster
(Themenstarter)
Anmeldungsdatum:
12. April 2020
Beiträge: 58
|
lubux schrieb: Internetzugang funktioniert aber.
Ja, mir ist auch aufgefallen, ich kann IPs direkt anpingen, nur URLs funktionieren nicht. Scheint also doch ein DNS-Problem zu sein. Wenn ich im Browser https://40.114.177.156/ (IP-Adresse von DuckDuckGo) aufrufe, bekomme ich eine Sicherheitswarnung, weil das verwendete Zertifikat nur für *.duckduckgo.com gilt. Das heißt, der Browser kann die IP-Adresse aufrufen und das Zertifikat laden. Aber wenn ich https://duckduckgo.com direkt aufrufe, geht es nicht. Mit http werde ich Dann habe ich in Firefox einmal DNS über HTTPS aktiviert, Anbieter Cloudflare. Damit geht's. Die Frage ist, warum DNS nicht funktioniert, obwohl ich in der Konfiguration einen DNS-Server eingetragen habe? Auch bei der physikalischen LAN-Verbindung ist der DNS-Server 1.1.1.1 eingetragen.
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
trisaster schrieb: Die Frage ist, warum DNS nicht funktioniert, obwohl ich in der Konfiguration einen DNS-Server eingetragen habe?
Wie sind die Ausgaben von:
cat /etc/resolv.conf
nc -zv 1.1.1.1 53
host heise.de
host heise.de 1.1.1.1
sudo netstat -tulpena | grep -i 53
?
|
|
trisaster
(Themenstarter)
Anmeldungsdatum:
12. April 2020
Beiträge: 58
|
lubux schrieb: trisaster schrieb: Die Frage ist, warum DNS nicht funktioniert, obwohl ich in der Konfiguration einen DNS-Server eingetragen habe?
Wie sind die Ausgaben von:
cat /etc/resolv.conf
nc -zv 1.1.1.1 53
host heise.de
host heise.de 1.1.1.1
sudo netstat -tulpena | grep -i 53
?
~$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad
search fritz.box ~$ nc -zv 1.1.1.1 53
Connection to 1.1.1.1 53 port [tcp/domain] succeeded! ~$ host heise.de
;; connection timed out; no servers could be reached ~$ host heise.de 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 10 relay.heise.de. ~$ sudo netstat -tulpena | grep -i 53
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 29072 937/systemd-resolve
tcp6 0 0 2003:c8:6f26:e800:55380 2a01:238:20a:202:54:993 VERBUNDEN 1001 49254 2273/betterbird
tcp6 0 0 2003:c8:6f26:e800:55396 2a01:238:20a:202:54:993 VERBUNDEN 1001 49255 2273/betterbird
udp 0 0 127.0.0.1:47786 127.0.0.53:53 VERBUNDEN 1001 160136 2955/firefox
udp 0 0 127.0.0.53:53 0.0.0.0:* 101 29071 937/systemd-resolve
udp 0 0 192.168.178.255:138 0.0.0.0:* 0 47153 1607/nmbd
udp 0 0 198.18.7.3:32995 1.1.1.1:53 VERBUNDEN 101 155198 937/systemd-resolve
udp 0 0 198.18.7.3:34007 1.1.1.1:53 VERBUNDEN 101 155203 937/systemd-resolve
udp 0 0 0.0.0.0:53111 0.0.0.0:* 0 151190 -
udp 0 0 0.0.0.0:5353 0.0.0.0:* 114 24422 1018/avahi-daemon:
udp 0 0 127.0.0.1:54917 127.0.0.53:53 VERBUNDEN 1001 161854 2273/betterbird
udp 0 0 127.0.0.1:38956 127.0.0.53:53 VERBUNDEN 1001 160140 2955/firefox
udp 0 0 198.18.7.3:39072 1.1.1.1:53 VERBUNDEN 101 155197 937/systemd-resolve
udp 0 0 198.18.7.3:39727 1.1.1.1:53 VERBUNDEN 101 155196 937/systemd-resolve
udp 0 0 127.0.0.1:57357 127.0.0.53:53 VERBUNDEN 1001 161856 2955/firefox
udp 0 0 127.0.0.1:60174 127.0.0.53:53 VERBUNDEN 1001 151205 2273/betterbird
udp 0 0 127.0.0.1:60575 127.0.0.53:53 VERBUNDEN 1001 163855 2955/firefox
udp 0 0 127.0.0.1:45487 127.0.0.53:53 VERBUNDEN 1001 160138 2955/firefox
udp6 0 0 fe80::3f53:f30b:e35:546 :::* 0 48131 1023/NetworkManager
udp6 0 0 :::53111 :::* 0 151191 -
udp6 0 0 :::5353 :::* 114 24423 1018/avahi-daemon: Vielleicht ist das noch hilfreich.
~$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp5s0)
Current Scopes: DNS
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.178.1
DNS Servers: 1.1.1.1 192.168.178.1
DNS Domain: fritz.box
Link 5 (VPN-WG)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
DNS Servers: 1.1.1.1
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
trisaster schrieb: ~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search fritz.box ~$ host heise.de
;; connection timed out; no servers could be reached
Kann systemd-resolved die FritzBox nicht erreichen? Hast Du das Routing geändert? Wie sind die Ausgaben von:
host heise.de 127.0.0.53
host heise.de 192.168.178.1
nc -zv 192.168.178.1 53
?
|
|
trisaster
(Themenstarter)
Anmeldungsdatum:
12. April 2020
Beiträge: 58
|
Vielen Dank für die Antworten! lubux schrieb: Kann systemd-resolved die FritzBox nicht erreichen? Hast Du das Routing geändert? Wie sind die Ausgaben von:
host heise.de 127.0.0.53
host heise.de 192.168.178.1
nc -zv 192.168.178.1 53
?
Die FritzBox kann ich erreichen, sowohl über den Browser, als auch über ping. Am Routing habe ich nie etwas geändert. Ich weiß ehrlich gesagt nicht einmal, wie ich daran etwas ändern könnte. Wie gesagt, frisch installiertes Kubuntu 22.04, nur WireGuard eingerichtet, gleiches Verhalten. ~$ host heise.de 127.0.0.53
;; connection timed out; no servers could be reached ~$ host heise.de 192.168.178.1
Using domain server:
Name: 192.168.178.1
Address: 192.168.178.1#53
Aliases:
heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 10 relay.heise.de. ~$ nc -zv 192.168.178.1 53
Connection to 192.168.178.1 53 port [tcp/domain] succeeded!
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
trisaster schrieb: ~$ host heise.de 127.0.0.53
;; connection timed out; no servers could be reached
Wie sind die Ausgaben von:
cat /etc/systemd/resolved.conf
resolvectl query heise.de
systemctl status systemd-resolved --full --nopager
?
|
|
trisaster
(Themenstarter)
Anmeldungsdatum:
12. April 2020
Beiträge: 58
|
~$ cat /etc/systemd/resolved.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it under the
# terms of the GNU Lesser General Public License as published by the Free
# Software Foundation; either version 2.1 of the License, or (at your option)
# any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.
[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no ~$ resolvectl query heise.de
heise.de: resolve call failed: All attempts to contact name servers or networks failed Hier habe ich --nopager zu --no-pager geändert und sudo vorgeschoben.
~$ sudo systemctl status systemd-resolved --full --no-pager
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2023-01-24 13:39:22 CET; 6h ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 937 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 38302)
Memory: 8.9M
CPU: 766ms
CGroup: /system.slice/systemd-resolved.service
└─937 /lib/systemd/systemd-resolved
Jan 24 19:51:47 desktop systemd-resolved[937]: VPN-WG: Bus client set default route setting: yes
Jan 24 19:51:47 desktop systemd-resolved[937]: VPN-WG: Bus client set DNS server list to: 1.1.1.1
Jan 24 19:52:03 desktop systemd-resolved[937]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 192.168.178.1.
Jan 24 19:52:03 desktop systemd-resolved[937]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.178.1.
Jan 24 19:53:54 desktop systemd-resolved[937]: enp5s0: Bus client set default route setting: yes
Jan 24 19:53:54 desktop systemd-resolved[937]: enp5s0: Bus client set DNS server list to: 1.1.1.1, 192.168.178.1, 2001:67c:28a4::, fd00::3a10:d5ff:feaa:2343
Jan 24 19:54:05 desktop systemd-resolved[937]: enp5s0: Bus client set default route setting: no
Jan 24 19:54:05 desktop systemd-resolved[937]: enp5s0: Bus client set DNS server list to: 1.1.1.1, 192.168.178.1
Jan 24 19:54:05 desktop systemd-resolved[937]: VPN-WG: Bus client set default route setting: yes
Jan 24 19:54:05 desktop systemd-resolved[937]: VPN-WG: Bus client set DNS server list to: 1.1.1.1
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
trisaster schrieb: ~$ cat /etc/systemd/resolved.conf
[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
Mach mal folgende Eintragungen in die [Resolve]Section der resolved.conf-Datei:
DNS=192.168.178.1 1.1.1.1 9.9.9.9
FallbackDNS=4.2.2.1 4.2.2.2
LLMNR=no
DNSStubListener=yes
Cache=yes
ReadEtcHosts=yes
Domains=fritz.box
und nach dem speichern ausführen:
sudo systemctl daemon-reload
sudo systemctl restart systemd-resolved
und danach die Ausgaben von:
resolvectl query heise.de
host heise.de 127.0.0.53
host berlin.de
hier posten. BTW: "sudo" nur dann und dort benutzen, wo auch erforderlich.
|
|
trisaster
(Themenstarter)
Anmeldungsdatum:
12. April 2020
Beiträge: 58
|
lubux schrieb: Mach mal folgende Eintragungen in die [Resolve]Section der resolved.conf-Datei:
DNS=192.168.178.1 1.1.1.1 9.9.9.9
FallbackDNS=4.2.2.1 4.2.2.2
LLMNR=no
DNSStubListener=yes
Cache=yes
ReadEtcHosts=yes
Domains=fritz.box
und nach dem speichern ausführen:
sudo systemctl daemon-reload
sudo systemctl restart systemd-resolved
Das hat funktioniert. Vielen vielen Dank! Es bleibt noch unklar, was der Unterschied zwischen Kubuntu 20.04 und 22.04 ist, denn bei 20.04 sieht die Datei genau so aus. Aber das ist für mich nicht wirklich relevant, Hauptsache es geht. lubux schrieb: und danach die Ausgaben von:
resolvectl query heise.de
host heise.de 127.0.0.53
host berlin.de
Der Vollständigkeit halber trotzdem noch die Ausgabe davon. ~$ resolvectl query heise.de
heise.de: 2a02:2e0:3fe:1001:302:: -- link: enp5s0
193.99.144.80 -- link: enp5s0
-- Information acquired via protocol DNS in 39.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network~$ host heise.de 127.0.0.53
Using domain server:
Name: 127.0.0.53
Address: 127.0.0.53#53
Aliases:
heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 10 relay.heise.de. ~$ host berlin.de
berlin.de has address 109.68.230.145
berlin.de has IPv6 address 2a00:13c8:f5::393:8a4d:2
berlin.de mail is handled by 10 mailin.berlin.de.
berlin.de mail is handled by 50 secondary.snafu.de. lubux schrieb: hier posten. BTW: "sudo" nur dann und dort benutzen, wo auch erforderlich.
sudo hatte ich bei systemctl verwendet, weil mir ohne sudo dieser Hinweis angezeigt wurde:
Warning: some journal files were not opened due to insufficient permissions.
|
|
ja
Anmeldungsdatum:
30. Juli 2022
Beiträge: Zähle...
|
trisaster schrieb: Das hat funktioniert. Vielen vielen Dank! Es bleibt noch unklar, was der Unterschied zwischen Kubuntu 20.04 und 22.04 ist, denn bei 20.04 sieht die Datei genau so aus. Aber das ist für mich nicht wirklich relevant, Hauptsache es geht.
Bei mir war der DNS Eintrag in der wg.conf das Problem. Ich musste das Paket resolvconf nachinstallieren, dann hat es geklappt. Oder ich habe den DNS Eintrag auskommentiert. Also ist vielleicht das Paket bei 20.04 dabei und bei 22.04 nicht mehr.
|
