Hallo

Heute hab ich OPNsense aktualisiert von 23.irgendwas auf 24.1.1. Und
dabei aufgefallen ist mir zuerst das er den squid gleich mal ungefragt
mit abgeräumt hat.

Der Ließ sich zwar anschließend neu installieren rennt aber bei jedem
start sofort in einen SegFault und ich finde keinen grund dafür. Aber
das nur nebenbei. Lt. pkg Version 6.6 entfernt und dann 6.6 (von mir)
neu installiert. Häh?

Neu dazu gekommen ist nun "Kea DHCP", offenbar als Alternatives angebot
zum ISC DHCPd der; wie man so hört; nicht mehr weiter entwickelt würde.

Von Kea hab ich noch nie gehört. Kennt den jemand?

Damit habe ich jetzt aber in Grunde das gleiche Problem wie mit unbound
(default) und dnsmasq (offenbar AUCH Default) und OpenDNS (auch
Default). WHY (default)? :-(

Der Knackpunkt ist: Ich will EINEN Dienst für EINE Aufgabe - und alle
anderen raus schmeißen können damit sie weder stören noch versehentlich
kompromittiert und evtl. aktiviert werden können. Auf einem Router
hielte ich das für normal und Sinnvoll.

Aber das sind nicht etwa plugins sondern packages und die kann man nur
auf "lock" setzen oder reinstallieren, was beides nicht das richtige
ist. Heißt: die gehören zum System; lt. beschluß der Macher vermutlich;
und ich kann nichts davon löschen.

Nun ist es mir testweise zwar schon gelungen Unbound nur auf einige
Interfaces zu binden und dnsmasq auf andere - mit einem anderen Port.
Damit könnten sie parallel laufen, aber das ist nur eine Krücke und
genau das gegenteil von erwünschten. Temporär, bei einem Wechsel ist das
okay.

Und mit Kea und ISC dhcpd ist's noch schlimmer. Kea will nicht starten
weil er auf den beiden eingestellten interfaces "kein fallback"
aktivieren kann wg. "address in use". Aber ISC ist auf diesen beiden
Interfaces überhaupt nicht aktiviert, der läuft nur auf 2 anderen
interfaces. Das sind allerdings VLANs und eines davon ist das physischen
interface.

Die Konstellation ist also wieder mal ein Hauruck-Konzept als Einzige
Lösung. Den einen komplett deaktivieren und hoffen das dann der andere
endlich die Füße auf den Boden bekommt und startet. Dabei wird das
Rauswerfen des dann an sich obsoleten Dienstes aktiv verhindert. Was
soll das?

Genau wie beim DNS. Wer Zum Teufel braucht ZWEI DNS-Server zugleich auf
EINEM Router? Und OpenDNS als Filter ist ja ein nettes Angebot aber wenn
ich es nicht will, dann will ich es auch raus werfen können.

Man kann auch Bind dazu Installieren, das wäre der Dritte DNS. Aber die
anderen wird man dennoch nicht los, nur den Bind kann man wieder raus
werfen. WFT?

Einerseits mag die Verzahnung dazwischen ja gut sein, das z.b. der dhcpd
ein Static lease auch im DNS eintragen könnte. Aber wenn das; oder
anderes; verhindert das man stück für Stück umsteigen kann auf den
anderen/Nachfolge-Dienst oder die sich sonstwie gegenseitig beharken
dann baut man m.E. Doch absichtliche Fallstricke in so ein System. Und
die Übersichtlichkeit; nicht nur im Services Menü; der WebUI geht dabei
m.E. auch noch flöten, aber das ist nur ein Randproblem.

Hat jemand einen Tip wie ich den Kea zum laufen bekomme oder muß ich
statt der VLANs jetzt ein bündel echte NICs in diese Kiste werfen - mit
getrennten Kabeln zu dem Managed Switch der sonst eigentlich die VLANs
auseinander dividierte?

Das log sagt (Neuer=Oben)

> 2024-02-09T23:45:56 Warning kea-dhcp4 WARN [kea-dhcp4.dhcpsrv.0x832d71000] DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
> 2024-02-09T23:45:56 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x832d71000] DHCP4_OPEN_SOCKETS_FAILED maximum number of open service sockets attempts: 0, has been exhausted without success
> 2024-02-09T23:45:56 Warning kea-dhcp4 WARN [kea-dhcp4.dhcpsrv.0x832d71000] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface vlan0.5, reason: failed to bind fallback socket to address 192.168.5.2, port 67, reason: Address already in use - is another DHCP server running?
> 2024-02-09T23:45:56 Warning kea-dhcp4 WARN [kea-dhcp4.dhcpsrv.0x832d71000] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface vlan0.10, reason: failed to bind fallback socket to address 192.168.10.2, port 67, reason: Address already in use - is another DHCP server running?

N.B. Das log zum dhcpd lügt auch. Der meldet seine konfig unter
/etc/dhcpd.conf aber wenn man dort rein schaut findet sich keine. Da ist
nur eine dhclient.conf sonst nix.

OBTW. Squid aktiviert, mit zurückgesetztem Cache, Restarted und:

> Segmentation fault
> Performing sanity check on squid configuration.
> 2024/02/10 01:20:46| Processing Configuration File: /usr/local/etc/squid/squid.conf (depth 0)
> 2024/02/10 01:20:46| Processing Configuration File: /usr/local/etc/squid/pre-auth/40-snmp.conf (depth 1)
> 2024/02/10 01:20:46| Processing Configuration File: /usr/local/etc/squid/pre-auth/dummy.conf (depth 1)
> 2024/02/10 01:20:46| Processing Configuration File: /usr/local/etc/squid/pre-auth/parentproxy.conf (depth 1)
> 2024/02/10 01:20:46| Processing Configuration File: /usr/local/etc/squid/auth/dummy.conf (depth 1)
> 2024/02/10 01:20:46| Processing Configuration File: /usr/local/etc/squid/post-auth/dummy.conf (depth 1)
> 2024/02/10 01:20:46| Set Current Directory to /var/squid/cache
> Segmentation fault

