letsencrypt DNS Problem

[Simaryp]

Hallo, ich habe heute eine Baustelle abschließen wollen und bin über ein unerwartetes Problem gestolpert.

Ich möchte gerne auf meinem Server traefik laufen lassen mit letsencrypt.
Ich hatte das auf meinem alten opnsense router auch schon mal funktionierend hin bekommen. Aber wegen anderer Baustellen liegen lassen müssen.

Ich wollte heute die traefik Konfiguration finalisieren und stellte fest, dass das letsencrypt nicht mehr ging.
Erstes Problem war, dass ich dyndns auf meinem neuen opnsense router noch nicht eingerichtet hatte. Das habe ich gerade hin bekommen.
Aber letsencrypt geht noch immer nicht.

Eine Recherche sagt mir, dass es wohl an meinem DNS Setup liegt, was sich bei dem neuen router geändert hatte. Früher hatte der DHCP-Server einfach die leases zum DNS hinzu gefügt. Daher musste ich im DNS nicht viel anpassen und letsencrypt hat bei cloudflare einen dns record angelegt. Im aktuellen Setup mit dnsmasq musste ich aber in unbound ein query forwarding anlegen, weswegen letsencrypt die IP nicht richtig auflöst und die dns challenge nicht machen kann.

Hat irgendjemand das hinbekommen?

[Simaryp]

Wenn ich den Forward für meine domain auf dnsmasq deactiviere, dann kann letsencrypt die challenges einrichten. Wenn ich es dann wieder aktiviere und zusätzlich in dnsmasqs die adressen als hosts konfiguriere, dann werden die gerouted und die zertifikate sind dann da.

Aber das ist natürlich nicht so wie gedacht.
Ich will ja nicht permenanent dort etwas umkonfigurieren und aktivierung togglen.

[meyergru]

Machst Du DNS-01 Verifikation? Falls ja, die DNS Updates werden weder durch Unbound noch durch DNSmasq durchgeleitet - beide Server können nur DNS-Queries verarbeiten. Ich habe das gemerkt, als ich versucht habe, mit einem Server "hinter" OpnSense einen DNS-01 update per RFC2136 durchzuführen, während ich alle DNS-Requests über den lokalen Unbound geforwardet hatte. Ich musste für den betroffenen Host eine Ausnahme eintragen.

[Simaryp]

Ja, ich wollte die DNS-Challenge machen, weil meine Heimdienste nicht aus dem Web erreichbar sind.

Ich meine, ich hätte auf einer etwas veralteten opnsense installation im Sommer das zum laufen bekommen. Da war aber noch nicht dnsmasq der standard, sondern ein einfacherer dienst, der nur DHCP gemacht hat. Dort wurden die Leases automatisch an unbound weiter geleitet. Damit hat sowohl die Erstellung der txt. entries in cloudflare funktioniert, als auch das routing zum server und Auflösung von traefik.

Jetzt geht es nicht mehr. Oder halt nur, wenn ich das Forwarding für meine domain an dnsmasq deaktiviere, die Dienste starte, wodurch die zertifikate erstellt werden und dann das Forwarding wieder anstelle. Aber das ist natürlich keine tragbare Lösung.

Vlt. muss ich eine ganz andere Lösung finden.

Ich will nur lokal auf die Dienste zugreifen, aber mit wenig aufwand tls ohne nervige Warnungen erreichen.

[meyergru]

Wie gesagt, wenn Du den DNS-Redirect wegnimmst, kannst Du ja den DNS update direkt absetzen. Das geht an jedem lokalen DNS-Sever vorbei und bedarf nur einer Regeleinschränkung im Port-Forwarding.

[Simaryp]

Ja, aber wenn ich den wegnehme, dann kriege ich ja nur noch eine Auflösung auf meine externe IP Adresse, aber nicht mehr auf die lokale IP.

Dann hab ich für die Dienste gültige Zertifikate, aber kann sie nicht mehr im internen Netz erreichen, sondern müsste, von außen rein und entsprechend den Port frei geben.

Oder übersehe ich da etwas?

[meyergru]

Es geht doch nur um eine Ausnahme für den Redirect für den Rechner, der das Zertifikat beantragt. Der Redirect soll doch nur dazu dienen, dass kein externer DNS-Server genutzt werden kann, sondern alle Requests auf Zielport 53 auf die OpnSense umgebogen werden (somit auch die DNS Updates).

Durch die Einschränkung erlaubst Du doch nur einem einzigen Host, diese Beschränkung zu umgehen. Das heißt nicht, dass er nicht als DNS-Resolver weiterhin die OpnSense nehmen DARF - nur eben nicht MUSS. Den externen DNS nutzt er doch nur für den DNS-Update. Klar, er KÖNNTE dann auch andere DNS-Resolver nutzen, aber da es sich mutmaßlich um einen Server handelt, wird das doch eher nicht passieren, oder?

Was man mit einer solchen Regel typischerweise erzwingen will, ist, dass IoT-Geräte oder Smartphones den eigenen DNS nutzen müssen.

[Simaryp]

Du meinst ich soll in der opnsense konfigurieren, dass der server einen externen dns server statt der opnsense nutzt?
Wie kann ich das erreichen?

Momentan habe ich floating rules, die dns traffic blockieren und auf opnsense umrouten.

[meyergru]

Was ist meine ist, dass man das normalerweise so macht, dass man einen Port Forward für Traffic mit Zielport UDP 53 auf 127.0.0.1:53 macht. Dadurch würde jeder DNS-Request von internen Quellen auf die OpnSense umgebogen. Die einzige Änderung ist, dass man in der Regel die Quelle mit !HOST-IP einträgt. Damit ist HOST-IP als einziger von diesem "Umbiegen" ausgenommen.

Ist alles hier beschrieben, inklusive dieses Problems, ziemlich am Ende des Threads.

[Simaryp]

Verstehe nicht, was du mit !HOST-IP meinst.

Ich habe ein Netwerk private. Da ist der Server und auch clients drin.

Meine DNS Regel redirected einfach alles auf die opnsense um.

Ich müsste vermutlich einen alias für den server nehmen und den von der Regel ausnehmen. Vermutlich müsste ich dann auch konfigurieren, dass dieser gerade nicht die opnsense als DNS nimmt.

[meyergru]

"!" bedeutet Negation, also die Checkbox "Destination / Invert" zu setzen. Und dann trägt man die Host-IP in das die Destination als "Single Host or IP" ein. Damit ist alles, was NICHT HOST-IP ist, von der Regel betroffen, nicht mehr "any". Die Einschränkung auf Deine lokalen Clients braucht es gar nicht, weil "any" genausogut funktioniert - wer soll denn sonst fragen?

Schau Dir einfach mal die Bilder im ersten Post des verlinkten Threads an, da sieht man, dass das "Destination / Invert" in der Regelliste zu einem vorangestellten "!" führt, z.B. in "! LAN Address".


Und nein, nochmal, den DNS-Server musst Du nicht ändern. Für die DNS-Requests kann er ganz normal die OpnSense nutzen. Die DNS Updates werden normalerweise sowieso an den authoritativen DNS-Server für die Domain abgesetzt - das ist meist einer im Internet.

Dummerweise sorgt die Redirect-Regel aber dafür, dass JEDER DNS-Request umgebogen wird, neben den DNS-Queries auch die DNS-Updates, die weiterhin nach draußen gehen sollen. Das liegt einfach daran, dass man nur auf den UDP Port 53 matcht, und der ist bei beiden Varianten gleich. Man müsste ins Protokoll hineinschauen, um zu sehen, dass es Update und keine Queries sind, aber das geht nicht so einfach.

Wenn Du die Regel komplett deaktivierst und Deine Clients sich "wohl verhalten", würden sie ja per DHCP auch die OpnSense als DNS-Server genannt bekommen und diese ohnehin nutzen. Die ganze Umleiterei macht man doch nur "on top", um das bei böswilligen oder fehlkonfigurierten Clients zu erzwingen.

[Simaryp]

Und mit  HOST-IP meinst du dann in meinem Fall die IP meines Servers?

[Simaryp]

Ich habe jetzt diese Regeln von any auf not server mac address gesetzt. Es funktioniert dennoch nicht. Ich vermute, ich muss den server noch so konfigurieren, dass er nicht die opnsense als dns nutzt.

[meyergru]

Nein, das ist nicht notwendig. Ich würde mal schauen, welchen Weg die DNS-Update-Pakete nehmen (also TCPdump auf der OpnSense). Vielleicht ist noch etwas falsch konfiguriert.

Die einzige Möglichkeit wäre, dass der DNS-Server, dem Du die Updates schickst, zufällig in Deinem internen Unbound-DNS auf die interne IP umgelenkt wird. Deswegen muss man dafür einen eigenen DNS-Namen nehmen, der ungleich dem Webserver-DNS-Namen ist, z.B. ns.domain.de vs. www.domain.de. Und dann trägt man die lokale IP nur für www.domain.de ein, nicht für ns.domain.de.

[Simaryp]

Da weiß ich ad hoc nicht, wie das geht. Ich muss da für heute auch eine Pause einlegen.

Die Regeln zum DNS umleiten sind so aufgesetzt, dass source alles ist, bis auf die mac adresse des Servers.