Unbound für VM Netzwerk

A

ath0

Well-Known Member
Moin,

ich bin Netzwerk technisch nicht der bewandertste, ggf. habe ich mich nur im Wald verlaufen und sehe nicht was sich als Lösung anbietet.
Ich baue gerade einen Server konzeptionell neu auf, noch ist das auf ner Spielzeug maschine die bei 4 VMs in die Knie geht. Abzu lösen ist ein mailserver der eine Postgres als backend für user verwendet, da ich mit Zertifikaten so meine schmerzen habe, nutze ich smallstep-ca. Die 3 Services sind in VMs die via vm-bhyve managed werden, auch das netz für die VMs wird über vm-bhyve hoch gezogen. Ich habe unbound auf der Maschine direkt laufen, das kommt beim Starten aber nicht hoch, vermutlich weil im RC file "before: network" angegeben ist und das VM Netz in der Config genutzt wird. Der Unbound selbst bindet auf 127.0.0.1.
Probiert habe ich mit local-unbound und unbound aus den ports, aktuell bin ich auf 13.3-RELEASE.
Wer hat eine idee wie ich unbound beim boot der Maschine zum Starten bekomme, bzw. geht das überhaupt so?
Mir erscheint es so als müsste das ganze auch in einer VM passieren wenn ich das so haben will, damit das Netz dann schon da ist.

Hoffe einer hat nen Tip für mich.
Gruß
ath0
 
Moin,

kannst du deinen Beitrag nochmal in Einzelschritten detaillierter (und mit mehr Rechtschreibkorrektur) und ggf. Screenshots wo du was genau machen willst, besser erläutern, damit es verständlicher wird? Aktuell verstehe ich noch nicht einmal, was dein Anliegen ist...
 
Der local-unbound ist nochmal was anderes als der in den ports. Müsste geklärt werden, was was ist. Den aus den ports willst du aber haben und im Zweifel auch eher nicht auf dem host laufen haben.
Da ich selbst nur die Hälfte verstehe (Netzplan wäre top) und du wahrscheinlich nochmal alles verwerfen und umplanen willst (nach Kenntniserlangung was man alles für Schabernack mit bhyve verschalten kann), wäre eben mein Rat nochmal genau studieren was vswitche sind und leisten.

Edit: Als kleinen Stupser bis dahin mein Tip den host als reinen VM-Träger zu sehen und netzwerkseitig als client zu betrachten/konfigurieren.
Sehr edel ausgefuchst wäre, dass man zwei NICports komplett autark in eine VM reinreicht (damit die auf dem host verschwinden und exklusiv einer VM zur Verfügung stehen). Da kann man eine OPNsense reinpacken, hat direkt unbound und kann via plugin Zertifikate via GUI klickern.
Alles weitere dann ebenfalls in VMs sowie den host clientmäßig der sense ggü. konfigurieren und so ausbauen.
Passthrough müssen aber Board, NIC und CPU unterstützen, reine Muskelkraft ist da nicht aussagekräftig.
 
Ich habe so etwas ähnliches laufen, statt richtiger VMs aber Jails. An den mitgelieferten Startscripten fummel ich prinzipiell nie rum und trotzdem steht dort
Code: 
# PROVIDE: local_unbound
# REQUIRE: FILESYSTEMS defaultroute netwait resolv
# BEFORE: NETWORKING
# KEYWORD: shutdown
drin. Deshalb denke ich nicht, dass das der Grund ist, warum unbound nicht startet.

Ich vermute, dass es an der Bindung an die IP 127.0.0.1 liegt. Vielleicht gibt es localhost da noch nicht.

Meine unbound.conf beginnt so:
Code: 
server:
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/local_unbound.pid
        auto-trust-anchor-file: /var/unbound/root.key
        interface: 0.0.0.0
        port: 53
        access-control: 127.0.0.0/16 allow
        do-ip4: yes
        do-ip6: no
        do-udp: yes
        do-tcp: yes
        hide-identity: yes
        hide-version: yes
        use-caps-for-id: yes
        num-threads: 2
        msg-cache-slabs: 4
        rrset-cache-slabs: 4
        infra-cache-slabs: 4
        key-cache-slabs: 4
