Aug 26, 2020

13496

Wireguard dns problem

Hallo Zusammen,

auf einem meiner VPS-Server Ubuntu 20.04 LTS (headless) habe ich wireguard eingerichtet,

ich kann mich ohne Problem einklinken und bekomme IP des VPS zugewiesen.

Sobald ich aus dem Client-Config den DNS eintrag 8.8.8.8 entferne oder die private IP des HOST 10.1.1.1 kann der Browser DNS-Name nicht auflösen und erhalte folgende Fehlermeldung z.Bsp:

ERR_ADDRESS_UNREACHABLE, DNS_PROBE_FINISHED_NO_INTERNET

.

Unter VPS ist der DNS-Eintrag

 /etc/netplan/50-cloud-init.yaml

hinterlegt ( 8.8.8.8 und 8.8.4.4).

den VPS server kann ich auch updaten, sodass die Namenauflösung auf dem VPS stattfindet und der ausgehende Traffic wie DNS, HTTPS, SSH und NTP sind erlaubt :

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
81262 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
 94M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state ESTABLISHED
 800 LOG_ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:2221 /* allow ssh */
65824 LOG_ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:50000 /* allow wireguard */
6180 LOG_ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443 /*  allow update download */
30812 ACCEPT     udp  --  *      *       0.0.0.0/0            8.8.8.8              udp dpt:53
   0 ACCEPT     udp  --  *      *       0.0.0.0/0            8.8.4.4              udp dpt:53
   0 ACCEPT     tcp  --  *      *       0.0.0.0/0            8.8.8.8              tcp dpt:53
   0 ACCEPT     tcp  --  *      *       0.0.0.0/0            8.8.4.4              tcp dpt:53
   0 ACCEPT     udp  --  *      *       0.0.0.0/0            91.189.91.157        udp dpt:123
   0 ACCEPT     udp  --  *      *       0.0.0.0/0            91.189.94.4          udp dpt:123
23256 ACCEPT     udp  --  *      *       0.0.0.0/0            91.189.89.198        udp dpt:123
   0 ACCEPT     udp  --  *      *       0.0.0.0/0            91.189.89.199        udp dpt:123

<

Und weiß nicht was ich noch modifzieren muss, anpassen muss.

Vielen Dank und freue mich auf jede Unterstützung

decehakan

Please also mark the comments that contributed to the solution of the article

Content-Key: 599340

Url: https://administrator.de/contentid/599340

Printed on: April 26, 2024 at 06:04 o'clock

12 Comments

Latest comment

Die Google DNS IPs zu verwenden machen heute eigentlich nur noch ziemliche Dummies. Jedermann weiss ja mittlerweile das die damit dein genaues Surf- und Internet Verhalten aufzeichnen, davon ein detailiertes Profil erstellen und das weltweit mit Dritten vermarkten.
Wem also Privatsphäre und Sicherheit etwas wert sind sollte wenn überhaupt, immer auf Datenschutz freundlichere Anbieter ausweichen:
https://www.heise.de/newsticker/meldung/Quad9-Datenschutzfreundliche-Alt ...
Soviel zu dem Thema....
Es ist so oder so völlig unsinnig einen DNS zu definieren, denn normal bekommt ein Client den ja per DHCP automatisch zugewiesen und ist in der Regel immer die des lokalen Providers oder Internet Routers der als DNS Proxy zum Provider arbeitet.
Es besteht also in der Regel nie ein Grund DNS Adressen statisch und fremd zu vergeben. Fragt sich also was genau du da eigentlich machst ?!

Sobald ich aus dem Client-Config den DNS eintrag 8.8.8.8 entferne oder die private IP des HOST 10.1.1.1 kann der Browser DNS-Name nicht auflösen und erhalte folgende Fehlermeldung z.Bsp:

Leitest du sämtlichen Traffic über den Tunnel? Poste doch mal deine WG Server und WG Client-Config.
Prüfe welche DNS-IP bei bestehendem Tunnel am Client noch hinterlegt ist und mit tracepath oder pathping den Pfad ermitteln über welchen die Pakete laufen. Wenn diese über den Tunnel laufen dann eine Ausnahme für lokale Netze in dem der DNS-Server steht in den AllowedIPs definieren sofern du eine lokale DNS-IP konfiguriert hast.

Btw. die Output-Chain hat für den Client so viel zu tun wie ein Fisch mit einem Fahrrad 🐟 ... Besser du übst nochmal die Basics im Homelab bevor du deine Künste auf die große weite Welt los lässt.

ich leite alle traffic über den Tunnel, hier die configs:

Client

[Interface]
PrivateKey = secret
Address = 10.1.1.2/32
DNS = 10.1.1.1

[Peer]
PublicKey = secret
AllowedIPs = 0.0.0.0/0
Endpoint = host-ip:50000
PersistentKeepalive = 15

Server / wg0.conf

[Interface]
Address = 10.1.1.1/28
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -A FORWARD -o %i -j ACCEPT;
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -D FORWARD -o %i -j ACCEPT;
ListenPort = 50000
PrivateKey = privat

[Peer]
PublicKey = privat
AllowedIPs = 10.1.1.2/32

Zitat von @145033:

Btw. die Output-Chain hat für den Client so viel zu tun wie ein Fisch mit einem Fahrrad 🐟 ... Besser du übst nochmal die Basics im Homelab bevor du deine Künste auf die große weite Welt los lässt.