Und WAS darf ich da als Grund für den SegFault raten? mit 'squid -z' die
cachedirs initialisiert habe ich - wie bei der neuinstallation angegeben.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

Am 10.02.2024 01:44 Uhr schrieb Kay Martinen:

> Der Ließ sich zwar anschließend neu installieren rennt aber bei jedem
> start sofort in einen SegFault und ich finde keinen grund dafür. Aber
> das nur nebenbei. Lt. pkg Version 6.6 entfernt und dann 6.6 (von mir)
> neu installiert. Häh?

Hast du das schon gemeldet?

> Neu dazu gekommen ist nun "Kea DHCP", offenbar als Alternatives
> angebot zum ISC DHCPd der; wie man so hört; nicht mehr weiter
> entwickelt würde.
>
> Von Kea hab ich noch nie gehört. Kennt den jemand?

Ich habe davon schon gehört. Kann DHCPv4 und DHCPv6.

> Aber das sind nicht etwa plugins sondern packages und die kann man
> nur auf "lock" setzen oder reinstallieren, was beides nicht das
> richtige ist. Heißt: die gehören zum System; lt. beschluß der Macher
> vermutlich; und ich kann nichts davon löschen.

Dann musst du dir ein anderes OS suchen.

> Nun ist es mir testweise zwar schon gelungen Unbound nur auf einige
> Interfaces zu binden und dnsmasq auf andere - mit einem anderen Port.
> Damit könnten sie parallel laufen, aber das ist nur eine Krücke und
> genau das gegenteil von erwünschten. Temporär, bei einem Wechsel ist
> das okay.

Und warum willst du 2 DNS-Server haben?

> Und mit Kea und ISC dhcpd ist's noch schlimmer. Kea will nicht
> starten weil er auf den beiden eingestellten interfaces "kein
> fallback" aktivieren kann wg. "address in use". Aber ISC ist auf
> diesen beiden Interfaces überhaupt nicht aktiviert, der läuft nur auf
> 2 anderen interfaces. Das sind allerdings VLANs und eines davon ist
> das physischen interface.

> Die Konstellation ist also wieder mal ein Hauruck-Konzept als Einzige
> Lösung. Den einen komplett deaktivieren und hoffen das dann der
> andere endlich die Füße auf den Boden bekommt und startet. Dabei wird
> das Rauswerfen des dann an sich obsoleten Dienstes aktiv verhindert.
> Was soll das?

Warum brauchst du 2 DHCP-Server?
dhcpd ist auf dem Abstellgleis und wird früher oder später überall
verschwinden.

> Genau wie beim DNS. Wer Zum Teufel braucht ZWEI DNS-Server zugleich
> auf EINEM Router? Und OpenDNS als Filter ist ja ein nettes Angebot
> aber wenn ich es nicht will, dann will ich es auch raus werfen können.

> Man kann auch Bind dazu Installieren, das wäre der Dritte DNS. Aber
> die anderen wird man dennoch nicht los, nur den Bind kann man wieder
> raus werfen. WFT?

Ich glaube das OS ist nicht das, was du haben willst.

> Hat jemand einen Tip wie ich den Kea zum laufen bekomme oder muß ich
> statt der VLANs jetzt ein bündel echte NICs in diese Kiste werfen -
> mit getrennten Kabeln zu dem Managed Switch der sonst eigentlich die
> VLANs auseinander dividierte?
>
> Das log sagt (Neuer=Oben)
>
> > 2024-02-09T23:45:56 Warning kea-dhcp4 WARN
> > [kea-dhcp4.dhcpsrv.0x832d71000] DHCPSRV_NO_SOCKETS_OPEN no
> > interface configured to listen to DHCP traffic
> > 2024-02-09T23:45:56 Informational kea-dhcp4
> > INFO [kea-dhcp4.dhcp4.0x832d71000] DHCP4_OPEN_SOCKETS_FAILED
> > maximum number of open service sockets attempts: 0, has been
> > exhausted without success 2024-02-09T23:45:56 Warning
> > kea-dhcp4 WARN [kea-dhcp4.dhcpsrv.0x832d71000]
> > DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open
> > socket on interface vlan0.5, reason: failed to bind fallback socket
> > to address 192.168.5.2, port 67, reason: Address already in use -
> > is another DHCP server running? 2024-02-09T23:45:56

Da läuft schon ein DHCP-Server. Identifiziere den (ss -lup als root)
und stelle den ab.

> OBTW. Squid aktiviert, mit zurückgesetztem Cache, Restarted und:
>
> > Segmentation fault
> > Performing sanity check on squid configuration.
> > 2024/02/10 01:20:46| Processing Configuration File:
> > /usr/local/etc/squid/squid.conf (depth 0) 2024/02/10 01:20:46|
> > Processing Configuration File:
> > /usr/local/etc/squid/pre-auth/40-snmp.conf (depth 1) 2024/02/10
> > 01:20:46| Processing Configuration File:
> > /usr/local/etc/squid/pre-auth/dummy.conf (depth 1) 2024/02/10
> > 01:20:46| Processing Configuration File:
> > /usr/local/etc/squid/pre-auth/parentproxy.conf (depth 1) 2024/02/10
> > 01:20:46| Processing Configuration File:
> > /usr/local/etc/squid/auth/dummy.conf (depth 1) 2024/02/10 01:20:46|
> > Processing Configuration File:
> > /usr/local/etc/squid/post-auth/dummy.conf (depth 1) 2024/02/10
> > 01:20:46| Set Current Directory to /var/squid/cache Segmentation
> > fault
>
> Und WAS darf ich da als Grund für den SegFault raten? mit 'squid -z'
> die cachedirs initialisiert habe ich - wie bei der neuinstallation
> angegeben.

Gibt es denn den Pfad überhaupt?

--
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