Wie man sieht, bindet sich unbound an alle IPs und der Zugriff wird aber access-control eingeschränkt. Das müsstest Du ggf. anpassen.
Danach folgen nur noch includes mit statischen Einträgen.
 
Ich hoffe ich hab dein Problem richtig verstanden, dein Text ist leider wirklich etwas verwirrend.

Ich denke auch, dass es nichts mit dem Startupscript zu tun hat, das Networking bezieht sich auf den Service der dein Netzwerk hochbringt, das ist unabhängig von den VMs, und deine unbound.conf und die IPs dort, schaut sich das Startupscript auch nicht an ;)

Schau doch mal was im unbound log steht, ich denke eher das da eine Config Fehlerhaft ist. Wenn der Unbound nur auf 127.0.0.1 bindet, kann er aber sowieso nicht von den VMs genutzt werden. Du musst den dann auf eine IP binden, der aus dem VM Netz erreichbar ist.
 
medV2 schrieb:
Ich hoffe ich hab dein Problem richtig verstanden, dein Text ist leider wirklich etwas verwirrend.
Zum Vergrößern anklicken....
Sorry, ich versuche es nochmal etwas sortierter ^^
medV2 schrieb:
Ich denke auch, dass es nichts mit dem Startupscript zu tun hat, das Networking bezieht sich auf den Service der dein Netzwerk hochbringt, das ist unabhängig von den VMs, und deine unbound.conf und die IPs dort, schaut sich das Startupscript auch nicht an ;)

Schau doch mal was im unbound log steht, ich denke eher das da eine Config Fehlerhaft ist. Wenn der Unbound nur auf 127.0.0.1 bindet, kann er aber sowieso nicht von den VMs genutzt werden. Du musst den dann auf eine IP binden, der aus dem VM Netz erreichbar ist.
Zum Vergrößern anklicken....
Ich nutze pf um den traffic nach Außen zu reglementieren und dementsprechend habe ich folgendes configuriert, Namesauflösung funktioniert auch nach manuellem start von unbound.
rdr pass on $int_if proto { udp tcp } from $nat_net to port 53 -> 127.0.0.1 port 53

Jetzt nochmal von vorne.
Ich habe einen Server der seit ewigkeiten z.b. meine Mails zuverlässig zustellt aber auch noch einen haufen anderen krempel macht. Das ganze habe ich vor ca 7 Jahren auf jails migriert, das ist mir zu kompliziert und umständlich, daher will ich das vermeindlich einfachere Konzept mit VMs probieren.

server_schematisch.png
Das Bild soll schematisch darstellen was ich versuche, das was mich aber interessiert, wie bekomme ich Unbound zum starten überredet, denn ist die Maschine oben, startet das teil ohne Probleme und tut dann seinen dienst. Alles andere funktioniert wie ich das möchte.

Im log von unbound sehe ich aktuell, "Server" gerade wieder gestartet:
[1712679172] unbound[3291:0] info: server stats for thread 3: 2 queries, 2 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
[1712679172] unbound[3291:0] info: server stats for thread 3: requestlist max 0 avg 0 exceeded 0 jostled 0
[1712679172] unbound[3291:0] info: mesh has 0 recursion states (0 with reply, 0 detached), 0 waiting replies, 0 recursion replies sent, 0 replies dropped, 0 states jostled out
[1712679172] unbound[3291:0] debug: cache memory msg=132184 rrset=132184 infra=11492 val=132400
[1712679172] unbound[3291:0] debug: comm_point_close of 3: event_del
[1712679172] unbound[3291:0] debug: comm_point_close of 4: event_del
[1712679172] unbound[3291:0] debug: comm_point_close of 12: event_del
[1712679172] unbound[3291:0] debug: Exit cleanup.
[1712679172] unbound[3291:0] debug: switching log to stderr

Der letzte Eintrag ist also vom letzten herunterfahren.
In messages findet man nichts mehr von heute:
Apr 6 10:46:57 test01 sam[1086]: /usr/local/etc/rc.d/unbound: WARNING: failed precmd routine for unbound
Apr 6 10:48:13 test01 sam[1101]: /usr/local/etc/rc.d/unbound: WARNING: failed precmd routine for unbound
Apr 6 10:48:40 test01 sam[1117]: /usr/local/etc/rc.d/unbound: WARNING: failed precmd routine for unbound

