Ich hoffe ich hab dein Problem richtig verstanden, dein Text ist leider wirklich etwas verwirrend.
Sorry, ich versuche es nochmal etwas sortierter ^^
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.
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.
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 ^^
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 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