Am 10.02.24 um 11:12 schrieb Marco Moock:
> Am 10.02.2024 01:44 Uhr schrieb Kay Martinen:
>
>> Der Ließ sich zwar anschließend neu installieren rennt aber bei jedem
>> start sofort in einen SegFault und ich finde keinen grund dafür. Aber
>> das nur nebenbei. Lt. pkg Version 6.6 entfernt und dann 6.6 (von mir)
>> neu installiert. Häh?
>
> Hast du das schon gemeldet?

Nein. Ich hab erst mal angenommen das läge an irgendwelchen
(versteckten) abhängigkeiten oder dem Wechsel der Hauptversions-Nummer.

Das es die gleiche Version ist habe ich auch erst danach im install-log
entdeckt.

Was den SegFault angeht. Mal sehen.

>> Neu dazu gekommen ist nun "Kea DHCP", offenbar als Alternatives

>> Von Kea hab ich noch nie gehört. Kennt den jemand?
>
> Ich habe davon schon gehört. Kann DHCPv4 und DHCPv6.

Ja schön. Und ein Reliant Robin könnte auch zum Space Shuttle werden -
wenn man Raketen dran bastelt -> Top Gear! ;-)

Im übrigens ist es nicht mal eine Alternative. Denn dann könnte man ja
einen davon los werden.

>> Aber das sind nicht etwa plugins sondern packages und die kann man
>> nur auf "lock" setzen oder reinstallieren, was beides nicht das
>> richtige ist. Heißt: die gehören zum System; lt. beschluß der Macher
>> vermutlich; und ich kann nichts davon löschen.
>
> Dann musst du dir ein anderes OS suchen.

Eines das sich Professionell und Routing auf die Fahne schrieb, einem
aber nicht ungefragt ZWEI DHCP-Server installiert? Hmm, da fiele mit nur
ein Generisches OS ein. Nicht wirklich hilfreich oder?

>> Nun ist es mir testweise zwar schon gelungen Unbound nur auf einige
>> Interfaces zu binden und dnsmasq auf andere - mit einem anderen Port.
>> Damit könnten sie parallel laufen, aber das ist nur eine Krücke und
>> genau das gegenteil von erwünschten. Temporär, bei einem Wechsel ist
>> das okay.
>
> Und warum willst du 2 DNS-Server haben?

Will ich nicht. Was ich wollen würde wäre:

EINEN DNS zu benutzten - und EINEN DHCPd. Und nur DIE.
Alternativ würde ich wollen das ich den einen nutzen könnte und den
anderen vorbereiten könnte (durch übertragen der static-leases, der
zonen-dateien o.a.). Und den alten dann deaktiviere, den neuen Aktiviere
und den alten entfernen. Geht aber nicht.

Ab jetzt (v 24.x) gehört zu OPN offenbar:

Kea DHCP
ISC DHCP
Dnsmasq
OpenDNS
Unbound

und offenbar kann man keinen davon raus schmeißen - nur deaktivieren.

Und das findest du; oder sonst jemand; nicht seltsam?

Wenn beide DNS/dhcpd auf unterschiedlichen interfaces nebeneinander
arbeiten könnten dann könnte man die mit Phantasie ja noch parallel
nutzen - was die "ist installiert und bleibt es auch" Methodik nahe
legte. Aber auch das geht nicht.

>> Und mit Kea und ISC dhcpd ist's noch schlimmer. Kea will nicht
>> starten weil er auf den beiden eingestellten interfaces "kein
>> fallback" aktivieren kann wg. "address in use". Aber ISC ist auf
>> diesen beiden Interfaces überhaupt nicht aktiviert, der läuft nur auf
>> 2 anderen interfaces. Das sind allerdings VLANs und eines davon ist
>> das physischen interface.
>
>> Die Konstellation ist also wieder mal ein Hauruck-Konzept als Einzige
>> Lösung. Den einen komplett deaktivieren und hoffen das dann der
>> andere endlich die Füße auf den Boden bekommt und startet. Dabei wird
>> das Rauswerfen des dann an sich obsoleten Dienstes aktiv verhindert.
>> Was soll das?
>
> Warum brauchst du 2 DHCP-Server?

S.O. Brauche ich nicht. Aber wenn ein isc-dhcpd auf einem eth0 aktiv
wäre, dann sollte es doch möglich sein das ein kea dhcpd auf einem eth1
aktiv ist - auch wenn dies ein vlan0.x wäre.

> dhcpd ist auf dem Abstellgleis und wird früher oder später überall
> verschwinden.

Dann sollte er ab jetzt Deinstallierbar sein, oder?

>> Genau wie beim DNS. Wer Zum Teufel braucht ZWEI DNS-Server zugleich
>> auf EINEM Router?

>> Man kann auch Bind dazu Installieren, das wäre der Dritte DNS. Aber
>> die anderen wird man dennoch nicht los, nur den Bind kann man wieder
>> raus werfen. WFT?
>
> Ich glaube das OS ist nicht das, was du haben willst.

Benutzt/kennst DU es denn?

>> Hat jemand einen Tip wie ich den Kea zum laufen bekomme oder muß ich
>> statt der VLANs jetzt ein bündel echte NICs in diese Kiste werfen -
>> mit getrennten Kabeln zu dem Managed Switch der sonst eigentlich die
>> VLANs auseinander dividierte?
>>
>> Das log sagt (Neuer=Oben)
>>
>>> 2024-02-09T23:45:56 Warning kea-dhcp4 WARN
>>> [kea-dhcp4.dhcpsrv.0x832d71000] DHCPSRV_NO_SOCKETS_OPEN no
>>> interface configured to listen to DHCP traffic
>>> 2024-02-09T23:45:56 Informational kea-dhcp4
>>> INFO [kea-dhcp4.dhcp4.0x832d71000] DHCP4_OPEN_SOCKETS_FAILED
>>> maximum number of open service sockets attempts: 0, has been
>>> exhausted without success 2024-02-09T23:45:56 Warning
>>> kea-dhcp4 WARN [kea-dhcp4.dhcpsrv.0x832d71000]
>>> DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open
>>> socket on interface vlan0.5, reason: failed to bind fallback socket
>>> to address 192.168.5.2, port 67, reason: Address already in use -
>>> is another DHCP server running? 2024-02-09T23:45:56
>
> Da läuft schon ein DHCP-Server. Identifiziere den (ss -lup als root)
> und stelle den ab.

Nope. Das eigentliche Problem sehe ich eher darin das der kea oder der
isc nicht-NUR auf das Interface agieren auf das sie auch konfiguriert
sind. Wäre das so, so dürfte es dieses Problem gar nicht geben.

Beim ISC war ich bisher der Meinung (frühere Erfahrungen auf einem
Linux) das der auch wirklich nur auf den interfaces lauscht auf die er
auch eingerichtet ist. Bei kea weiß ich das nicht da ich den noch nicht
kenne.

>> OBTW. Squid aktiviert, mit zurückgesetztem Cache, Restarted und:
>>
>>> Segmentation fault
>>> Performing sanity check on squid configuration.
>>> 2024/02/10 01:20:46| Processing Configuration File:
>>> /usr/local/etc/squid/squid.conf (depth 0) 2024/02/10 01:20:46|
>>> Processing Configuration File:
>>> /usr/local/etc/squid/pre-auth/40-snmp.conf (depth 1) 2024/02/10
>>> 01:20:46| Processing Configuration File:
>>> /usr/local/etc/squid/pre-auth/dummy.conf (depth 1) 2024/02/10
>>> 01:20:46| Processing Configuration File:
>>> /usr/local/etc/squid/pre-auth/parentproxy.conf (depth 1) 2024/02/10
>>> 01:20:46| Processing Configuration File:
>>> /usr/local/etc/squid/auth/dummy.conf (depth 1) 2024/02/10 01:20:46|
>>> Processing Configuration File:
>>> /usr/local/etc/squid/post-auth/dummy.conf (depth 1) 2024/02/10
>>> 01:20:46| Set Current Directory to /var/squid/cache Segmentation
>>> fault
>>
>> Und WAS darf ich da als Grund für den SegFault raten? mit 'squid -z'
>> die cachedirs initialisiert habe ich - wie bei der neuinstallation
>> angegeben.
>
> Gibt es denn den Pfad überhaupt?

/etc gibt es natürlich und die cachedir's wurden ja auch angelegt. Die
anderen müsste ich erst nachschauen. Ich würde aber erst mal annehmen
das er sonst bei processing eher ein file not found melden müsste - wenn
die nicht da wären. Im übrigen war das ein Spätabendlicher Rant, also
Sorry für etwa drastische Wortwahl.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

Am 10.02.2024 19:31 Uhr schrieb Kay Martinen:

> Am 10.02.24 um 11:12 schrieb Marco Moock:
> > Am 10.02.2024 01:44 Uhr schrieb Kay Martinen:
> >
> >> Der Ließ sich zwar anschließend neu installieren rennt aber bei
> >> jedem start sofort in einen SegFault und ich finde keinen grund
> >> dafür. Aber das nur nebenbei. Lt. pkg Version 6.6 entfernt und
> >> dann 6.6 (von mir) neu installiert. Häh?
> >
> > Hast du das schon gemeldet?
>
> Nein. Ich hab erst mal angenommen das läge an irgendwelchen
> (versteckten) abhängigkeiten oder dem Wechsel der
> Hauptversions-Nummer.

Dann sollte da aber eine passende Fehlermeldung kommen.

> Was den SegFault angeht. Mal sehen.

Solltest du melden, denn wenn es keiner macht, wird die Ursache auch
nicht behoben.

> >> Neu dazu gekommen ist nun "Kea DHCP", offenbar als Alternatives
>
> >> Von Kea hab ich noch nie gehört. Kennt den jemand?
> >
> > Ich habe davon schon gehört. Kann DHCPv4 und DHCPv6.
>
> Ja schön. Und ein Reliant Robin könnte auch zum Space Shuttle werden
> - wenn man Raketen dran bastelt -> Top Gear! ;-)
>
> Im übrigens ist es nicht mal eine Alternative. Denn dann könnte man
> ja einen davon los werden.

Was spricht denn dagegen, dhcpd abzustellen/zu entfernen (falls das
geht) und Kea zu nutzen?

> >> Aber das sind nicht etwa plugins sondern packages und die kann man
> >> nur auf "lock" setzen oder reinstallieren, was beides nicht das
> >> richtige ist. Heißt: die gehören zum System; lt. beschluß der
> >> Macher vermutlich; und ich kann nichts davon löschen.
> >
> > Dann musst du dir ein anderes OS suchen.
>
> Eines das sich Professionell und Routing auf die Fahne schrieb, einem
> aber nicht ungefragt ZWEI DHCP-Server installiert? Hmm, da fiele mit
> nur ein Generisches OS ein. Nicht wirklich hilfreich oder?

Stimmt auch wieder...

> >> Nun ist es mir testweise zwar schon gelungen Unbound nur auf einige
> >> Interfaces zu binden und dnsmasq auf andere - mit einem anderen
> >> Port. Damit könnten sie parallel laufen, aber das ist nur eine
> >> Krücke und genau das gegenteil von erwünschten. Temporär, bei
> >> einem Wechsel ist das okay.
> >
> > Und warum willst du 2 DNS-Server haben?
>
> Will ich nicht. Was ich wollen würde wäre:
>
> EINEN DNS zu benutzten - und EINEN DHCPd. Und nur DIE.
> Alternativ würde ich wollen das ich den einen nutzen könnte und den
> anderen vorbereiten könnte (durch übertragen der static-leases, der
> zonen-dateien o.a.). Und den alten dann deaktiviere, den neuen
> Aktiviere und den alten entfernen. Geht aber nicht.

Das kannst du ja auf einem anderen System erstmal alles testen und da
vorbereiten und dann nur noch rüberspielen.

> Ab jetzt (v 24.x) gehört zu OPN offenbar:
>
> Kea DHCP
> ISC DHCP
> Dnsmasq
> OpenDNS
> Unbound
>
> und offenbar kann man keinen davon raus schmeißen - nur deaktivieren.

Dann deaktiviere die ungewünschten halt.

> Und das findest du; oder sonst jemand; nicht seltsam?

Doch.

> >> Und mit Kea und ISC dhcpd ist's noch schlimmer. Kea will nicht
> >> starten weil er auf den beiden eingestellten interfaces "kein
> >> fallback" aktivieren kann wg. "address in use". Aber ISC ist auf
> >> diesen beiden Interfaces überhaupt nicht aktiviert, der läuft nur
> >> auf 2 anderen interfaces. Das sind allerdings VLANs und eines
> >> davon ist das physischen interface.
> >
> >> Die Konstellation ist also wieder mal ein Hauruck-Konzept als
> >> Einzige Lösung. Den einen komplett deaktivieren und hoffen das
> >> dann der andere endlich die Füße auf den Boden bekommt und
> >> startet. Dabei wird das Rauswerfen des dann an sich obsoleten
> >> Dienstes aktiv verhindert. Was soll das?
> >
> > Warum brauchst du 2 DHCP-Server?
>
> S.O. Brauche ich nicht. Aber wenn ein isc-dhcpd auf einem eth0 aktiv
> wäre, dann sollte es doch möglich sein das ein kea dhcpd auf einem
> eth1 aktiv ist - auch wenn dies ein vlan0.x wäre.

Ja, aber nur dann, wenn man die beide passende Konfigurieren kann.

> > dhcpd ist auf dem Abstellgleis und wird früher oder später überall
> > verschwinden.
>
> Dann sollte er ab jetzt Deinstallierbar sein, oder?

Ja, aber deaktivierbar wäre auch ausreichend.

> >> Genau wie beim DNS. Wer Zum Teufel braucht ZWEI DNS-Server zugleich
> >> auf EINEM Router?
>
> >> Man kann auch Bind dazu Installieren, das wäre der Dritte DNS. Aber
> >> die anderen wird man dennoch nicht los, nur den Bind kann man
> >> wieder raus werfen. WFT?
> >
> > Ich glaube das OS ist nicht das, was du haben willst.
>
> Benutzt/kennst DU es denn?

Nein, aber wenn deine Beschreibung den Tatsachen entspricht, ist es
nicht so, wie du es gerne hättest.

> >> Hat jemand einen Tip wie ich den Kea zum laufen bekomme oder muß
> >> ich statt der VLANs jetzt ein bündel echte NICs in diese Kiste
> >> werfen - mit getrennten Kabeln zu dem Managed Switch der sonst
> >> eigentlich die VLANs auseinander dividierte?
> >>
> >> Das log sagt (Neuer=Oben)
> >>
> >>> 2024-02-09T23:45:56 Warning kea-dhcp4 WARN
> >>> [kea-dhcp4.dhcpsrv.0x832d71000] DHCPSRV_NO_SOCKETS_OPEN no
> >>> interface configured to listen to DHCP traffic
> >>> 2024-02-09T23:45:56 Informational kea-dhcp4
> >>> INFO [kea-dhcp4.dhcp4.0x832d71000] DHCP4_OPEN_SOCKETS_FAILED
> >>> maximum number of open service sockets attempts: 0, has been
> >>> exhausted without success 2024-02-09T23:45:56 Warning
> >>> kea-dhcp4 WARN [kea-dhcp4.dhcpsrv.0x832d71000]
> >>> DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open
> >>> socket on interface vlan0.5, reason: failed to bind fallback
> >>> socket to address 192.168.5.2, port 67, reason: Address already
> >>> in use - is another DHCP server running? 2024-02-09T23:45:56
> >
> > Da läuft schon ein DHCP-Server. Identifiziere den (ss -lup als root)
> > und stelle den ab.
>
> Nope. Das eigentliche Problem sehe ich eher darin das der kea oder
> der isc nicht-NUR auf das Interface agieren auf das sie auch
> konfiguriert sind. Wäre das so, so dürfte es dieses Problem gar nicht
> geben.

Dann prüfe bitte, welcher von beiden jetzt auf dem Interface lauscht
und sorge dann mal bei einem von beiden dafür, dass der nur da lauscht
wo er soll. Dann das gleiche mit dem 2.
Falls das nicht vorgesehen ist, musst du eben die Umstellung
anderweitig umsetzen.

> Beim ISC war ich bisher der Meinung (frühere Erfahrungen auf einem
> Linux) das der auch wirklich nur auf den interfaces lauscht auf die
> er auch eingerichtet ist. Bei kea weiß ich das nicht da ich den noch
> nicht kenne.

Ich auch nicht, aber es gibt Doku:
https://kb.isc.org/docs/kea-configuration-sections-explained
Da wird ganz am Anfang gezeigt, wie man die Interfaces konfiguriert.
Funktioniert das bei dir?

--
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

Am 10.02.24 um 01:44 schrieb Kay Martinen:
> Von Kea hab ich noch nie gehört. Kennt den jemand?
Ja, das ist aktuelle DHCP-Server vom ISC.
Tim

Marco Moock <mm+solani@dorfdsl.de> wrote:
> dhcpd ist auf dem Abstellgleis und wird früher oder später überall
> verschwinden.

Also das wage ich zu bezweifeln. Ja, SLAAC kann heute einen Teil
der Aufgaben übernehmen, aber in vielen Situationen wird man so
schnell nicht um DHCP rumkommen.

/ralph

Kay Martinen <usenet@martinen.de> wrote:
> Von Kea hab ich noch nie gehört. Kennt den jemand?

Ist einfach der Nachfolger. Ich hab gerade mein Netz drauf umgestellt,
war eigentlich halb so wild. Er ist halt meinem Gefühl nach auf
eher größere Installationen optimiert, ich weiß nicht ob man das
im Privaten Netz daheim wirklich alles braucht, was der kann.

Ich hab die Hoffnung, dass sich einer der "kleineren" DHCP-Server
als Alternative neben Kea durchsetzt. Abwarten.

> Und mit Kea und ISC dhcpd ist's noch schlimmer. Kea will nicht starten
> weil er auf den beiden eingestellten interfaces "kein fallback"
> aktivieren kann wg. "address in use". Aber ISC ist auf diesen beiden
> Interfaces überhaupt nicht aktiviert, der läuft nur auf 2 anderen
> interfaces. Das sind allerdings VLANs und eines davon ist das physischen
> interface.

Ich kenne OPNsense diesbezüglich nicht, aber bei mir läuft kea auf
nur einem Interface, und das ohne Schmerzen. Ist aber Debian.

/ralph

Am 19.02.2024 02:45 Uhr schrieb Ralph Aichinger:

> Marco Moock <mm+solani@dorfdsl.de> wrote:
> > dhcpd ist auf dem Abstellgleis und wird früher oder später überall
> > verschwinden.
>
> Also das wage ich zu bezweifeln.

Eine nicht mehr gewartete Software wird früher oder später an vielen
Stellen rausfliegen. Es gibt ja alternative DHCP-Server.

> Ja, SLAAC kann heute einen Teil der Aufgaben übernehmen, aber in
> vielen Situationen wird man so schnell nicht um DHCP rumkommen.

Hat auch keiner gesagt. Du kannst mit Kea weiterhin DHCPv4 und DHCPv6
nutzen.

--
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

Marco Moock <mm+solani@dorfdsl.de> wrote:
> Eine nicht mehr gewartete Software wird früher oder später an vielen
> Stellen rausfliegen. Es gibt ja alternative DHCP-Server.

Ah sorry, ich hab dich mißverstanden (war spät), wenn du die konkrete
Software meinst, dann gebe ich dir natürlich recht. Ich habe gedacht
du meinst das Protokoll als ganzes.

/ralph

Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>Ist einfach der Nachfolger. Ich hab gerade mein Netz drauf umgestellt,
>war eigentlich halb so wild. Er ist halt meinem Gefühl nach auf
>eher größere Installationen optimiert, ich weiß nicht ob man das
>im Privaten Netz daheim wirklich alles braucht, was der kann.

Das klingt plausibel, denn für kleinere Netze nimmt "man" ja dnsmasq,
dsa kann gleich alles. Ob man damit glücklich wird steht auf einem
anderen Blatt.

Kann kea inzwischen DHCP Replication?

>Ich hab die Hoffnung, dass sich einer der "kleineren" DHCP-Server
>als Alternative neben Kea durchsetzt. Abwarten.

Welche wären das neben dnsmasq?

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Das klingt plausibel, denn für kleinere Netze nimmt "man" ja dnsmasq,
> dsa kann gleich alles. Ob man damit glücklich wird steht auf einem
> anderen Blatt.

Der "kann gleich alles"-Aspekt war der, der mich ein bißchen
abgeschreckt hat, nachdem bind9 bei mir superproblemlos läuft,
auch mit DNS64, wollte ich bevorzugt eine reine DHCP-Lösung.

> Kann kea inzwischen DHCP Replication?

Ich hab mir das nicht angesehen, weil für meine Nutzung irrelevant,
aber ich vermute ja, oder was äquivalentes.

https://kb.isc.org/docs/aa-01617

Ich hab das Gefühl, die implementieren vor allem Features für
Serviceprovider und Enterprise-Nutzer, weil das diejenigen sind, die
ihnen das Essen auf den Tisch stellen ;)

>>Ich hab die Hoffnung, dass sich einer der "kleineren" DHCP-Server
>>als Alternative neben Kea durchsetzt. Abwarten.
>
> Welche wären das neben dnsmasq?

Keine Ahnung, es wäre ja vorstellbar, dass irgendjemand eine
Neuentwicklung startet. Bei den HTTP-Servern ist es ja auch so,
da wahr jahrzehntelang Apache, dann ngninx der "Standard",
und dann kommt mit Caddy was neues daher. Ja, vermutlich gibt
es bei DHCP-Servern weniger Business cases, aber vom Scope her
passt das schon noch für eine entschlossene Gruppe von Hobbyentwicklern,
wenn jemand der Sinn nach sowas steht.

Aber auch wenn dnsmasq sich stärker als Standardlösung durchsetzen
würde, wär schon viel gewonnen. Ich habe das Gefühl, das ist (noch)
nicht ganz der Fall.

Ich habe relativ oft das Szenario "ich brauch auf dem Subnet schnell
einen improvisierten DHCP-Server, um irgendeinen Switch oder ein IoT-
Device mit einer IP zu versorgen", z.B. von meinem Notebook aus. Bis
jetzt hab ich dafür isc-dhcp-server verwendet. Kea scheint mir dafür
fast ein bißchen zu sperrig. Vermutlich werde ich mir dafür dnsmasq
ansehen (oder was anderes, falls irgednwas daherkommt).

/ralph

Am 19.02.24 um 08:35 schrieb Ralph Aichinger:
> Marco Moock <mm+solani@dorfdsl.de> wrote:
>> Eine nicht mehr gewartete Software wird früher oder später an vielen
>> Stellen rausfliegen. Es gibt ja alternative DHCP-Server.
>
> Ah sorry, ich hab dich mißverstanden (war spät), wenn du die konkrete
> Software meinst, dann gebe ich dir natürlich recht. Ich habe gedacht
> du meinst das Protokoll als ganzes.

Naheliegender Irrtum da er ja nur "dhcpd" allgemein schrob - und nicht
"ISC-DHCPd". DER Kontext stand nur im Topic. Also GUT versteckt. :-)

Der war; und ist es noch; für mich allerdings auch mehr oder weniger
synonym. Lange benutzt, oft selbst per text konfiguriert und im allg.
tut er was er soll. Eigentlich fehlt mir da nix.

Zu den Hintergründen warum der nicht mehr weiter entwickelt würde und
man stattdessen einen neuen nehmen sollte habe ich weder gehört noch
gelesen. Vermutung: $Coder mucksch, mag altes nicht Flicken, will lieber
das Rad neu erfinden... = Business as usual.

Und: WIE sollte man einen ISC-DHCPd kompromittieren können - außer durch
massenhaft MACs um den Pool trocken zu legen? Würde wohl bei jedem dhcpd
funktionieren. Und ohne Zugriff auf den dhcpd-host wüßte ich da nix.
Jemand ne Idee? DoS per "Magischem" Ping ähh MAC???

Warum sollte man/ICH den also (zwangsweise) gewechselt-bekommen-müssen?

Bye/
/Kay

--
nix

Am 19.02.2024 14:27 Uhr schrieb Kay Martinen:

> Und: WIE sollte man einen ISC-DHCPd kompromittieren können - außer
> durch massenhaft MACs um den Pool trocken zu legen?

Ggf. durch Fehler n der Verarbeitung, z.B. durch Pufferüberläufe etc.
Ich halte das für eine eher unkritische Komponente, aber warum setzt
man noch darauf?

--
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

Kay Martinen <usenet@martinen.de> wrote:
> Zu den Hintergründen warum der nicht mehr weiter entwickelt würde und
> man stattdessen einen neuen nehmen sollte habe ich weder gehört noch
> gelesen. Vermutung: $Coder mucksch, mag altes nicht Flicken, will lieber
> das Rad neu erfinden... = Business as usual.

Ich vermute: Die Leute vom ISC brauchen einfach jemand der die
Weiterentwicklung finanziert, und das geht vermutlich einfacher
bei einem Produkt für komplexe Anforderungen wie Kea, weniger
bei einem Brot-und-Butter-Produkt wie dem isc-dhcpd.

Den Client haben sie ja AFAIK ganz aufgegeben, ohne Ersatz.

> Und: WIE sollte man einen ISC-DHCPd kompromittieren können - außer durch
> massenhaft MACs um den Pool trocken zu legen? Würde wohl bei jedem dhcpd
> funktionieren. Und ohne Zugriff auf den dhcpd-host wüßte ich da nix.
> Jemand ne Idee? DoS per "Magischem" Ping ähh MAC???

Prinzipiell ist bei jedem Prozess, der dem Netzwerk ausgesetzt wird,
eine Sicherheitslücke vorstellbar.

/ralph

Marco Moock <mm+solani@dorfdsl.de> wrote:
> Am 19.02.2024 14:27 Uhr schrieb Kay Martinen:
>
>> Und: WIE sollte man einen ISC-DHCPd kompromittieren können - außer
>> durch massenhaft MACs um den Pool trocken zu legen?
>
> Ggf. durch Fehler n der Verarbeitung, z.B. durch Pufferüberläufe etc.

Jo, siehe z.B.

https://www.cvedetails.com/vulnerability-list/vendor_id-64/product_id-17706/ISC-Dhcp.html

/ralph

Am 19.02.24 um 14:54 schrieb Ralph Aichinger:
> Marco Moock <mm+solani@dorfdsl.de> wrote:
>> Am 19.02.2024 14:27 Uhr schrieb Kay Martinen:
>>
>>> Und: WIE sollte man einen ISC-DHCPd kompromittieren können - außer
>>> durch massenhaft MACs um den Pool trocken zu legen?
>>
>> Ggf. durch Fehler n der Verarbeitung, z.B. durch Pufferüberläufe etc.
>
> Jo, siehe z.B.
>
> https://www.cvedetails.com/vulnerability-list/vendor_id-64/product_id-17706/ISC-Dhcp.html
Tja. Offenbar Pufferüberläufe, Memory Leaks, special craftet Packets
oder Many Packets u.s.w. was allesamt (beim überfliegen der Liste) eher
nur zu einem Denial of Service führt.

Im Schlimmsten falle muß man den DHCP-Server neu starten oder den Host
wenn wg. Leck der OOM-Reaper zuschlüge.

Ich hatte jetzt an so etwas "boshaftes" gedacht wie jede menge DCHP_REQ
mit differiernden MAC zu senden, und dessen DHCP_OFFER mit einem
passenden DHCP_ACK zu beantworten - bis der Pool ausgereizt ist und
keiner mehr eine IP bekommen könnte.

Ein DHCPd der keine Adressen für Leases frei hat und einer der
abgestützt ist machen sich m.E. gleich bemerkbar: Der Client bekommt
keine IP und gibt sich evtl. selbst eine aus dem für autoconfig
vorgesehenen Bereich.

In beiden Fällen startet man den Server neu und dann die Clients und
alles sollte wieder KNUT sein. :-)

Und der Vorteil von Kea DHCP ist jetzt WAS? Neues Programm = Neue
Fehler! = !ISC-DHCP Fehler? Toll! ;)

Ok, Ok. Wenn man einem Client so falsche routen DNS oder Gateways
unterschieben könnte wäre das ernster. Aber ich habe noch kein Linux
gesehen bei dem man ihm nicht verbieten könnte dynamisch bezogene Routen
zu ignorieren. Ist das nicht sowieso Standard-verhalten?

Bei Windows; der üblichen Zielplattform für Angriffe; ist mir die option
noch nicht aufgefallen. Und auch nicht jeder Client übernimmt alle
angebotenen Optionen die der DHCPd liefert. IMHO ist sogar der dhclient
da von haus aus arg sparsam eingestellt.

Bye/
/Kay

--
nix

Am 19.02.24 um 14:49 schrieb Ralph Aichinger:
> Kay Martinen <usenet@martinen.de> wrote:
>> Zu den Hintergründen warum der nicht mehr weiter entwickelt würde und
>> man stattdessen einen neuen nehmen sollte habe ich weder gehört noch
>> gelesen. Vermutung: $Coder mucksch, mag altes nicht Flicken, will lieber
>> das Rad neu erfinden... = Business as usual.
>
> Ich vermute: Die Leute vom ISC brauchen einfach jemand der die
> Weiterentwicklung finanziert, und das geht vermutlich einfacher
> bei einem Produkt für komplexe Anforderungen wie Kea, weniger
> bei einem Brot-und-Butter-Produkt wie dem isc-dhcpd.