Unbound aktuell:
# service unbound status
unbound is not running.
Keiner Zuhause

Starte ich das ding jetzt ...
# service unbound start
Obtaining a trust anchor...
Starting unbound.
[1712693735] unbound[1639:0] debug: creating udp4 socket 127.0.0.1 53
[1712693735] unbound[1639:0] debug: creating tcp4 socket 127.0.0.1 53
# service unbound status
unbound is running as pid 1640.

Crotchmaster, Danke für deine Antwort, ich sehe es ähnlich wie du, aber kann es richtig sein das ich einen Dienst auf alle interfaces binde die es gibt um später dann dafür sorgen zu müssen das keiner dran kommt? Bin ich von Freebsd seit ca 20 Jahren nicht gewohnt sowas. Ich hatte angenommen das local_unbound eine sonderlocke ist und daher Unbound aus den Ports genommen ... da ist das aber auch genau so. Verstehe ich einfach was falsches unter DNS und man will das das ding nicht an genau die IP gebunden wird die man für gewisse kommunikation nutzen will? Im Zweifel würde ich den von dir beschriebenen Weg gehen, aber das fühlt sich falsch an ^^
crotchmaster schrieb:
Ich vermute, dass es an der Bindung an die IP 127.0.0.1 liegt. Vielleicht gibt es localhost da noch nicht.

Meine unbound.conf beginnt so:
Code: 
server:
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/local_unbound.pid
        auto-trust-anchor-file: /var/unbound/root.key
        interface: 0.0.0.0
        port: 53
        access-control: 127.0.0.0/16 allow
        do-ip4: yes
        do-ip6: no
        do-udp: yes
        do-tcp: yes
        hide-identity: yes
        hide-version: yes
        use-caps-for-id: yes
        num-threads: 2
        msg-cache-slabs: 4
        rrset-cache-slabs: 4
        infra-cache-slabs: 4
        key-cache-slabs: 4
Wie man sieht, bindet sich unbound an alle IPs und der Zugriff wird aber access-control eingeschränkt. Das müsstest Du ggf. anpassen.
Danach folgen nur noch includes mit statischen Einträgen.
Zum Vergrößern anklicken....

Zum abschluss noch ein auszug meiner Config.
server:
# log verbosity
verbosity: 8
logfile: "/log/unbound.log"


interface: 127.0.0.1
port: 53
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.1/32 allow

root-hints: "/usr/local/etc/unbound/root.hints"
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: yes
cache-min-ttl: 3600
cache-max-ttl: 86400
prefetch: yes
num-threads: 4
msg-cache-slabs: 8
rrset-cache-slabs: 8
infra-cache-slabs: 8
key-cache-slabs: 8
rrset-cache-size: 256m
msg-cache-size: 128m
so-rcvbuf: 1m
private-address: 10.0.0.0/8

Ich hoffe das war jetzt ein wenig besser, ich hätte das Drumrum mal weglassen sollen, das tut ja und der Text wäre dann weniger verwirrend gewesen. Sorry dafür.


Edit: jetzt hätte ich es fast vergessen, in meiner Proxmox umgebung für die Arbeit läuft unbound in einem LXC auch ohne Probleme und ist ähnlich (angelehnt ... entfernt verwandt ... so übern daumen hingekotzt ^^) konfiguriert.

Gruß
ath0
 
KobRheTilla schrieb:
Vielleicht liegt es daran, dass unbound nicht startet.
Lass auch mal unbound-checkconf laufen.

Rob
Zum Vergrößern anklicken....
Leider nein, die Zeile habe ich erst nachträglich eingefügt, denn sonst loged Unbound irgendwie nirgens wirklich hin, bisschen was ist in mesages zu finden, aber das bringt wenig ... gut, das Log von Unbound ist jetzt auch nicht sonderlich hilfreich ^^
Der pfad ist auch tatsächlich korrekt und ist relativ zum config Verzeichniss, keine ahnung ob man das irgendwie ändern könnte, ist aber aktuell brauchbar für mich erstmal.

Hier mal was unbound-checkconf sagt:
# unbound-checkconf
unbound-checkconf: no errors in /usr/local/etc/unbound/unbound.conf