jup weiß ich, wollte nur ausführlich sein ;)

DNS = 10.1.1.1

Wenn du den VPS als DNS-Server definierst muss dort erstens auch ein DNS-Server/Proxy laufen, zweitens musst du deiner Firewall sagen das diese ein INPUT von 10.1.1.2 auf Port 53 akzeptiert.

Wenn du diesen Eintrag weg lässt, dann prüfe welche DNS-IP der Client noch hat. Liegt die IP in einem Netz das der Client direkt über seine lokale Ruoting-Tabelle erreichen kann sollte es out of the box klappen, wenn diese DNS-IP aber nicht direkt vom Client erreichbar ist dann musst du die lokalen Netze per AllowedIPs ausfiltern, damit der Client die DNS-IP noch erreichen kann und die Anfragen an diese nicht über den Tunnel schickt.

zitat: Wenn du den VPS als DNS-Server definierst muss dort erstens auch ein DNS-Server/Proxy laufen....

hast vollkommen recht

.

Mein Windows Client übernimmt den DNS-Server vom Gateway,also Wireguard ( wenn ich alles tunnele).

route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway.hoster. 0.0.0.0         UG    0      0        0 eth0
10.1.1.0        0.0.0.0         255.255.255.240 U     0      0        0 wg0
host-ip    0.0.0.0         255.255.252.0   U     0      0        0 eth0

ip route 

default via  x.x.104.1 dev eth0 proto static
10.1.1.0/28 dev wg0 proto kernel scope link src 10.1.1.1
x.x.104.0/22 dev eth0 proto kernel scope link src x.x.107.80

mein lokaler dns resolver ist der vom ubuntu (20.04)standard gelegten systemd/resolver.conf

Er wird über

127.0.0.53:53

angesprochen.

Wenn der dns-resolver 127.0.0.53 mit meiner öffentlicher ip kommuniziert , muss er auch mit 10.1.1.1 besprechen, so meine logik

Anscheined geht es glaub ich nur noch, wie du oben erwähnt über ein dns-proxy (unbound or bind9 ).

Mein Windows Client übernimmt den DNS-Server vom Gateway,also Wireguard ( wenn ich alles tunnele).

Dafür gibt es in Wireguard kein Protokoll.
Deine Default Route geht laut Tabelle nicht über den Tunnel.

127.0.0.53:53

Und wie du siehst lauscht der nur über die Loopback-Adresse, von anderen nicht erreichbar.

Back to your lab and learn the basics

Redest wie ein Meister (:, gib mir den endgültigen Tipp, wie muss ich die routing Tabelle ändern, am besten den command geben ;]

@aqui: du hast recht, aber glaubst du echt dass nur Google die profilin macht, alle sind gleich, ama, ali, Windows oder fbok alle sind kapos. Wäre nicht Google die Nr. 1dann würde Yahoo, oder Bing oder astalavista die Daten sammeln. Das Problem ist das System, wir werden alle in der Schule gezüchtet um besser zu sein als der andere, mehr und bessere Ergebnisse zu leisten als der Andere. Ich sehe nur ein Licht im Tunnel der westlichen Werte (USA Euro) und der sieht nicht schön aus. Globale Erwärmung > Gletscher schmelzen > Ernte ertrag wird sinken > real battle royal maybe?

wie muss ich die routing Tabelle ändern, am besten den command geben

ip route add default via 10.1.1.1

Anscheinend bin ich nicht der einzige der homelab lernen muss ;)

Siehst du Großmeister geht nicht.

shell@: ip route add default via 10.1.1.1
shell@: RTNETLINK answers: File exists

Ja klar .... Leg die Default Route auf das TunnelDevice und lösch andere bereits existierende, doppelt gemoppelt geht halt nicht, sagt ja die Fehlermeldung bereits. Welches ClientOS du hier verwendest sagst du auch nirgendwo, Windows das du oben nur erwähnst kennt übrigens kein ip route Kommando.

Na dann bastel mal weiter. Tschö.

ich hab mich etwas schlau gemacht und alleine

Ja klar .... Leg die Default Route auf das TunnelDevice und lösch andere bereits existierende, doppelt gemoppelt geht halt nicht, sagt ja die Fehlermeldung bereits.

Falsch, Linux kennt nur eine default route, zwei default route führen zu einer Überlappung, daher war deine Idee tool, aber falsch

mit dem Paket

iproute2

kann man zwei default route erstellen.

Macht es ein unterschied zu routing ob ich windows oder linux als clientos benutze ?

Zitat von @decehakan:
Falsch, Linux kennt nur eine default route, zwei default route führen zu einer Überlappung, daher war deine Idee tool, aber falsch

Nein. es sind mehrere Default Routes problemlos möglich, die haben nur jeweils unterschiedliche Prioritäten.

Default Route bedeutet nur als Ziel 0.0.0.0/0. Diese können problemlos mehrfach angelegt sein mit unterschiedlichen Pios und Dev's. Für Lastverteilung oder Failover oder Policy-Routing ist das ja normal.

mit dem Paket
iproute2
kann man zwei default route erstellen.

Eben, nichts anderes meinte ich wenn ich ip Kommandos benutze.

Macht es ein unterschied zu routing ob ich windows oder linux als clientos benutze ?

Kommt drauf an was du mit "routing" genau meinst, der Begriff ist zu allgemein. Das Grund-Prinzip ist bei beiden gleich.

German Question Networks