Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #115804 > unrolled thread
| Started by | Tim Ritberg <tim@server.invalid> |
|---|---|
| First post | 2021-03-19 18:11 +0100 |
| Last post | 2021-04-01 14:19 +0200 |
| Articles | 20 on this page of 125 — 21 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-19 18:11 +0100
Re: Systemd kaputt? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-03-19 18:54 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-19 19:31 +0100
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-20 09:16 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-20 10:54 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-20 11:46 +0100
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-21 19:04 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-21 19:22 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-23 10:52 +0100
Re: Systemd kaputt? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-03-24 11:19 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-24 13:29 +0100
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-24 19:01 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-24 19:29 +0100
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-03-24 21:04 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-24 21:18 +0100
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 08:16 +0100
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 08:16 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-25 09:45 +0100
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-25 13:43 +0100
Re: Systemd kaputt? Tim Ritberg <tim@server.invalid> - 2021-03-25 14:58 +0100
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-03-25 18:44 +0100
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-02 20:49 +0200
Re: Systemd kaputt? Marcus Jodorf <trap@killfile.de> - 2021-03-26 05:31 +0100
Re: Systemd kaputt? Christian Garbs <mitch@cgarbs.de> - 2021-03-26 09:46 +0100
IPv6Präfixe weiterverteilen (was: Systemd kaputt?) Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2021-03-26 09:57 +0100
Re: IPv6Präfixe weiterverteilen (was: Systemd kaputt?) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-26 12:16 +0100
Re: IPv6Präfixe weiterverteilen Juergen Ilse <news@usenet-verwaltung.de> - 2021-03-27 14:56 +0000
Re: IPv6Präfixe weiterverteilen Kay Martinen <usenet@martinen.de> - 2021-03-30 19:41 +0200
Re: IPv6Präfixe weiterverteilen Juergen Ilse <news@usenet-verwaltung.de> - 2021-03-30 22:51 +0000
Re: IPv6Präfixe weiterverteilen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-03-31 08:47 +0200
Re: IPv6Präfixe weiterverteilen Marcel Logen <333200007110-0201@ybtra.de> - 2021-03-31 16:27 +0200
Re: IPv6Präfixe weiterverteilen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-03-31 17:45 +0200
Re: IPv6Präfixe weiterverteilen Marcel Logen <333200007110-0201@ybtra.de> - 2021-03-31 19:08 +0200
Re: IPv6Präfixe weiterverteilen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-03-31 19:43 +0200
Re: IPv6Präfixe weiterverteilen Kay Martinen <usenet@martinen.de> - 2021-03-31 20:09 +0200
Re: IPv6Präfixe weiterverteilen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-03-31 21:16 +0200
Re: IPv6Präfixe weiterverteilen Marcel Logen <333200007110-0201@ybtra.de> - 2021-03-31 21:57 +0200
Re: IPv6Präfixe weiterverteilen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-04-01 07:41 +0200
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-31 10:32 +0200
Re: IPv6Präfixe weiterverteilen Thomas Noll <-_tn_-@web.de> - 2021-03-31 09:12 +0000
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-31 20:09 +0200
Re: IPv6Präfixe weiterverteilen Kay Martinen <usenet@martinen.de> - 2021-03-31 21:06 +0200
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-03-26 20:36 +0100
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-02 21:14 +0200
Re: IPv6Präfixe weiterverteilen Thomas Noll <-_tn_-@web.de> - 2021-04-03 08:17 +0000
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-03 20:48 +0200
Re: IPv6Präfixe weiterverteilen Thomas Noll <-_tn_-@web.de> - 2021-04-03 19:36 +0000
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-12 20:17 +0200
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-13 09:11 +0200
Re: IPv6Präfixe weiterverteilen Thomas Noll <-_tn_-@web.de> - 2021-04-16 21:41 +0000
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-20 19:49 +0200
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-06 12:53 +0200
Re: IPv6Präfixe weiterverteilen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-04-06 11:48 +0000
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-06 14:42 +0200
Re: IPv6Präfixe weiterverteilen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-04-06 14:01 +0000
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-07 08:38 +0200
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-12 21:10 +0200
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-13 09:18 +0200
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-06-16 21:17 +0200
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-13 20:49 +0200
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-14 08:11 +0200
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-14 08:57 +0200
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-14 18:29 +0200
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-16 20:19 +0200
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-20 20:04 +0200
nftables für IPv6 (was: Re: IPv6Präfixe weiterverteilen) Christian Garbs <mitch@cgarbs.de> - 2021-04-12 21:51 +0200
Re: nftables für IPv6 Andreas Kohlbach <ank@spamfence.net> - 2021-04-12 21:32 -0400
Re: nftables für IPv6 Christian Garbs <mitch@cgarbs.de> - 2021-04-13 21:01 +0200
Re: nftables für IPv6 Kay Martinen <usenet@martinen.de> - 2021-04-13 23:09 +0200
Re: nftables für IPv6 Christian Garbs <mitch@cgarbs.de> - 2021-04-14 09:01 +0200
Re: nftables für IPv6 Kay Martinen <usenet@martinen.de> - 2021-04-14 20:12 +0200
Re: nftables für IPv6 Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-04-13 19:21 +0000
Re: IPv6Präfixe weiterverteilen Christian Garbs <mitch@cgarbs.de> - 2021-04-16 20:32 +0200
Re: IPv6Präfixe weiterverteilen Kay Martinen <usenet@martinen.de> - 2021-04-16 21:14 +0200
Re: IPv6Präfixe weiterverteilen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-17 09:53 +0200
Re: Systemd kaputt? Marcus Jodorf <trap@killfile.de> - 2021-03-26 13:20 +0100
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-27 09:27 +0100
Re: Systemd kaputt? Christian Garbs <mitch@cgarbs.de> - 2021-04-03 09:16 +0200
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-02 20:53 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-02 23:30 +0000
Re: Systemd kaputt? Andreas Kohlbach <ank@spamfence.net> - 2021-04-02 21:57 -0400
Re: Systemd kaputt? Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-04-03 05:39 +0200
Re: Systemd kaputt? Andreas Kohlbach <ank@spamfence.net> - 2021-04-03 06:22 -0400
Re: Systemd kaputt? Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-04-03 21:01 +0200
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-03 13:34 +0200
Re: Systemd kaputt? Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-04-03 21:17 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-03 10:35 +0000
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-03 15:29 +0200
Re: Systemd kaputt? Thomas Hochstein <thh@thh.name> - 2021-04-03 17:04 +0200
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-03 20:03 +0200
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 13:05 +0200
Re: Systemd kaputt? Andreas Kohlbach <ank@spamfence.net> - 2021-04-03 10:29 -0400
Re: Systemd kaputt? Arno Welzel <usenet@arnowelzel.de> - 2021-04-03 14:30 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-03 12:53 +0000
Re: Systemd kaputt? Thomas Noll <-_tn_-@web.de> - 2021-04-03 13:01 +0000
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 13:06 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-04 18:18 +0000
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-04 21:22 +0200
Re: Systemd kaputt? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-05 12:26 +0200
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-03 20:00 +0200
Re: Systemd kaputt? Marcel Logen <333200007110-0201@ybtra.de> - 2021-04-03 20:19 +0200
Re: Systemd kaputt? Marcus Jodorf <trap@killfile.de> - 2021-04-04 00:07 +0200
Re: Systemd kaputt? Paul Muster <exp-311221@news.muster.net> - 2021-04-04 08:30 +0200
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-03 15:29 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-03 13:42 +0000
Re: Systemd kaputt? Thomas Dorner <de.comp.os.unix.linux.misc.210403.dorner@spamgourmet.com> - 2021-04-03 19:45 +0200
Re: Systemd kaputt? Paul Muster <exp-311221@news.muster.net> - 2021-04-03 20:16 +0200
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-03 21:29 +0200
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 13:07 +0200
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-04 13:30 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-04 22:48 +0000
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 09:26 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 13:01 +0000
Re: Systemd kaputt? Andreas Kohlbach <ank@spamfence.net> - 2021-04-05 15:37 -0400
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-05 20:26 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 22:50 +0000
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-06 15:30 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-06 14:30 +0000
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-06 22:55 +0200
Re: Systemd kaputt? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 08:49 +0000
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-05 11:37 +0200
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 13:27 +0200
Re: Systemd kaputt? Kay Martinen <usenet@martinen.de> - 2021-04-05 14:43 +0200
Re: Systemd kaputt? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 16:22 +0200
Re: Systemd kaputt? Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-04-01 14:19 +0200
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-14 08:11 +0200 |
| Subject | Re: IPv6Präfixe weiterverteilen |
| Message-ID | <s56125$815$1@news1.tnib.de> |
| In reply to | #116621 |
Christian Garbs <mitch@cgarbs.de> wrote: >Da steht aber definitiv nichts von "hint" drinnen. >Auch strings(1) auf das Binary zeigt nichts mit "hint". Im Zweifel den Quelltext nach 62 durchsuchen? Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-04-14 08:57 +0200 |
| Subject | Re: IPv6Präfixe weiterverteilen |
| Message-ID | <s563oc$t8tn$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #116637 |
Mahlzeit! Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Christian Garbs <mitch@cgarbs.de> wrote: >>Da steht aber definitiv nichts von "hint" drinnen. >>Auch strings(1) auf das Binary zeigt nichts mit "hint". > > Im Zweifel den Quelltext nach 62 durchsuchen? Gute Idee! Außerhalb des durch yacc generierten Parsers taucht da keine 62 auf. Gruß, Chris "62 is the new 23" tian -- ....Christian.Garbs....................................https://www.cgarbs.de Ein Blizableiter auf dem Kirchturm ist das denkbar stärkste Misstrauensvotum gegen den lieben Gott. (Karl Krauss)
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-14 18:29 +0200 |
| Subject | Re: IPv6Präfixe weiterverteilen |
| Message-ID | <s57591$p2q$1@news1.tnib.de> |
| In reply to | #116640 |
Christian Garbs <mitch@cgarbs.de> wrote: >Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> Christian Garbs <mitch@cgarbs.de> wrote: > >>>Da steht aber definitiv nichts von "hint" drinnen. >>>Auch strings(1) auf das Binary zeigt nichts mit "hint". >> >> Im Zweifel den Quelltext nach 62 durchsuchen? > >Gute Idee! >Außerhalb des durch yacc generierten Parsers taucht da keine 62 auf. Mist. dann bin ich mit dem Latein am Ende, außer den Code zu inspizieren der die IA_PD Option erzeugt. Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-04-16 20:19 +0200 |
| Subject | Re: IPv6Präfixe weiterverteilen |
| Message-ID | <s5ckg8$gqpe$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #116657 |
Mahlzeit! Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Christian Garbs <mitch@cgarbs.de> wrote: >>>[wide-dhcpv6-client / prefix delegation length hint) >>Außerhalb des durch yacc generierten Parsers taucht da keine 62 auf. > > Mist. dann bin ich mit dem Latein am Ende, außer den Code zu > inspizieren der die IA_PD Option erzeugt. Da will ich eh noch reingucken, es gibt nämlich keine Beschreibung, was dem Script, das man in der Config definieren kann, alles an Parametern mitgegeben wird und wann das Script überhaupt ausgeführt wird. Es scheint nicht so zu sein, dass das Script bei "neuer Präfix empfangen" triggert. Dann kann ich aber den radvd nicht restarten und er verteilt weiterhin den alten Präfix (oder vermutlich gar keinen, wenn der alte abgelaufen ist). Oder vielleicht hat radvd ja auch noch eine Option "guck mal, ob sich was geändert hat". Gruß Christian -- ....Christian.Garbs....................................https://www.cgarbs.de ANIKI - das freie Anime- und Manga-Lexikon zum Mitmachen: http://www.aniki.info
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-04-20 20:04 +0200 |
| Subject | Re: IPv6Präfixe weiterverteilen |
| Message-ID | <s5n53a$sktk$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #116695 |
Mahlzeit!
Christian Garbs <mitch@cgarbs.de> wrote:
> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> Christian Garbs <mitch@cgarbs.de> wrote:
>
>>>>[wide-dhcpv6-client / prefix delegation length hint)
>
>>>Außerhalb des durch yacc generierten Parsers taucht da keine 62 auf.
>>
>> Mist. dann bin ich mit dem Latein am Ende, außer den Code zu
>> inspizieren der die IA_PD Option erzeugt.
>
> Da will ich eh noch reingucken[…]
Ich habe gestöbert und soweit ich das sehe, wird die IA_PD-Option nach
einem Timeout (Verlängerung der Loease oder sowas) mitgeschickt. Der
Wert wird dabei aus einer Antwort des des DHCP-Servers übernommen.
Ich habe keine Stelle gefunden, wo man den Wert von außen setzen
könnte, d.h. es wird kein expliziter Wert angefordert, aber es ist
sichergestellt, dass weitere Unterhaltungen mit dem Server den Wert
enthalten, den der Server beim ersten Mal geliefert hat.
Oder so ähnlich.
Und was genau das konfigurierbare Skript alles machen kann, habe ich
jetzt nicht untersucht, da ich den radvd inzwischen dank Thomas zur
Mitarbeit überreden konnte ("DecrementLifetimes Off;").
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
vs lbh pna ernq guvf, lbh'er n trrx.
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-04-12 21:51 +0200 |
| Subject | nftables für IPv6 (was: Re: IPv6Präfixe weiterverteilen) |
| Message-ID | <s528bc$7v8t$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #116483 |
Mahlzeit!
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>>1.4.6 Firewall auf dem Server
>>-----------------------------
>>
>> Ist ein eigenes Kapitel :-) Gleichlautende Regeln für IPv4/IPv6 lassen
>> sich ganz wunderbar über `nftables' erledigen, die Config ist viel
>> einfacher und übersichtlicher als mit `iptables'.
>
> Das würde mich auch etwas detaillierter interessieren, ich hänge da
> immer noch bei iptables über ferm fest (ein cooles Tool, leider auch
> nur noch so barely alive).
Ich hatte anderthalb Jahrzehnte lang ein wildes Shellskript mit >1000
Zeilen, das anhand einer Konfigurationsdatei iptables-Regeln erzeugt
hat (anfangs sogar noch ipchains). Das war zeitweise sogar auf
drei(!) verschiedenen Rechnern im Einsatz. Totaler Overkill und wild
gewachsen.
IPv6 habe ich mich nie getraut, weil ich dann dieses Monster hätte
komplett umschreiben müssen.
Mit nftables ist die Firewall bei gleicher Funktionalität viel
übersichtlicher als das Skript geworden. Außerdem kann ich die Regeln
direkt in nftables-Syntax konfigurieren, statt ein Skript zu
benötigen, dass mir die Konfiguration generiert. Die Regeln sind
dadurch atomar austauschbar und wenn irgendwo ein Syntaxfehler ist,
passiert einfach gar nichts, statt dass wie früher die alten Regeln
schon gelöscht sind, die neuen aber nie auftauchen. Und
/etc/nftables.conf ist direkt executable, das ist nett ;-)
Inhaltlich ist das total Consumer-Grade, das macht ungefähr das
gleiche wie die Fritz!Box-Firewall:
- von drinnen darf alles raus (eth0->dmz0)
- Antworten darauf dürfen von draußen wieder rein (dmz0->eth0)
- für IPv4 macht es NAT für das interne Netz (eth0)
- von außen sind bestimmte Ports zugänglich (dmz0->eth0)
(einige der Ports sind in der Fritz!Box freigeschaltet und
weitergeleitet und damit „richtig“ von außen erreichbar;
die anderen Port sind nur aus der DMZ erreichbar, z.B. aus dem
WLAN im Wohnzimmer)
Also eigentlich eher simpel.
Die VPN-Endpunkte, die ich hier habe, laufen unter „internes Netz“ und
haben keine eigenen Firewall-Regeln (bis auf das Öffnen der Wireguard-
bzw. OpenVPN-Ports), das reicht für mich aus. (In meinem alten Skript
musste ich noch jedes VPN-Device einzeln konfigurieren.) Da das
interne Netz sehr leer geworden ist, dient die Firewall größtenteils
noch dazu, das WLAN von den VPNs zu trennen.
Bevor ich jetzt frage, ob Du daran Interesse hast, kipp ich es einfach
hier rein ;-)
Die ganze „table inet“ gilt gleichzeitig für IPv4 und IPv6, nur ganz
vereinzelt wird darin explizit nochmal nach der Version unterschieden.
+v
#!/usr/sbin/nft -f
flush ruleset
# TODO: sprinkle with "comment" and "counter"
define dmz_if = dmz0
# Auth SSH Portmap NFS mountd uucpS_____ minidlna syncthing OpenVPN
define accept_tcp_ports = { auth, 443, 111, 2049, 2050, 4012, 4013, 8200, 22000, 58005 }
# Portmap ssdp NFS mountd syncthing WireGuard
define accept_udp_ports = { 111, 1900, 2049, 2050, 21027, 58006 }
define icmp_v4_types_global_ok = { echo-request, destination-unreachable, time-exceeded, parameter-problem, source-quench }
define icmp_v6_types_global_ok = { echo-request, destination-unreachable, time-exceeded, parameter-problem, packet-too-big }
define icmp_v6_types_local_ok = { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert, nd-router-solicit, mld-listener-query }
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# accept related, drop invalid
jump connection_state
# drop loopback traffic not from loopback
iif != lo ip daddr 127.0.0.1/8 counter drop comment "dropped loopback v4"
iif != lo ip6 daddr ::1/128 counter drop comment "dropped loopback v6"
# carte blanche for everything not coming from the DMZ
iifname != $dmz_if accept
# allow icmp
jump accept_icmp
# open external ports
tcp dport $accept_tcp_ports accept
udp dport $accept_udp_ports accept
# allow DHCPv6
ip6 nexthdr udp udp dport dhcpv6-client udp sport dhcpv6-server accept
# Email direkt von der Fritzbox annehmen
tcp dport { smtp } ip saddr 192.168.YY.1 accept
# reject statt drop
jump reject_if_possible
}
chain forward {
type filter hook forward priority 0; policy drop;
# loopback should not be here
iifname lo counter drop comment "dropped loopback forward"
# accept related, drop invalid
jump connection_state
# carte blanche for everything not coming from the DMZ
iifname != $dmz_if accept
# allow icmp
jump accept_icmp
# reject statt drop
jump reject_if_possible
}
chain connection_state {
# drop invalid connections
ct state invalid counter drop comment "dropped invalid"
# established/related connections
ct state established,related counter accept
}
chain accept_icmp {
# allow global icmp
icmp type $icmp_v4_types_global_ok accept
ip6 nexthdr icmpv6 icmpv6 type $icmp_v6_types_global_ok accept
# IPv6 ICMP routing stuff / local icmp
ip6 nexthdr icmpv6 icmpv6 type $icmp_v6_types_local_ok ip6 hoplimit 1 accept
ip6 nexthdr icmpv6 icmpv6 type $icmp_v6_types_local_ok ip6 hoplimit 255 counter accept
}
chain reject_if_possible {
counter reject with tcp reset comment "reject/tcp"
counter reject with icmpx type port-unreachable comment "reject/icmp unreachable"
counter comment "reject/drop"
}
}
table ip nat {
chain prerouting {
type nat hook prerouting priority 0; policy accept;
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oifname $dmz_if masquerade
}
}
-v
Nagelt mich nicht auf die Details für IPv6 und ICMP fest, ich habe mir
das seinerzeit aus verschiedenen Anleitungen zusammengekramt, mich
soweit ich konnte aufgeschlaut und das ganze um „funktioniert auch
ohne diese Regel“ entschlackt. Das ist vermutlich einer
Revisionsabteilung nicht compliant genug, aber hier bei mir mache ich
die (Firewall-)Regeln ;-)
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Nicht die Schere! NICHT DIE SCH... NO CARRIER
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2021-04-12 21:32 -0400 |
| Subject | Re: nftables für IPv6 |
| Message-ID | <87tuobnf49.fsf@usenet.ankman.de> |
| In reply to | #116582 |
On Mon, 12 Apr 2021 21:51:08 +0200 (CEST), Christian Garbs wrote: > > Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > >>>1.4.6 Firewall auf dem Server >>>----------------------------- >>> >>> Ist ein eigenes Kapitel :-) Gleichlautende Regeln für IPv4/IPv6 lassen >>> sich ganz wunderbar über `nftables' erledigen, die Config ist viel >>> einfacher und übersichtlicher als mit `iptables'. >> >> Das würde mich auch etwas detaillierter interessieren, ich hänge da >> immer noch bei iptables über ferm fest (ein cooles Tool, leider auch >> nur noch so barely alive). > > Ich hatte anderthalb Jahrzehnte lang ein wildes Shellskript mit >1000 > Zeilen, das anhand einer Konfigurationsdatei iptables-Regeln erzeugt > hat (anfangs sogar noch ipchains). Das war zeitweise sogar auf > drei(!) verschiedenen Rechnern im Einsatz. Totaler Overkill und wild > gewachsen. > > IPv6 habe ich mich nie getraut, weil ich dann dieses Monster hätte > komplett umschreiben müssen. > > Mit nftables ist die Firewall bei gleicher Funktionalität viel > übersichtlicher als das Skript geworden. Der Fall scheint ähnlich zu ip VS ifconfig und iw VS iwconfig zu liegen. ip und iw sind lange verfügbar. Und vor einem Jahrzehnt las ich schon, dass ifconfig und iwconfig "bald" obsolet sein werden. Ist nicht wirklich (flächendeckend) passiert. So wie nftables seit 2014 verfügbar IMO auch abstrakter als iptables ist, wie es ip und iw schon sind. Man scheint aber an Bewährtem festhalten zu wollen, dass die alten Versionen nicht "stillgelegt" werden. Ich werde mal ipchains installieren. ;-) -- Andreas PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-04-13 21:01 +0200 |
| Subject | Re: nftables für IPv6 |
| Message-ID | <s54ppi$af1d$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #116586 |
Mahlzeit! Andreas Kohlbach <ank@spamfence.net> wrote: > Der Fall scheint ähnlich zu ip VS ifconfig und iw VS iwconfig zu > liegen. ip und iw sind lange verfügbar. Und vor einem Jahrzehnt las ich > schon, dass ifconfig und iwconfig "bald" obsolet sein werden. Ist nicht > wirklich (flächendeckend) passiert. Bezüglich des Toolings habe ich mich (toolunterstützt) umdressiert. Folgendes steht in meinem Shell-Setup: # finally start to use iproute2 over net-tools! alias arp='echo "use ip n (ip neighbour) instead"' alias ifconfig='echo "use ip a (ip addr), ip link, ip -s (ip-stats) instead"' alias netstat='echo "use ss, ip route (for netstat -r), ip -s link (for netstat -i), ip maddr (for netstat -g) instead"' alias route='echo "use ip r (ip route) instead"' ;-) Christian -- ....Christian.Garbs....................................https://www.cgarbs.de Montag ist Schontag (Kalle)
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2021-04-13 23:09 +0200 |
| Subject | Re: nftables für IPv6 |
| Message-ID | <esdhkh-r1g.ln1@news.martinen.de> |
| In reply to | #116622 |
Am 13.04.21 um 21:01 schrieb Christian Garbs: > Bezüglich des Toolings habe ich mich (toolunterstützt) umdressiert. Du hörst also auf das was du dir selbst zu sagen hast? Nobel. :) > Folgendes steht in meinem Shell-Setup: > > # finally start to use iproute2 over net-tools! > alias arp='echo "use ip n (ip neighbour) instead"' > alias ifconfig='echo "use ip a (ip addr), ip link, ip -s (ip-stats) instead"' > alias netstat='echo "use ss, ip route (for netstat -r), ip -s link (for netstat -i), ip maddr (for netstat -g) instead"' > alias route='echo "use ip r (ip route) instead"' > > ;-) Hmm. Das gefällt mir. Den klaue ich von dir und lege ihn mir mal in meine Sammlung der Dinge die ich noch erledigen will. Bisher gibts allerdings noch nettools-deprecated aber wenn die mal nicht mehr sein sollten... Kay -- Posted via leafnode
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-04-14 09:01 +0200 |
| Subject | Re: nftables für IPv6 |
| Message-ID | <s56417$teb7$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #116630 |
Mahlzeit! Kay Martinen <usenet@martinen.de> wrote: > Am 13.04.21 um 21:01 schrieb Christian Garbs: > >> Bezüglich des Toolings habe ich mich (toolunterstützt) umdressiert. > > Du hörst also auf das was du dir selbst zu sagen hast? Nobel. :) Es hat zumindest in dem Fall funktioniert, ip(8) ist jetzt im muscle memory :-) Ich bin jetzt gemein und weise darauf hin, dass sich die Aliase natürlich jederzeit unter Angabe des vollen Pfades umgehen lassen.¹ *undführemichnichtinVersuchung* Gruß Christian ¹) Und über \ifconfig oder ähnliches, aber das ist bei mir nicht im muscle memory. -- ....Christian.Garbs....................................https://www.cgarbs.de "Good health" is merely the slowest rate at which one can die.
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2021-04-14 20:12 +0200 |
| Subject | Re: nftables für IPv6 |
| Message-ID | <4tnjkh-90e.ln1@news.martinen.de> |
| In reply to | #116641 |
Am 14.04.21 um 09:01 schrieb Christian Garbs: > Mahlzeit! > > Kay Martinen <usenet@martinen.de> wrote: >> Am 13.04.21 um 21:01 schrieb Christian Garbs: >> >>> Bezüglich des Toolings habe ich mich (toolunterstützt) umdressiert. >> >> Du hörst also auf das was du dir selbst zu sagen hast? Nobel. :) > > Es hat zumindest in dem Fall funktioniert, ip(8) ist jetzt im muscle > memory :-) <gemeine_frage> Funktioniert denn damit auch RPC? (Remote Person Control) > Ich bin jetzt gemein und weise darauf hin, dass sich die Aliase natürlich > jederzeit unter Angabe des vollen Pfades umgehen lassen.¹ Sonst wär's ja kein shell-Alias. > *undführemichnichtinVersuchung* Ja, doch, bitte! Sündigen macht viel mehr Spaß wenn man damit Religioten ärgern kann. ;-) > ¹) Und über \ifconfig oder ähnliches, aber das ist bei mir nicht im > muscle memory. Putzig. Das funktioniert tatsächlich. Irgendwas war da mit dem '\' aber ich hab's vergessen. Zeichencapturing? Kay -- Posted via leafnode
[toc] | [prev] | [next] | [standalone]
| From | Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) |
|---|---|
| Date | 2021-04-13 19:21 +0000 |
| Subject | Re: nftables für IPv6 |
| Message-ID | <1t6075ebbfi6486n3e8%sfroehli@Froehlich.Priv.at> |
| In reply to | #116582 |
On Mon, 12 Apr 2021 21:51:08 Christian Garbs wrote:
> # Auth SSH Portmap NFS mountd uucpS_____ minidlna syncthing OpenVPN
> define accept_tcp_ports = { auth, 443, 111, 2049, 2050, 4012, 4013, 8200, 22000, 58005 }
Eines der wenigen Dinge, die ich an nftables bisher nicht mag, ist
die Idee, Portbezeichnungen nicht aus /etc/services einzulesen,
sondern ein recht willkürliches Subset davon fix zu codieren.
Und ein weiteres ist die "etwas" unübersichtliche Syntax durch
Fehlen jeglicher Trennung der einzelnen Statements in einer Rule.
Es geht noch deutlich komplexer, aber selbst in Deinem einfachren
Regelwerk hätte ich bei:
> ip6 nexthdr icmpv6 icmpv6 type $icmp_v6_types_local_ok ip6 hoplimit 255 counter accept
...schon Mühe, das ohne im benachbarten Fenster aufgeschlagenen
Handbuch noch korrekt in seine Bestandteile zu trennen.
Aber ok, wenn man sich mit dem Regelwerk auseinandersetzt (und nicht
nur mit einzelnen Port- oder Adresslisten), dann ohnehin meistens
intensiver...
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Stefan - Für die Tage der Wehmut: Werkeln weil es tüftelt!
(Sloganizer)
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-04-16 20:32 +0200 |
| Subject | Re: IPv6Präfixe weiterverteilen |
| Message-ID | <s5cl8e$h2oa$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #116483 |
Mahlzeit!
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Christian Garbs <mitch@cgarbs.de> wrote:
> Können wir uns auf "Transfernetz" statt "DMZ" einigen? Das ist aber
> eine Stilfrage.
Jain, bei mir ist es tatsächlich mal so und mal so:
1. Fritz!Box <-> LAN-Kabel <-> Server
2. Fritz!Box <-> low-security-Hausnetz mit WLAN <-> Server
Wobei bei 2. DMZ wohl vielleicht nicht ganz richtig ist, immerhin ist
der einzige absichtlich aus dem Internet erreichbare Rechner in beiden
Fällen der Server. Potenziell (bei Angriffen/Fehlkonfigurationen)
steht bei 2. allerdings auch mein Fernseher im Internet.
Was wäre denn ein schmissiger Begriff für "mehr als ein Transfernetz,
aber halt nicht das interne Netz"?
Sollte ich - ausgehend vom Server - vielleicht ganz abstrakt
"Downstream" und "Upstream" verwenden?
> Zieht die Fritzbox nach einem Prefixwechsel bzw. beim Nichtbestehen
> einer Netzverbindung das zugewiesene Präfix zuverlässig, sofort und
> korrekt zurück, oder sind Dir da irgendwelche Ungereimtheiten
> aufgefallen?
Da ist mir bisher nichts aufgefallen. Wenn ich mit "ip -6 a" gucke,
ist immer eine externe Adresse zu sehen. Falls die mal fehlt, würde
mir das auch nicht unbedingt auffallen, weil ja immer noch IPv4
vorhanden ist (vermutlich verzögert sich da nur der erste Connect
irgendwohin).
> Kommt es vor, dass beim Prefixwechsel seitens des
> Providers zwischendurch ULA-Adressen verteilt und direkt wieder
> zurückgezogen werden?
Ich habe ehrlich gesagt noch nie beim IP-Wechsel zugeguckt, das
passiert immer nachts. Müsste ich vielleicht mal per Skript capturen.
> Oder lässt die Fritzbox das Announcement für die
> ULA-Adressen einfach die ganze Zeit "draußen"?
Die von der Fritz!Box ausgewiesen ULA ist momentan nicht zu sehen.
Das passt zu der Einstellung in der Oberfläche:
| Unique Local Addresses
|
| Wählen Sie aus, wie den Geräten im Heimnetz die Unique Local
| Addresses (ULA) zugewiesen werden sollen.
|
| (X) Unique Local Addresses (ULA) zuweisen, solange keine
| IPv6-Internetverbindung besteht (empfohlen)
| ( ) Keine Unique Local Addresses (ULA) zuweisen (nicht empfohlen)
| ( ) Unique Local Addresses (ULA) immer zuweisen
Darunter könnte ich mir auch eine ULA aussuchen, aktuell hat sich die
Fritz!Box da wohl selbst was ausgedacht.
>> [Präfix anfordern]
> Ok, das wird also der Bereich, wo mir mein systemd-networkd weh tun
> wird. Eventuell doch erst mal den Router nach Bullseye updaten, der
> systemd dort ist halt doch erheblichst frischer.
Ich bin ja mit Stable soweit zufrieden, dass ich auf nichts neues
warte - das nächste Release passiert halt irgendwann. Aber so langsam
hätte ich gerne ein neueres systemd-networkd, dann kann ich hier
einige Pakete (wide-dhcpv6-client, radvd, normales ISC DHCP?)
deinstallieren :-)
Ich vermute mal, sowas wie "pre-up" und "pre-down" unterstüzt systemd
da dann auch? Konkret starte und stoppe ich meine WireGuard-Devices,
wenn dmz0 hochkommt oder runtergeht.
>>1.4.3 Netzwerk-Konfiguration
>>----------------------------
>>
>> In der `/etc/sysctl.conf' habe ich unter anderem folgendes stehen.
>> Sieht wichtig aus:
>>
>> ,----
>> | # EXPERIMENTAL
>> | # ipv6 privacy extension ONLY on external device
>> | # https://wiki.ubuntuusers.de/IPv6/Privacy_Extensions/
>> | net.ipv6.conf.dmz0.use_tempaddr = 2
>> | net.ipv6.conf.dmz0.temp_prefered_lft = 14400
>
> Auf dem Router halte ich das für unnötig, es sei denn, Du hast auch
> Benutzer dort.
Ja, da wird gearbeitet.
Der eine Server ist mein aktueller Desktop ;-)
> Der Transport von Nutztraffic läuft nach meiner Erwartung sowieso
> über die Link-Local-Adressen; ich wäre überrascht wenn das bei
> Prefix Delegation anders wäre.
Damit meinst Du aber nur den internen Traffic, oder? Sonst müsste die
Fritz!Box ja wieder sowas ähnliches wie NAT machen, wenn es nach
draußen geht.
Wenn ich von einem internen Client per SSH über IPv6 auf meinen
Rootserver im Internet gehe, dann ist die dort sichtbare
Absender-Adresse die, die der Client aus dem delegierten Präfix
bekommen hat.
> Möchtest Du Systeme im Hausnetz über IPv6 aus dem Internet adressieren
> können, d.h. hat die Fritzbox eine Route für die delegierten Prefixe
> angelegt?
Ja, ich möchte jeweils von draußen per SSH auf den Server zugreifen
können. Das klappt auch mit IPv6.
Ich hab mir dafür ein eigenes Dyndns gebaut¹ und mache TOTP für den
SSH-Login (was ich auch seit Jahren mal bloggen wollte…).
> Ich persönlich finde radvd nicht so toll, das ist voller Fallstricke -
> und das, obwohl es im September 2020 das letzte Release gab. So ganz
> tot ist der Upstream also nicht, aber ein Release alle drei Jahre
> finde ich nicht toll.
Zu der Erkenntnis komme ich auch langsam: Der verteilt zwar den
delegierten Präfix einmalig weiter, aber falls der Präfix sich ändert,
wechselt er nicht auf den neuen. Da muss ich noch forschen.
Gibt es denn Alternativen zu radvd, abgesehen von aktuellem systemd?
> RDNSS ist leider nicht besonders gut und breit unterstützt, es gibt
> haufenweise Systeme die das nicht können.
Ganz ehrlich: Ich habe das wohl damals mit in die Config geschrieben,
aber ob die Clients das benutzen: keine Ahnung. Der DNS-Servier ist
gesetzt, aber das kann auch alles aus dem IPv4-DHCP getrudelt sein,
dort sind die Einstellungen ja die gleichen.
Gut, IPv4 vs. IPv6 beim Nameserver fällt auf :-)
> Im Zweifel nehmen die Clients eh den IPv4-DNS-Server :-(
Nachgeguckt: Jepp, das macht der Ubuntu-Client genau so. (und
oh: da läuft systemd-resolve, das hab ich mir noch nie so genau
angeguckt)
>> Wenn ich nichts vergessen habe, ist das alles.
>
> DANKE!
Gerne! Ich wollte das Thema schon länger mal fürs Blog aufschreiben,
aber da fehlt immer die Motivation. Hierzugroup war das Thema ein
willkommener Hook, das endlich mal auf die Reihe zu kriegen und jetzt
kriege ich sogar noch zusätzlichen Input zu dem Thema.
Gruß
Christian
PS: Deine hier nicht zitierten Anmerkungen versuche ich auch noch
irgendwie mit einzuarbeiten.
¹) https://github.com/mmitch/dns-update
--
....Christian.Garbs....................................https://www.cgarbs.de
Sattinger's Law:
It works better if you plug it in.
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2021-04-16 21:14 +0200 |
| Subject | Re: IPv6Präfixe weiterverteilen |
| Message-ID | <r94pkh-7c5.ln1@news.martinen.de> |
| In reply to | #116696 |
Am 16.04.21 um 20:32 schrieb Christian Garbs: > > Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> Christian Garbs <mitch@cgarbs.de> wrote: > >> Können wir uns auf "Transfernetz" statt "DMZ" einigen? Das ist aber >> eine Stilfrage. > > Jain, bei mir ist es tatsächlich mal so und mal so: > > 1. Fritz!Box <-> LAN-Kabel <-> Server > 2. Fritz!Box <-> low-security-Hausnetz mit WLAN <-> Server > > Wobei bei 2. DMZ wohl vielleicht nicht ganz richtig ist, immerhin ist > der einzige absichtlich aus dem Internet erreichbare Rechner in beiden > Fällen der Server. Potenziell (bei Angriffen/Fehlkonfigurationen) > steht bei 2. allerdings auch mein Fernseher im Internet. Mir sind nur zwei formen von DMZ bekannt. Die "einbeinige" Variante die mittels extra Interface direkt vom (WAN)Router abzweigt und die "zweibeinige" die zwischen Externem und Internem Router liegt. Die zugleich aber auch ein "transfernetz" ist. Was du da oben beschreibst klingt irgendwie weder nach dem einen noch dem anderen. > Was wäre denn ein schmissiger Begriff für "mehr als ein Transfernetz, > aber halt nicht das interne Netz"? Exposed Host! :-) Ernsthaft. Will man nicht im Internen Netz haben, ist keine DMZ aber (Einzahl) auch kein Transfernetz. > Sollte ich - ausgehend vom Server - vielleicht ganz abstrakt > "Downstream" und "Upstream" verwenden? Das beschreibt doch nur Richtungen eines Datenstroms relativ zum Betrachter. Ungeeignet! Kay -- Posted via leafnode
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-17 09:53 +0200 |
| Subject | Re: IPv6Präfixe weiterverteilen |
| Message-ID | <s5e451$q5c$1@news1.tnib.de> |
| In reply to | #116696 |
Christian Garbs <mitch@cgarbs.de> wrote: >Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> Christian Garbs <mitch@cgarbs.de> wrote: > >> Können wir uns auf "Transfernetz" statt "DMZ" einigen? Das ist aber >> eine Stilfrage. > >Jain, bei mir ist es tatsächlich mal so und mal so: > > 1. Fritz!Box <-> LAN-Kabel <-> Server > 2. Fritz!Box <-> low-security-Hausnetz mit WLAN <-> Server > >Wobei bei 2. DMZ wohl vielleicht nicht ganz richtig ist, immerhin ist >der einzige absichtlich aus dem Internet erreichbare Rechner in beiden >Fällen der Server. Potenziell (bei Angriffen/Fehlkonfigurationen) >steht bei 2. allerdings auch mein Fernseher im Internet. > >Was wäre denn ein schmissiger Begriff für "mehr als ein Transfernetz, >aber halt nicht das interne Netz"? Da kenne ich Perimeternetz, Servicenetz, halböffentliches Netz... Eine DMZ im klassischen Sinne kommt heute fast nicht mehr vor, das hat man früher so genannt, wenn man in das Transfernetz zwischen Provider und eigener Firewall noch Dinge hingehängt hat, oder bei Transfernetzen zwischen zwei kooperierenden Firmen, in denen man zusätzlch noch die Systeme angesiedelt hat, die den Datentransfer bewerkstelligen. Ganz klassisch waren das ftp-Server, auf denen beide Seiten Rechte hatten und die Firewalls, die das Firmennetz abschotten nur Zugriff auf diese Systeme erlaubt haben. >Sollte ich - ausgehend vom Server - vielleicht ganz abstrakt >"Downstream" und "Upstream" verwenden? Ich unterscheide zwischen untrusted, internal und perimeter. >> Zieht die Fritzbox nach einem Prefixwechsel bzw. beim Nichtbestehen >> einer Netzverbindung das zugewiesene Präfix zuverlässig, sofort und >> korrekt zurück, oder sind Dir da irgendwelche Ungereimtheiten >> aufgefallen? > >Da ist mir bisher nichts aufgefallen. Wenn ich mit "ip -6 a" gucke, >ist immer eine externe Adresse zu sehen. Falls die mal fehlt, würde >mir das auch nicht unbedingt auffallen, weil ja immer noch IPv4 >vorhanden ist (vermutlich verzögert sich da nur der erste Connect >irgendwohin). Bei mir hat der IPv6-Prefix bisher noch nicht gewechselt. Das ist also auch bei meinem Provider 1&1 anders gehandhabt als bei IPv4 mit der 24h-Zwangstrennung, nach der auch immer eine neue IPv4-Adresse kommt. Ich werde da mal ein Monitoring aufsetzen. >Die von der Fritz!Box ausgewiesen ULA ist momentan nicht zu sehen. >Das passt zu der Einstellung in der Oberfläche: > >| Unique Local Addresses >| >| Wählen Sie aus, wie den Geräten im Heimnetz die Unique Local >| Addresses (ULA) zugewiesen werden sollen. >| >| (X) Unique Local Addresses (ULA) zuweisen, solange keine >| IPv6-Internetverbindung besteht (empfohlen) >| ( ) Keine Unique Local Addresses (ULA) zuweisen (nicht empfohlen) >| ( ) Unique Local Addresses (ULA) immer zuweisen > >Darunter könnte ich mir auch eine ULA aussuchen, aktuell hat sich die >Fritz!Box da wohl selbst was ausgedacht. Nach meinem Bauchgefühl sollte man in einem Netz mit wechselndem Prefix für die interne Kommunikation immer noch zusätzlch einen statischen Prefix verteilen. Das wäre dann also die dritte Option. Für mein Netz ergibt das aber keinen Sinn, weil ich den statischen Prefix aus dem zentralen Router verteilen könnte und die Fritzbox nicht zentral steht. >> Ok, das wird also der Bereich, wo mir mein systemd-networkd weh tun >> wird. Eventuell doch erst mal den Router nach Bullseye updaten, der >> systemd dort ist halt doch erheblichst frischer. > >Ich bin ja mit Stable soweit zufrieden, dass ich auf nichts neues >warte - das nächste Release passiert halt irgendwann. Aber so langsam >hätte ich gerne ein neueres systemd-networkd, dann kann ich hier >einige Pakete (wide-dhcpv6-client, radvd, normales ISC DHCP?) >deinstallieren :-) Ich habe gerade einen Backport von systemd aus bullseye gebaut, der wird aber nur bis zum Release leben und dann wird das eine frühe Maschine für ein Update. >Ich vermute mal, sowas wie "pre-up" und "pre-down" unterstüzt systemd >da dann auch? Konkret starte und stoppe ich meine WireGuard-Devices, >wenn dmz0 hochkommt oder runtergeht. Das müsstest Du vermutlich mit einer eigenen Unit am systemd-networkd verklöppeln. Die Eingriffsmöglichkeiten in die internen Prozesse beiben bei Programmen aus dem systemd-Ökosystem grundsätzlich weit hinter dem zurück, was wir aus dem klassischen Unix gewöhnt sind. Aber irgendwas ist ja immer. >> Der Transport von Nutztraffic läuft nach meiner Erwartung sowieso >> über die Link-Local-Adressen; ich wäre überrascht wenn das bei >> Prefix Delegation anders wäre. > >Damit meinst Du aber nur den internen Traffic, oder? Ich meine, das Du üblicherweise link local adressen als Gateway-Adressen für Routen verwendest. Eine oft gesehene, aber nirgendwo hingeschriebene Konvention ist, dass fe80::1 das Gateway in Richtung Internet ist. >> Möchtest Du Systeme im Hausnetz über IPv6 aus dem Internet adressieren >> können, d.h. hat die Fritzbox eine Route für die delegierten Prefixe >> angelegt? > >Ja, ich möchte jeweils von draußen per SSH auf den Server zugreifen >können. Das klappt auch mit IPv6. Man muss aber eine "Portfreigabe" anlegen. So weit bin ich in einem Testsetup inzwischen auch ;-) >Gibt es denn Alternativen zu radvd, abgesehen von aktuellem systemd? Nicht dass ich wüsste. Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Marcus Jodorf <trap@killfile.de> |
|---|---|
| Date | 2021-03-26 13:20 +0100 |
| Message-ID | <87h7kynm2j.fsf-bofh@killfile.de> |
| In reply to | #115988 |
Christian Garbs <mitch@cgarbs.de> schrieb: > Dass systemd mal beim Booten[1] oder Runterfahren hakt und hängt, habe > ich auch schon erlebt, aber das klingt jetzt so wie "im laufenden > Betrieb abgestürzt". Wie hat systemd denn da die Finger drin? Ist nur eine sujektive Beobachtung. Zum Beispiel hängende Dienste scheint es einfach viel öfter zu geben als früher. Ich kann mich beim besten Willen nicht erinnern, daß ich früher öfter mal irgendwas neu starten mußte, weil es sich verklemmt hat und auf nichts mehr reagiert, weil z.B. irgendwelche sockets scheinbar spontan nicht mehr tun. Und die Hänger bei rauf oder runterfahren sind echt ein Graus - man sollte eigentlich meinen, daß ein initsystem vielleicht gerade das einigermaßen hinbekommen sollte. > Und seit ich in meiner /etc/network/interfaces alle Netzwerkkarten auf > allow-hotplug umgestellt habe, wartet systemd nicht mehr bei jedem > Boot eine Minute in der Gegend rum. Das waren bei mir 5 min timeouts. Plus beim Start nach Ablauf des Timeouts war praktisch nichts wegen angeblich fehlendem Netz gestartet. Netz war zwar in Wirklichkeit da, aber dann halt keine Programme. Den Mist haben sie auch irgendwann plötzlich eingebaut. Die Rechner liefen alle schon vorher jahrelang problemlos ohne allow-hotplug (im Einklang mit der Doku, die die Entwickler da offenbar nicht lesen). > Mit systemd-networking wäre das vielleicht nicht passiert, aber ich > verteile die dynamischen IPv6-Präfixe von der FritzBox intern weiter, > das geht glaube ich mit systemd-networking nicht. Auch da bin ich > seit "allow-hotplug" glücklich. Nicht wirklich. Weil das mit dem hotplug dauert vergleichsweise lange. Damit braucht network-online.target bei mir überall praktisch doppelt so lange, um erreicht zu werden, als zuvor. Und es ist natürlich an sich ärgerlich, wenn plötzlich etwas überall ohne Vorwarnung broken ist, was vorher jahrelang einfach funktioniert hat. Gruß, Marcus ⚂⚃
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-03-27 09:27 +0100 |
| Message-ID | <s3mq8v$8un$1@news1.tnib.de> |
| In reply to | #115988 |
Christian Garbs <mitch@cgarbs.de> wrote: >Und seit ich in meiner /etc/network/interfaces alle Netzwerkkarten auf >allow-hotplug umgestellt habe, wartet systemd nicht mehr bei jedem >Boot eine Minute in der Gegend rum. Mit systemd-networking wäre das >vielleicht nicht passiert, aber ich verteile die dynamischen IPv6-Präfixe >von der FritzBox intern weiter, das geht glaube ich mit >systemd-networking nicht. Neuerer systemd-networkd kann Prefix Delegation. Mich würde intressieren, wie Du das "klassisch" machst, da systemd-networkd bestimmt noch ein paar Debian-Releases braucht bis das brauchbar funktioniert (ich extrapoliere hier von den Erfahrungen mit dem 'normalen' IPv6-Support in systemd-networkd, der anfänglich an etlichen Stellen wirklich grotesk kaputt war). Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-04-03 09:16 +0200 |
| Message-ID | <s494od$9eih$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #116002 |
Mahlzeit! Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Christian Garbs <mitch@cgarbs.de> wrote: >> Mit systemd-networking wäre das vielleicht nicht passiert, aber ich >> verteile die dynamischen IPv6-Präfixe von der FritzBox intern >> weiter, das geht glaube ich mit systemd-networking nicht. > Neuerer systemd-networkd kann Prefix Delegation. Mich würde > intressieren, wie Du das "klassisch" machst, Siehe "weiter oben" <s47qek$j401$1@yggdrasil.dn.cgarbs.de> :-) Letztendlich ist wohl radvd das nötige Extra-Zahnrad. Gruß Christian -- ....Christian.Garbs....................................https://www.cgarbs.de Q: Why do firemen wear red suspenders? A: To conform with departmental regulations concerning uniform dress.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-02 20:53 +0200 |
| Message-ID | <s47p6p$ch9$1@news1.tnib.de> |
| In reply to | #115982 |
Marcus Jodorf <trap@killfile.de> wrote: >Ich weiß nicht, ob man da groß philosophieren muß -- aber was mir >aufgefallen ist, ist daß ungefähr parallel zum Aufkommen von systemd >es begonnen hat, daß plötzlich Windowsserver stabiler laufen als so >manches Linux (reboots wegen Updates außen vor). Das ist IMO hauptsächlich Windows' Verdienst, das muss man Microsoft einfach zugestehen. Ich kann bei meinen Linuxen keine Neigung zur Instabilität entdecken. >Das mag daran liegen, daß MS dafür ja auch ein paar Jahrzehnte Anlauf >gebraucht und es vielleicht dann endlich mal geschafft hat... So sehe ich das, ja. >Aber letztlich finde ich das schon etwas traurig. Jedenfalls war systemd >zumindest keinerlei Zugewinn an Stabilität und ich hab auch einfach mehr >weggeknallte Systeme in den letzten Jahren erlebt als im Jahrzehnt >davor. Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis, hauptsächlich weil systemd-units einfacher zu debuggen sind als Initscripts und mit systemd etliche hanebüchene Heuristiken oder archaische Mechanismen wie pidfiles nicht mehr notwendig sind. Und es ist massivst einfacher geworden, Features wie Capabilities und Namespaces zu benutzen (das hat vor systemd nicht ohne Grund kaum jemand gemacht). >Das mag empirisch keine Bedeutung haben, aber mir persönlich fällt es >schon auf. Ich hab mich tatsächlich schon mal dabei erwischt, zu >überlegen, ob es nicht sinnvoller wäre, eine kritische Sache auf einen >aktuellen Windows- statt einen Linuxserver zu packen. Das ist inzwischen im Wesentlichen eine Stilfrage. Unter Windows kann man halt immer noch erheblich schlechter debuggen als in einem systemd-Linux. Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2021-04-02 23:30 +0000 |
| Message-ID | <s489ek$s7a$4@news2.informatik.uni-stuttgart.de> |
| In reply to | #116192 |
Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis, Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da aufhaengt. TOLLER Fortschritt ist das. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web