Gruß
ath0
 
Obwohl ich eher dazu neige DNS auch nicht auf dem Host laufen zu lassen und das in eine eigene Instanz packe, habe ich doch in einem Fall einen loacl_unbound aus Faulheit direkt laufen. Ich habe gerade mal an der config etwas rumgespielt und (zumindest) local_unbound ist unbeeindruckt davon, ob der bind nur auf localhost ist oder sonstigen IP-Spielereien mit Ausnahme eines bind auf eine nicht vorhandene IP...er startet immer brav auch nach reboot.

Eine Sache ist mir aber ins Auge gesprungen, was ich so bei mir noch nie bewusst wahrgenommen habe:
ath0 schrieb:
Apr 6 10:46:57 test01 sam[1086]: /usr/local/etc/rc.d/unbound: WARNING: failed precmd routine for unbound
Apr 6 10:48:13 test01 sam[1101]: /usr/local/etc/rc.d/unbound: WARNING: failed precmd routine for unbound
Apr 6 10:48:40 test01 sam[1117]: /usr/local/etc/rc.d/unbound: WARNING: failed precmd routine for unbound
Zum Vergrößern anklicken....
Wer bitte sind sam[1086], sam[1101] und sam[1117]? Vllt. habe ich auch nur einen Knoten im Hirn...
 
Ego schrieb:
Obwohl ich eher dazu neige DNS auch nicht auf dem Host laufen zu lassen und das in eine eigene Instanz packe, habe ich doch in einem Fall einen loacl_unbound aus Faulheit direkt laufen. Ich habe gerade mal an der config etwas rumgespielt und (zumindest) local_unbound ist unbeeindruckt davon, ob der bind nur auf localhost ist oder sonstigen IP-Spielereien mit Ausnahme eines bind auf eine nicht vorhandene IP...er startet immer brav auch nach reboot.

Eine Sache ist mir aber ins Auge gesprungen, was ich so bei mir noch nie bewusst wahrgenommen habe:

Wer bitte sind sam[1086], sam[1101] und sam[1117]? Vllt. habe ich auch nur einen Knoten im Hirn...
Zum Vergrößern anklicken....
sam ist ein username das in Klammern PIDs der shell in der ich das root terminal offen hatte.

Ich raffe das nicht, ich lasse das Teil ja schon nur an localhost lauschen um das Problem zu umgehen, sonst würde ich das lieber im vm-nat lauschen lassen. Ich werde die config jetzt zerpflücken mal gucken ob ich den fehler finde, sonst muss ich den umzug anders gestalten ... pläne sind ja da um sie zu ändern ne ...

Danke dennoch euch allen :)
Wenn ich den fehler gefunden habe werde ich berichten. ^^
 
Auf meinem FreeBSD-Server hatte ich das damals so gemacht und das waren die einzigen Configs zum Thema Unbound:

Code: 
$ cat /var/unbound/forward.conf
forward-zone:
name: "."
forward-addr: 9.9.9.9

$ local-unbound-setup

Du koenntest das ja mal so als Minimalsetup testen und nach nach und nach deinen Beduerfnissen anpassen und schauen, ab welchem Punkt es nicht mehr geht. Vorher muesstest Du allerdings deine unbound.conf und sonstigen unbound-configs sichern und loeschen, damit alles frisch und sauber ist.
 
midnight schrieb:
Auf meinem FreeBSD-Server hatte ich das damals so gemacht und das waren die einzigen Configs zum Thema Unbound:

Code: 
$ cat /var/unbound/forward.conf
forward-zone:
name: "."
forward-addr: 9.9.9.9

$ local-unbound-setup

Du koenntest das ja mal so als Minimalsetup testen und nach nach und nach deinen Beduerfnissen anpassen und schauen, ab welchem Punkt es nicht mehr geht. Vorher muesstest Du allerdings deine unbound.conf und sonstigen unbound-configs sichern und loeschen, damit alles frisch und sauber ist.
Zum Vergrößern anklicken....
Danke dir, das werde ich als ausgangspunkt nehmen :)
Nächste Woche sollte ich wieder mehr Zeit dafür haben, die letzten Tagen war nicht all zuviel Zeit für Computereien ... abgesehen von der Täglichen Arbeit.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben