Jul 07, 2023, updated at 23:18:53 (UTC)

1861

DNS Server auf VPN host

Hallo an alle,

Ich bin noch recht neu und eher unerfahren im Bereich Netzwerktechnik. Gerade der Schwerpunkt Routing und Schnittstellen ist für mich noch unbekanntes gebiet. Da ich außerdem niemanden mit genügend Fachwissen in meinem Umfeld habe, suche ich nun hier nach Rat.

Ich habe einen Linux Server auf dem Mehrere Virtuelle Maschinen laufen. Jetzt möchte ich auf dem Host einen DNS Server verwenden, um die VMS per Name erreichen zu können. Der DNS-Server befindet sich im privaten Netz 192.168.0.0/16 und soll unter 192.168.144.144 erreichbar sein.

Hierzu habe ich ein dummy Interface mit der ip 192.168.144.144 erstellt von dem aus der DNS-Server die Anfragen bearbeiten kann.

dnsdummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet 192.168.144.144  netmask 255.255.255.0  broadcast 192.168.144.255

Ist man nun auf einem Windows Client im VPN Angemeldet und gibt ping 192.168.144.144 ein, antwortet der Server Ordnungsgemäß. Gibt man allerdings z.B. nslookup vm1.example.com ein, erhält man einen timeout. Hier sollte aber eigentlich die Adresse der vm zurück kommen. Ich denke nicht, dass es an der Firewall oder dem Routing liegt, da der Ping ja ordnungsgemäß durchgeführt wurde. Gibt man allerdings dig vm1.example.com auf dem host ein. Funktioniert alles einwandfrei. Dies liegt an der Zeile listen-address=127.0.0.1.

Zur Sicherheit hier nochmal ein Auszug aus meiner Routing Tabelle und der iptables Eintrag:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
177.177.0    0.0.0.0         255.255.255.0   U         0 0          0 wg0
168.128.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0
168.144.0   0.0.0.0         255.255.255.0   U         0 0          0 dnsdummy0
168.192.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr2

target     prot opt source               destination
ACCEPT     all  --  10.177.177.0/24      anywhere             ctstate NEW,UNTRACKED

Dnsmasq ist aktuell konfiguriert mit:

listen-address=127.0.0.1
listen-address=192.168.144.144

Allerdigns habe ich auch die folgenden Konfigurationen ausprobiert. Jedoch ohne Erfolg.

interfaces=wg0
listen-address=0.0.0.0
###########
interfaces=dnsdummy0
listen-address=0.0.0.0

auszug aus /etc/hosts:

192.168.192.215 vm1.example.com

tcpdump -i wg0 liefert mir:

`192.168.144.144 > 10.177.177.2: ICMP host 192.168.144.144 unreachable`

was allerdings im Widerspruch zu dem erfolgreichen Ping steht. Vermutlich liegt hier irgendwo das Problem.

192.168.144.144 > 10.177.177.2: ICMP echo reply, id 1,

Struktur des Netzwerks:

  10.177.177.2                    10.177.177.1    192.168.144.144
+--------------+                     +---+          +---------+     +----------+
|Windows Client|-----[Wireguard]-----|wg0|----------|dnsdummy0|-----|DNS-Server|
+--------------+                     +---+          +---------+     +----------+
                                  ^--------------------HOST-----------------------^

Da ich nun schon seit mehreren Tagen verschiedene Firewall Konfigurationen, virtuelle Schnittstellen und dnsmasq Konfigurationen ausprobiert habe und immer noch zu keinem Ergebnis gekommen bin, wollte ich nun einmal hier nachfragen, wo genau das Konfigurations-Problem liegen könnte. Oder vielleicht ist es doch das dummy interface. Ich bin mir da leider nicht ganz sicher, was genau das Problem verursacht.

Als VPN Verwende ich Wireguard um in das Netz 192.168.0.0/16 zu kommen. Die Schnittstelle ist wg0 auf 10.177.177.1.
Als DNS-Server verwende ich dnsmasq, da dieser für meine Zwecke ausreichend ist.

Vielen Dank für jede Hilfe.

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

Content-Key: 7777109200

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

Printed on: May 3, 2024 at 00:05 o'clock

10 Comments

Latest comment

N'Abend.

Zitat von @PlayerSchark:
[...]Gibt man allerdings z.B. nslookup vm1 ein[...]

Naja, nslookup vm1.domain.tld sollte evtl. etwas zurück liefern?
FQDNs rocken.

Cheers,
jsysde

Naja, nslookup vm1.domain.tld sollte evtl. etwas zurück liefern?
FQDNs rocken.

Guten Abend,

vielen Dank für deine Antwort. Natürlich verwende ich an dieser stelle einen FQDN.

Aber sollte das nicht eigentlich irrelevant sein, solange in der /etc/hosts datei "192.168.192.4 vm1" steht?

Ich habe den Beitrag entsprechend angepasst.

VG

192.168.0.0/16 und soll unter 192.168.144.144 erreichbar sein.

Da stimmt ja schon irgendwas mit der Maskierung nicht. Du redest von einem /16er Prefix aber die Zieladresse ist mit einmal in einem /24er Netz? Wie geht das zusammen?

erhält man einen timeout.

Was sagt nslookup am Client denn welchen DNS Server der Client befragt??
Du kannst das bei aktivem VPN auf dem Windows Rechner auch immer mit ipconfig -all sehen.

Sofern du beim VPN Dialin keinen DNS Server an den VPN Client propagierst wird der weiterhin seinen lokalen DNS fragen und der kennt dann sehr wahrscheinlich vm1.example.com nicht und deshalb rennt das ins Leere!!
Du kannst nslookup zwingen einen bestimmten DNS Server zu fragen: nslookup [domain-name] [name-server] ist die Syntax dafür. In deinem Falle dann nslookup vm1.example.com 192.168.144.144

Ich denke nicht, dass es an der Firewall oder dem Routing liegt

Da solltest du dir nicht sicher sein! Deine falschen Subnetzmasken oben in der Schilderung würden schon für falsches Routing sorgen! Auch das ICMP unreachable im tcpdump spricht diesbezüglich eine deutliche Sprache! Ein ip r auf dem Host würde helfen das Routing zu klären.

Alles zum korrekten Wireguard Setup findest du im hiesigen Wireguard Tutorial!
Hier sollte in jedem Falle ein DNS = 192.168.144.144 in der Client Konfig stehen was du mit ipconfig -all überprüfen solltest.
Auch deine falsche Subnetzmasken solltest du prüfen und ggf. korrigieren!

Hey @aqui, vielen dank für deine erneute Hilfe

Wie geht das zusammen?

192.168.0.0/16 ist der Private IP Bereich C Wenn ich mich nicht täusche. Und in C kann ich das 3. und 4. Oktett doch frei vergeben. Die IP Adresse des DNS-Servers muss ja eine IP Sein. Ich habe deshalb eine genommen, die man sich leicht merken kann.

Was sagt nslookup am Client denn welchen DNS Server der Client befragt??

Aus nslookup: Address: 192.168.144.144

Wireguard ist diesbezüglich korrekt eingestellt.

Adressen: 10.177.177.2/32, fd42:42:42::2/128
DNS-Server: 192.168.144.144
- - - - - - - - - - - - - - - - - - - - - - - - -
Erlaube IPS: 192.168.0.0/16, ::1/128

Auch das ICMP unreachable im tcpdump spricht diesbezüglich eine deutliche Sprache!

Da hast du recht, aus diesem Grund suche ich gerade nochmal die ganze Firewall ab. Ich denke dort ist es am wahrscheinlichsten. Allerdings ist iptables für mich sehr kompliziert. Ich habe mir bereits mehrere Tutorials und Diagramme dazu angeschaut. Auf welche Punkte muss ich konkret achten?

Es muss ja von Source IP 10.177.177.0/24 nach Destination 192.168.0.0/16 erlaubt sein. Der entsprechende Befehl wäre dann (jeweils für dcp und udp, da DNS):

iptables --append INPUT --protocol tcp --src 10.177.177.0/24 --dst 192.168.0.0/16 --jump ACCEPT

Oder sehe ich hier etwas falsch? Ein weiteres Problem ist, durch die Virtualisierung, entstehen komische Chains über die ich kaum einen Überblick habe. Zudem steht bei den meisten vorhandenen regeln/chains source: anywhere destination: anywhere.

Ein ip r auf dem Host würde helfen das Routing zu klären.

Gerne kein Problem. Einige "Offensichtliche Korrekturen" musste ich allerdings vornehmen.

default via 512.512.16.224 dev eno1 onlink
177.177.0/24 dev wg0 proto kernel scope link src 10.177.177.1
512.16.224/27 via 512.512.16.225 dev eno1
512.16.224/27 dev eno1 proto kernel scope link src 512.512.16.229
168.128.0/24 dev virbr0 proto kernel scope link src 192.168.128.1
168.144.0/24 dev dnsdummy0 proto kernel scope link src 192.168.144.144
168.192.0/24 dev virbr2 proto kernel scope link src 192.168.192.1 linkdown