Ulkig ist: Das ISC im Namen des "Produkts" habe ich immer so verstanden
das es der vom ISC selbst (oder im Auftrag) erstellte; und empfohlene
Standard ist. Okay, Finanzierung ist ja heute eh das wichtigste. Noch
Wichtiger als Kontinuität, Qualitäts-sicherung und alles andere.

> Den Client haben sie ja AFAIK ganz aufgegeben, ohne Ersatz.

DAVON habe ich sogar schon gehört. Das es nun auch den Server betrifft
noch nicht.

>> Und: WIE sollte man einen ISC-DHCPd kompromittieren können - außer durch
>> massenhaft MACs um den Pool trocken zu legen? Würde wohl bei jedem dhcpd
>> funktionieren. Und ohne Zugriff auf den dhcpd-host wüßte ich da nix.
>> Jemand ne Idee? DoS per "Magischem" Ping ähh MAC???
>
> Prinzipiell ist bei jedem Prozess, der dem Netzwerk ausgesetzt wird,
> eine Sicherheitslücke vorstellbar.
Schon Richtig. Aber So sachen wie Privileg Escalation dürfte mit
DHCP-Paketen allein wohl schwierig bis unmöglich werden oder?

Oder hab ich bei den CVE's einen übersehen wo du mit Millionen(?)
Paketen einen Buffer overflow im Host erreichst und damit Remote Code in
den Speicherbereich des DHCPd injizieren könntest - und der dann an
Root-rechte gelangt um den Router zu übernehmen?

Bye/
/Kay

--
nix

Am 19.02.2024 18:23 Uhr schrieb Kay Martinen:

> Am 19.02.24 um 14:54 schrieb Ralph Aichinger:
> > Marco Moock <mm+solani@dorfdsl.de> wrote:
> >> Am 19.02.2024 14:27 Uhr schrieb Kay Martinen:
> >>
> >>> Und: WIE sollte man einen ISC-DHCPd kompromittieren können - außer
> >>> durch massenhaft MACs um den Pool trocken zu legen?
> >>
> >> Ggf. durch Fehler n der Verarbeitung, z.B. durch Pufferüberläufe
> >> etc.
> >
> > Jo, siehe z.B.
> >
> > https://www.cvedetails.com/vulnerability-list/vendor_id-64/product_id-17706/ISC-Dhcp.html
> >
> Tja. Offenbar Pufferüberläufe, Memory Leaks, special craftet Packets
> oder Many Packets u.s.w. was allesamt (beim überfliegen der Liste)
> eher nur zu einem Denial of Service führt.
>
> Im Schlimmsten falle muß man den DHCP-Server neu starten oder den
> Host wenn wg. Leck der OOM-Reaper zuschlüge.
>
> Ich hatte jetzt an so etwas "boshaftes" gedacht wie jede menge
> DCHP_REQ mit differiernden MAC zu senden, und dessen DHCP_OFFER mit
> einem passenden DHCP_ACK zu beantworten - bis der Pool ausgereizt ist
> und keiner mehr eine IP bekommen könnte.

Dieses Problem besteht grundsätzlich bei DHCP - unabhängig von der
Implementierung.
Das muss man dann über Port-Security (802.1x kombiniert mit MAC-Filtern)
am Switch in den Griff bekommen.

> Und der Vorteil von Kea DHCP ist jetzt WAS? Neues Programm = Neue
> Fehler! = !ISC-DHCP Fehler? Toll! ;)

Die gefundenen Fehler werden behoben. Beim alten dhcpd eher
unwahrscheinlich.

> Ok, Ok. Wenn man einem Client so falsche routen DNS oder Gateways
> unterschieben könnte wäre das ernster. Aber ich habe noch kein Linux
> gesehen bei dem man ihm nicht verbieten könnte dynamisch bezogene
> Routen zu ignorieren. Ist das nicht sowieso Standard-verhalten?

DHCP ist kein sichere Protokoll. Jeder kann manipulierte Pakete
erzeugen. Man muss sows über portbasierte Firewalls restriktieren,
sodass nur am Switchport mit dem Server das DHCP-Offer ins Netz
gelangen darf.

> Bei Windows; der üblichen Zielplattform für Angriffe; ist mir die
> option noch nicht aufgefallen. Und auch nicht jeder Client übernimmt
> alle angebotenen Optionen die der DHCPd liefert. IMHO ist sogar der
> dhclient da von haus aus arg sparsam eingestellt.

Was soll der auch sonst machen?

--
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> Das klingt plausibel, denn für kleinere Netze nimmt "man" ja dnsmasq,
>> dsa kann gleich alles. Ob man damit glücklich wird steht auf einem
>> anderen Blatt.
>
>Der "kann gleich alles"-Aspekt war der, der mich ein bißchen
>abgeschreckt hat, nachdem bind9 bei mir superproblemlos läuft,
>auch mit DNS64, wollte ich bevorzugt eine reine DHCP-Lösung.

Das sehe ich ganz genauso.

>> Kann kea inzwischen DHCP Replication?
>
>Ich hab mir das nicht angesehen, weil für meine Nutzung irrelevant,
>aber ich vermute ja, oder was äquivalentes.
>
>https://kb.isc.org/docs/aa-01617
>
>Ich hab das Gefühl, die implementieren vor allem Features für
>Serviceprovider und Enterprise-Nutzer, weil das diejenigen sind, die
>ihnen das Essen auf den Tisch stellen ;)

Als Enterpreis nutzer bräuchte man DHCP failover und hübsche
Schnittstellen. omshell ist zwar eine Schnittstelle, aber beim besten
Willen nicht "hübsch".

>Ich habe relativ oft das Szenario "ich brauch auf dem Subnet schnell
>einen improvisierten DHCP-Server, um irgendeinen Switch oder ein IoT-
>Device mit einer IP zu versorgen", z.B. von meinem Notebook aus. Bis
>jetzt hab ich dafür isc-dhcp-server verwendet. Kea scheint mir dafür
>fast ein bißchen zu sperrig. Vermutlich werde ich mir dafür dnsmasq
>ansehen (oder was anderes, falls irgednwas daherkommt).

Ich fürchte, da wird es hingehen, ja.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402