[Eisfair] dehydrated: Problem mit iptables (BFB?)

[Rolf Bensch]

Hallo Olaf,

Am 17.10.2017 um 22:31 schrieb Olaf Jaehrling:
> ...
> Der Grund kann sein, dass letsencrypt.org mittlerweile
> Domainloadbalancer einsetzen könnte (kann ich im Moment nicht
> verifizieren). Das bedeutet, dass beim Setzen der Regel eine anderer IP
> aufgerufen wird als beim löschen.
> 
> Das kann man das Problem anders lösen.
> Du initialisierst ja irgendwo iptables (firewallscript?)
> In diesem kannst Du eine neue CHAIN definieren.
> das würde dann so gehen
> iptables -N LETSCHAIN
> iptables -I INPUT - j LETSCHAIN
> DEHYDRATED_HOOK_CMD_1_EXEC='/sbin/iptables -I LETSCHAIN -s
> LETSENCRYPT-HP -j ACCEPT'
> DEHYDRATED_HOOK_CMD_10_EXEC='/sbin/iptables -F LETSCHAIN'
> 
> 
> Was bedeutet das.
> 1. Es wird eine Chain namens LETSCHAIN angelegt
> 2. die INPUT-Chain anweisen, dass sie in die LETSCHAIN gucken soll
> 3. Wenn PAKETE ankommen (INPUT) wird in der LETSCHAIN geschaut, ob die
> sourceadresse drin steht. Wenn ja, dann "ja"
> 4. das CMD_10 leert die CHAIN,so das kein Ja-Rückgabewert kommen kann,
> also das Paket abgewiesen wird und in der INPUT-Chain zur nächsten Regel
> gegangen wird.
> 
> 
> P.S. habe jetzt doch mal den Loadbalancer verifizieren können
> 1. 104.125.64.117
> 2. 23.211.172.190
> 3. 23.54.84.44
> 
> Schau mal so alle 10-15 Minuten
> dig letsencrypt.org
> 
> Da kannst Du das nachvollziehen.

Hmmm, wenn ich das richtig interpretiere, genügt die Verwendung des 
DNS-Namen nicht mehr:

# /sbin/iptables -D INPUT -s letsencrypt.org -j ACCEPT

fügt dann nur eine IP-Adresse ein. Ist das soweit korrekt verstanden? 
Wie erhält mit Deinem Vorschlag LETSCHAIN die passenden IP-Adressen?

Ich dachte eigentlich die Ursache gefunden zu haben. Zumindest erhielt 
ich nach Aktivierung von DEHYDRATED_HOOK_CMD_1 direkt ein neues 
Zertifikat. Sollte ich jetzt wirklich direkt anfangen zu basteln oder 
lieber die nächste Aktualisierung abwarten?

Grüße Rolf