was du mit ipconfig -all überprüfen solltest

Soweit alles korrekt eingetragen.

Unbekannter Adapter wg0-client-me:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : WireGuard Tunnel
   Physische Adresse . . . . . . . . :
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : fd42:42:42::2(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 10.177.177.2(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.255
   Standardgateway . . . . . . . . . :
   DNS-Server  . . . . . . . . . . . : 192.168.144.144
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Moin, sorry habe mir jetzt nicht alles ausführlich durchgelesen weil ich direkt weiter schlafen werde 😅
Ich glaube was Aqui meinte ist, dass dein Dummy interface das Netz 192.168.144.0/24 hat, du aber von einem privaten IP Adress Bereich von 192.168.0.0/16 gesprochen hast.

Das wird, soweit ich weiß, als zwei verschiedene Netze anerkannt.

Versuch mal das Dummy interface ebenfalls mit der /16er subnetzmaske auszustatten und teste es nochmal falls das noch nicht gemacht wurde.

Vg

Hey, danke für deine Antwort.
Ich bin mir da auch immer nie so sicher, ob ein /24er Netz in einem /16er drin ist oder nicht. Ich tendiere aber meistens zu Ja.
Das ändern der Subnetzmaske hat leider das Problem nicht gelöst. Ich vermute es liegt tatsächlich an der Firewall. Was ich allerdings wo, wie konfigurieren muss, das gilt es gerade heraus zu finden.

Ich bin mir da auch immer nie so sicher, ob ein /24er Netz in einem /16er drin ist oder nicht.

Etwas wirre Äusserung, denn DU bist doch derjenige der es konfiguriert. Da sollte mann dann eigentlich schon wissen was man selber da tut!

192.168.0.0/16 ist der Private IP Bereich C

Du lebst noch im tiefsten IP Neandertal! "Klassen" gibt es schon seit 30 Jahren nicht mehr in der IP Adressierung! Wir befinden uns mittlerweile im Zeitalter des CIDR Routings:
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Lesen und verstehen!

kann ich das 3. und 4. Oktett doch frei vergeben.

Das kannst du schon, nur innerhalb eines IP Netzes sollte man bekanntlich eine konsistente Subnetzmaske benutzen, was bei dir laut deiner eigenen Schilderung ja nicht gegeben ist wenn du einmal von einem 16 Bit Prefix redest und dann wieder von einem mit 24 Bit.
Bei 24 Bit sind die ersten 3 Oktets immer das Netzwerk und das letzte der Hostanteil. Simple Subnetting Binsenweisheit. Guckst du hier.

Wireguard ist diesbezüglich korrekt eingestellt.

Das ist es leider nicht und sieht man schon an deiner falschen Client IP Adresse!! Nur in den Allowed IPs verwendet man /32 Hostmasken im internen Netzwerk nicht aber in der Client IP Adressierung selber. Zeigt leider das du das Wireguard Tutorial nicht oder nicht richtig gelesen hast was diese Thematik explizit beschreibt!!

Deine WG Konfig wäre auch hilfreich für eine zielführende Hilfe denn die Adressierung offenbart das du auch dort scheinbar gravierende Fehler gemacht hast zumindestens was Adressierung und Masken anbetrifft.

Es muss ja von Source IP 10.177.177.0/24 nach Destination 192.168.0.0/16

Können wir ja nicht zielführend beantworten wenn du uns nicht sagst ob du im lokalen LAN nun mit einer 16er oder mit einer 24er Maske arbeitest?! Beides zu gleich geht nicht wie dir oben ja schon mehrfach gesagt wurde!

Das ändern der Subnetzmaske hat leider das Problem nicht gelöst.

Ist ja auch kein Wunder und völliger Quatsch, denn wie du ja oben sehen kannst verwenden ALLE deine 192.168er IP Netze laut Routing Tabelle einen 24er Prefix. Da darfst du dann keinesfalls mit einem 16er Prefix arbeiten! Vergiss den Unsinn also und korrigiere das bzw. prüfe ob die Subnetzmasken alle korrekt sind!

Ein funktionierendes Beispiel für einen VPN Server mit öffentlicher IP findest du u.a. HIER. Der benutzt zwar IKEv2 statt WG um mit allen onboard VPN Clients kompatibel zu sein aber die ToDos beim generellen Setup sind vollkommen identisch zu deinem.

Vielen Dank für die Sehr ausführliche Antwort.

wenn du uns nicht sagst ob du im lokalen LAN nun mit einer 16er oder mit einer 24er Maske arbeitest

Also das "Interne" Netz ist 192.168.0.0/16. In diesem Internen Netz gibt es für verschiedene Anwendungen verschiedene Bereiche. 192.168.128.0/24, 192.168.192.0/24, etc.. Der DNS ist aktuell alleine im Netz 192.168.144.0/24 und könnte eventuell eine /32er auf 192.168.144.144 bekommen. Wireguard Client IPS sind im Netz 10.177.177.0/24

Wireguard Tutorial

Es macht immer Sinn von der Adressierung mit dem Server bei der .1 anzufangen und die Clients "von oben nach unten" zu vergeben.
[...]
Diese Adressierung der Übersicht halber ist rein kosmetischer Natur und kann jeder nach eigenem Ermessen vornehmen.

Guten Tag nochmal.

Ich habe jetzt mal

iptables -I INPUT 1 --protocol all --src 10.177.177.0/24 --dst 192.168.0.0/16 --jump ACCEPT

anstatt

iptables -A INPUT --protocol all --src 10.177.177.0/24 --dst 192.168.0.0/16 --jump ACCEPT

ausprobiert. Das scheint zu funktionieren. Dazu musste ich die Regel nur in /etc/wireguard/wg0.conf bei PostUp hinzufügen.

Jetzt bleibt nur noch ein Problem. Das dummy Interface übersteht keinen Reboot.

Meine aktuelle Konfiguration sieht so aus:

/etc/systemd/network/dnsdummy0.netdev

[NetDev]
Name=dnsdummy0
Kind=dummy

/etc/systemd/network/dnsdummy0.network

[Match]
Name=dnsdummy0

[Network]
Address=192.168.144.144
Mask=255.255.0.0

gibt man nach einem Reboot den Befehl systemctl restart systemd-networkd ein, wird das Interface erstellt und alles funktioniert korrekt.

Edit:
Um das Interface doch nach dem reboot zu behalteen musste ich networkd aktivierten.

systemctl enable systemd-networkd

Also das "Interne" Netz ist 192.168.0.0/16

Dann kannst du logischerweise keine anderen 192.168er IP Netze mehr verwenden!!
Das kann doch niemals klappen, denn wie sollte damit eine eindeutliche Wegefindung geregelt sein? Alle /24er Netze sind doch immer Teil des /16er Netz und damit unroutebar! Ein IP Routing ist damit völlig unmöglich. Das kann also niemals klappen!

Mit dem /16er Netz sind alle weiteren 192.168er Netze für dich dann absolut Tabu!
Du musst dann auf den RFC 1918 Range 172.16.0.0/12 mit 24er Masken ausweichen oder das 10.0.0.0er Netz verwenden.
Dann ist klar das das oben niemals klappen kann mit so einem völlig falschen IP Adressdesign.
Mal ganz abgesehen davon ist ein /16er Netz auch völliger Unsinn. Jeder gute Netzwerker weiss das in einer L2 Domain niemals mehr als 150 bis max. 200 Clients sein sollten. Allein aus dieser Designsicht sind /16er Netze schon Unsinn. 65.534 Hosts zu adressieren in einem Netz ist Quatsch.
Checke ob du das 0er Netz ggf. auch mit einem 24er Prefix betreiben kannst also 192.168.0.0/24
Auch das würde dein Problem sofort lösen.

Alternativ kannst du das .0.0/16er Netz auch "halbieren", denn deine anderen Netze fangen ja glücklicherweise erst mit .128.0 /24 an!
Wenn du dann statt des 16er einen 17er Prefix (255.255.128.0) verwendest hast du zumindestens immer noch die Hostrange 192.168.0.1 bis 192.168.127.254.
Auch das würde dein Problem elegant lösen denn der Bereich ""192.168.128.1 bis 192.168.255.254** wäre dann für deine /24er Netzekomplett frei und so wieder problemlos routebar!!
Das wäre die eleganteste Lösung! 😉

Geht das nicht musst du zwangsweise auf die anderen o.a. IP Netze ausweichen. Anders ist das NICHT zu lösen.
Sorry, aber solche IP Adress Banalitäten und Grundlagen sollte man aber schon kennen als Admin! 🧐

Das dummy Interface übersteht keinen Reboot.

Musst du statisch in der /etc/interfaces konfigurieren!

German solved Question DNS Linux Network VPN Firewall

Hotly discussed

End of availability for classic Teams clientDani - 2 Comments

Ubuntu 24.04 LTS Noble Numbat availableFrank

Developer diary: Release 6.1admtech