Freetz-ng: Empfehlung für Reverse Proxy?

[John Paden]

Hallo zusammen,

ich nutze Freetz - aktuell freetz-ng schon seit Jahren, u.a. um mit dnsmasq deutliche mehr Optionen bezüglich DNS und dhcp zu haben.

Nun habe ich die folgende Situation: Hinter der (unveränderten) Kabel Fritzbox des Providers steht meine Fritzbox, die die Port 80/443 Zugriffe per Weiterleitung empfängt. Unterdessen gibt es eine ganze Anzahl von urls, die hier auflaufen. Bisher reicht die 2. Fritzbox diese brav an den pi#1 weiter, auf dem Apache läuft und die URLs auf die einzelnen virtual Hosts verteilt bzw via reverse proxy dann auf den pi#2 oder pi#3.
Nun stellt sich der pi#1 auf die Dauer als 'single point of failure' Stressfaktur heraus.

Daher die Idee, schon auf die Fritzbox einen reverse proxy zu freetzen, welcher dann die Zugriffe abhängig von den URLs auf pi#1, pi#2 und pi#3 verteilt, oder zB. einen Failover kennt - wenn pi#1 nicht da, automatsich den Zugriff von www.domain.com auf die 'Fehler_index.html' umleiten der auf pi#2 liegt etc. Luxus wäre, wenn auf der Fritzbox selber auch ein einfacher http Server laufen würde.

- lighthttpd kann http und proxy, aber kein SSL weiterleiten (richtig?)
- Apache 2.4.irgendwas habe ich testweise mal im Freetz buildprozess dazugefügt. Make läuft durch, die Fritzbox bootet auch, aber ich finde aber nix auf der GUI?
- welche anderen tools gibts, was nutzt Ihr so?

Danke für jeden Erfahrungsbericht oder Tip und Grüße!

 

[John Paden]

Update - ich stelle fest, ich habe zu lange nicht mehr genug mit freetz gemacht.
Fritzbox 3490, aktuelles freetz-ng 3490_07.30.all_freetz-ng-20074M-9a9109c1c
Versuch, Apache hinzuzufügen:
- Infos u.a. aus https://github.com/Freetz-NG/freetz-ng/blob/master/docs/make/apache2.md und

Apache Web-Server |

Modifikationen der Fritz!Box - Eine weitere WordPress-Seite

fritzmod.net

- Telnet im make menuconfig hinzukonfiguriert
- dropbaer (as is) hinzukonfiguriert
- Other Patches: drop nonexec for external storage (für den Fall, apache auszulagern)

Aktuell hakt alles daran, daß weder telnet noch ssh/dropbaer root Zugang erlauben.
- root / PW freetz geht nicht. Sollte es?
- z.B. boxusr99int oder andere user aus /etcpasswd funktionieren mit dem Fritzbox PW, sind aber nicht root.
Was habe ich übersehen?

 

[Joe_57]

Kannst du nicht nach dem erfolgreichen Login z.B. miitels "sudo" weitermachen?

 

[John Paden]

Hi, leider nein, die Fritzbox sagt "sudo not found".
Kann man sudo hineinkompilieren?

 

[PeterPawn]

Erst mal ein "Werksreset" für die AVM-Einstellungen (ein Benutzer boxusr99[int] ist eben auch ein Zeichen für ein schon sehr, sehr altes Relikt aus Zeiten, wo die AVM-Benutzerverwaltung noch vieles komplett anders machte - heutzutage beginnen die Mappings mit AVM-UID 10) und dann vermutlich auch noch eines für die Freetz-Einstellungen (die sind von den AVM-Einstellungen unabhängig) - das klingt doch alles sehr nach der Übernahme alter und längst nicht mehr aktueller Einstellungen aus älteren Freetz(-NG)-Installationen.

Ansonsten gibt es hier mehrfache Erklärungen, wie die AVM-Benutzerverwaltung funktioniert und was da von wo nach wo gemappt wird (Stichworte "boxusers" und ggf. noch "users.map", sowie "ar7login") - nach deren Lektüre sollten eigentlich keine weiteren Unklarheiten bestehen, welche Credentials für welche Anmeldung verwendet werden können (das bezieht sich auf die Versuche, da irgendwelche Accounts wie boxusr99int für eine Anmeldung zu benutzen).

Das Standard-Kennwort für den Benutzer root wird von Freetz(-NG) direkt als Kennwort (bzw. als Hash desselben) in der Datei /var/tmp/shadow gesetzt (https://github.com/Freetz-NG/freetz-ng/blob/9f685d358a9958356c199f5eaa175bed7e719b9d/fwmod#L1115), die es auch nur bei Freetz(-NG) gibt. AVM verwendet keine shadow-Datei und setzt auch in der /var/tmp/passwd - die als /etc/passwd verlinkt ist für Zugriffe der Standard-C-Library - KEIN Kennwort für den Benutzer root, so daß üblicherweise kein Login mit diesem Namen möglich ist ... aber schließlich werden am Ende beim AVM-Login (mittels ar7login) ohnehin ALLE Benutzer-Accounts auf root gemappt.

Die erwähnte /var/tmp/shadow wird - genauso wie die /var/tmp/passwd - bei JEDEM Systemstart erneut aus der Datei /var.tar an eine "beschreibbare" Stelle extrahiert und im Anschluß (im Freetz(-NG)-Kontext) durch diverse Umformungen (https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/usr/bin/modusers) auf den jeweils aktuellen Stand gebracht, wobei (nach dem Einbeziehen der von der AVM-Firmware automatisch generierten Accounts in /tmp/passwd: https://github.com/Freetz-NG/freetz...9b9d/make/mod/files/root/usr/bin/modusers#L12) zwischendrin die gesicherten Daten aus den Freetz-Einstellungen übernommen werden: https://github.com/Freetz-NG/freetz...9b9d/make/mod/files/root/usr/bin/modusers#L23 ... wenn da also am Ende nicht mehr das "initiale Kennwort" aus der /var.tar gesetzt sein sollte, dann KANN das fast nur noch an alten Freetz-(NG-)Settings liegen, die da irgendwann geladen werden in modusers.

Die Login-Versuche mit anderen Accounts sind also Kohl (solange es sich nicht doch um alte, gesicherte Freetz-(NG-)Einstellungen handelt) und solange nichts und niemand das "Standard-Kennwort" für Freetz(-NG) in der ausgepackten /var/tmp/shadow ändert, sollte ein Login mit diesen Daten auch funktionieren - vorausgesetzt das Programm, was sich um die Überprüfung von Benutzernamen und Kennwort kümmert (üblicherweise /bin/login, wobei das ggf. bei einigen Services durch Parameter oder Einstellungen geändert werden kann), bedient sich auch aus diesen Dateien. Das AVM-Programm ar7login macht das ausdrücklich NICHT, das verwendet die Daten aus dem Abschnitt boxusers in der Datei /var/flash/ar7.cfg.

Welches Login-Programm jetzt welcher Freetz-NG-Service verwendet, weiß ich nicht (das ist mir alles zu volatil, um das jedesmal erneut zu erkunden) - aber das kriegt man (bei Interesse) ja auch leicht selbst heraus. Spätestens in der Prozessliste in den Support-Daten sind irgendwo auch die Aufrufparameter der laufenden Services zu sehen und wenn das dort nicht direkt angegeben ist (wie z.B. hier:

vidar:/home/peh~ $ telnet fb7490
Trying 192.168.130.1...
Connected to fb7490.
Escape character is '^]'.
Fritz!Box user: <removed>
password:
ermittle die aktuelle TTY
tty is "/dev/pts/32"
disable start/stop characters and flowcontrol
# ps l | grep telnet
S     0  5549     1  1760   232 0:0   May25 00:00:12 telnetd -l /sbin/ar7login
S     0 16238 16225  1756   256 pts32 16:42 00:00:00 {exe} grep telnet
#

bei einem Telnet-Service, der auf einer 7490 mit aktueller Labor-Firmware durch den telefon-Daemon gestartet wurde), dann steht es wohl in irgendeiner Einstellungsdatei - bei einem "fresh Freetz(-NG)" sollte es ja keine alten "User-Daten" geben, die irgendetwas so setzen, daß man da nicht mehr herankommt.

 

[B612]

AVM verwendet keine shadow-Datei

Aber die gibt es in meiner 7580 und 7530 ohne Freetz:

root:*:12332:0:99999:7:::

Und ist auch in /var.tar vorhanden.

 

[PeterPawn]

Die mag ja als "statische Datei" existieren, aber die ganzen Accounts, die vom FRITZ!OS dynamisch generiert werden, die sollten ihre Kennwörter auch direkt in der /etc/passwd stehen haben ... DAS meinte ich damit, daß AVM für die Kennwörter KEINE shadow-Datei verwendet - das schließt nicht aus, daß diese Datei dennoch existiert.

EDIT: Wobei ich oben tatsächlich geschrieben habe, daß es diese Datei "nur bei Freetz(-NG) gibt" ... DAS ist dann tatsächlich falsch (meinerseits), wird aber vom zitierten Text in #6 nicht verdeutlicht.

 

[John Paden]

So, hat ein wenig gedauert. Danke für die Tips.
Andere (gebrauchte) 7580 Box besorgt.
Neues Freetz incl. dropbaer gebaut.
Wieder gelernt, wie man ein in-memory baut.
Mit den super *.sp1 Skipten neu gefreetzt.
Und tatsächlich - die root userid ist wieder root / freetz. *bäm* .-)

Nach

packages/apache – Freetz

freetz.github.io

weiter vorgegangen:

> Freetz Image ohne Apache und Php erstellen und auf die Box spielen - done
> Apache und ev. PHP als [statisch gelinkte] binaries auswählen und erneut make ausführen - done
> Die Binaries aus packages/apache-x.y.z und packages/php-x.y.z auf einen externen Stick packen (das php-cgi sollte in den cgi-bin Ordner des apache gelegt werden - done, aber die Verzeichnisse sind komplett anders: z.B. /var/media/ftp//USBStick-01/apache/usr/sbin/apache2

Und dann aber:
root@fritz:/var/mod/root# /var/media/ftp//USBStick-01/apache/usr/sbin/apache2
-sh: /var/media/ftp//USBStick-01/apache/usr/sbin/apache2: Permission denied

root@fritz:/var/mod/root# ls -l /var/media/ftp//USBStick-01/apache/usr/sbin/
-rwxrwxrwx 1 root root 5083176 Jan 1 01:34 apache2
-rwxrwxrwx 1 root root 3400 Jan 1 01:34 apachectl
-rwxrwxrwx 1 root root 117488 Jan 1 01:34 checkgid
-rwxrwxrwx 1 root root 1045 Jan 1 01:34 envvars
-rwxrwxrwx 1 root root 319956 Jan 1 01:34 fcgistarter
-rwxrwxrwx 1 root root 354868 Jan 1 01:34 htcacheclean
-rwxrwxrwx 1 root root 342348 Jan 1 01:34 rotatelogs
-rwxrwxrwx 1 root root 138112 Jan 1 01:34 suexec2

.. ich komme nicht drauf, wo ist der Fehler?

Hat überhaupt jemand so ne config schon mal zum laufen gehabt?

Auch diese Vorgehensweise

Installation |

Modifikationen der Fritz!Box - Eine weitere WordPress-Seite

fritzmod.net

scheitert am Permission denied

Die aktuellen user sind boxusr33 und boxusr33int.

 

[PeterPawn]

Vermutlich ist der Stick mit noexec-Option gemountet. Dafür bzw. dagegen gibt es auch einen Patch (aber nicht von Ratiopharm).

 

[John Paden]

... na klar. daran hats gelegen. Das kommt vom 'start from scratch'.

Mittlerweile

- FRITZ!Box 7580 Firmware: 153.07.29 rev92247 Freetz: ng-20103M-ecad2a667

- startet apache in script
mkdir /var/apache2
# ist nach dem reboot mmer weg
ln -s /var/media/ftp/Intenso-cMobileLine-01/apache2/logs /var/apache2/logs
# braucht apache
rm /var/media/ftp/Intenso-cMobileLine-01/apache2/logs/httpd.p*
# Leichen entsorgen, falls noch da
/var/media/ftp/Intenso-cMobileLine-01/apache2/usr/sbin/apache2 -f /var/media/ftp/Intenso-cMobileLine-01/apache2/etc/apache2/apache2.conf
# apache starten
ps | grep apache
# prüfen obs läuft

- in der
/var/media/ftp/Intenso-cMobileLine-01/apache/etc/apache2/apache2.conf
alle Pfade neu gesetzt und user geändert und eingefügt:
Listen 90


- intern und extern erreichbar mit
cp /var/flash/ar7.cfg /var/media/ftp/Intenso-cMobileLine-01/
nano /var/media/ftp/Intenso-cMobileLine-01/ar7.cfg

mcupstream = "internet";
voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
"tcp 0.0.0.0:5060 0.0.0.0:5060",
"udp 0.0.0.0:7078+20 0.0.0.0:7078";
voip_ip6_forwardrules = "udp 5060 # SIP", "tcp 5060 # SIP",
"udp 7078-7097 # RTP";
tr069_ip6_forwardrules = "tcp 8089";
internet_in_nat_rules_enabled = yes;
internet_out_nat_rules_enabled = yes;
internet_forwardrules = "tcp 0.0.0.0:10080 0.0.0.0:90",
"tcp 0.0.0.0:10443 0.0.0.0:453";

ctlmgr -s; voipd -s; cp /var/media/ftp/Intenso-cMobileLine-01/ar7.cfg /var/flash/ar7.cfg; reboot
(in einem durch)

- autostart von apache: im Freetz WebIF unter Freetz / rc.custom einfügen (dank an https://fritzmod.net/)

HDD='Intenso-cMobileLine-01'
HDD_ABSOLUT='/var/media/ftp/'$HDD

while ! [ -d $HDD_ABSOLUT ] ; do sleep 5; done

mkdir /var/apache2

ln -s $HDD_ABSOLUT/apache2/logs /var/apache2/logs
rm $HDD_ABSOLUT/apache2/logs/httpd.p*
$HDD_ABSOLUT/apache2/usr/sbin/apache2 -f $HDD_ABSOLUT/apache2/etc/apache2/apache2.conf
ps | grep apache

==> nun startet apache2 regelmäßig und ich kann mich an die Konfiguration des Proxy machen.

 

[PeterPawn]

Dennoch erlaube ich mir die Anmerkung, daß das alles ziemlich ungeschickt "zusammengeklittert" ist (zumindest in meinen Augen - warum das so ist, kommt weiter unten) - das fängt mit der "Notwendigkeit", da einen Pfad "fest" zu definieren, bereits an, zieht sich über die verwendete Schleife, um (vermeintlich) das Mounten des USB-Sticks zu erkennen und endet beim (für mich unnötigen) mkdir für das Verzeichnis mit den Log-Files (warum löscht man "alte" Log-Files, wenn man doch das Verzeichnis gerade erst angelegt hat?).

Außerdem wäre es Zufall bzw. "modellabhängig", ob die Änderung der ar7.cfg überhaupt übernommen wird (das Zurückschreiben von Änderungen mittels cp funktioniert i.d.R. nicht, aber mit etwas Glück - und dem richtigen Modell - wird damit wenigstens ein "regular file" angelegt, das den tatsächlichen Inhalt der ar7.cfg im TFFS "überdeckt" und damit kommt man dann zur (falschen) Feststellung, man hätte beim Editieren alles richtig gemacht), so wie das oben in #10 gemacht wurde.

Die erwähnte 5-Sekunden-Schleife ist u.a. auch deshalb unzuverlässig, weil zwischen dem Anlegen des Verzeichnisses für den Mount-Point (auf dessen Existenz wird ja mittels while ! -d <directory> getestet) und der tatsächlichen Verfügbarkeit des (gemounteten) Volumes durchaus noch einiges an Zeit vergehen kann und somit ist das (korrekte) Funktionieren dieser Schleife sehr stark davon abhängig, "wie kurz" nach dem Anlegen des Verzeichnisses (und da arbeitet das AVM-Skript (/etc/hotplug/udev-mount-sd) ähnlich wie FREETZMOUNT - man weiß ja auch nicht, was da konfiguriert wurde beim Freetz-NG-Build) der nächste Test erfolgt.

Denn auch wenn das Verzeichnis üblicherweise erst einmal so angelegt wird, daß da GAR KEINE Zugriffsrechte eingeräumt werden (so sieht es z.Zt. in der AVM-Firmware an dieser Stelle aus:

MNTPATH="$FTPDIR/$MNTNAME"
test -d "$MNTPATH" && rmdir "$MNTPATH"
if [ ! -d "$MNTPATH" ]; then
echo "Mounting [${MNTNAME}] to device $DEVNODE..." > /dev/console
mkdir -m 000 -p "$MNTPATH" ## create dir without access rights
if [ ! -d "$MNTPATH" ]; then
free_mount_reserve
mkdir -m 000 -p "$MNTPATH"
fi
break
else
if grep -q " ${MNTPATH} " /proc/mounts ; then
echo "[${MNTNAME}] already mounted" > /dev/console
else
if test -d "${MNTPATH}/FRITZ" && test "$(ls -A ${MNTPATH})" = "FRITZ" ; then
echo "FRITZ dir found, Mounting [${MNTNAME}] to device $DEVNODE anyway..." > /dev/console
break
fi
fi

), stört das den Test, ob es sich um ein Verzeichnis handelt, nicht weiter und der liefert unmittelbar nach dem mkdir dann auch schon true, womit die "Warteschleife" abgebrochen und die folgenden Befehle abgearbeitet werden, egal ob da das Volume tatsächlich schon gemountet wurde oder nicht. Ein korrekter Test würde z.B. an dieser Stelle auch noch prüfen, ob unter diesem Pfad auch TATSÄCHLICH ein Volume gemountet ist ... so, wie es oben bei AVM auch in einem else-Zweig zu sehen ist. Wenn sich in Freetz-NG nicht schon wieder vieles sehr grundsätzlich geändert haben sollte, müßte der Start der Freetz-Konfiguration (in dessen Rahmen dann auch die rc.custom abgearbeitet wird) mittlerweile parallel zum Rest der AVM-Initialisierung erfolgen und damit steigt dann natürlich auch das Risiko (das ist von der konkreten Konfiguration abhängig und davon, wie lange der Rest der Initialisierung braucht), daß es zu Race-Conditions kommt, weil eine "pre-condition" nicht sauber getestet wird.

Außerdem gibt es geschicktere Wege, eigene Aktionen bei einem erfolgreichen Mounten eines Volumes auszuführen - einer davon wäre z.B. die autorun.sh (https://github.com/Freetz-NG/freetz...ake/mod/files/root/usr/lib/libmodudevm.sh#L35), wenn man FREETZMOUNT verwendet und auch bei den AVM-Skripten für das Mounten über den udevd gäbe es (selbstverständlich neben der Änderung des verwendeten Codes, was natürlich auch denkbar wäre) noch genug andere Optionen, wo man sich in den Ablauf einklinken könnte ... und zwar OHNE solche "polling loops", die nun mal der ungeschickteste Weg sind, wenn man mit "modernen" Wegen der System-Initialisierung konfrontiert wird (wie das beim supervisor von AVM ja mittlerweile auch der Fall ist).

Eine (sichere und saubere) Option wäre es z.B., die udevd-Skripte (u.U. auch nur "dynamisch") so zu modifizieren, daß ein eigenes Shell-Skript bei jeder Konfigurationsänderung für Storage-Devices aufgerufen wird (denn so ein Stick kann auch mal (absichtlich oder "herausgerutscht") "ohne Ansage" entfernt werden) und in diesem Skript kann man dann (abhängig von dem, was da "behandelt" werden soll) die passenden Aktionen auslösen ... z.B. indem man dort dann erst einmal prüft, ob das Volume vorhanden ist bzw. gemountet wurde (wobei man auch die Suche nach dem richtigen Volume eben geschickter machen kann, dann funktioniert das auch nach dem Wechsel des verwendeten USB-Sticks weiterhin, ohne daß man da etwas ändern muß - im Moment ist der Hersteller und das Modell des Sticks ja Bestandteil des Pfades) und in Abhängigkeit davon dann den Dienst (neu) startet oder ihn auch anhält, wenn der Stick nicht mehr verfügbar ist. Ich bin im Moment auch nicht sicher, wie das FRITZ!OS reagiert, wenn die ausführbare Datei für einen (bereits laufenden) Dienst nicht mehr verfügbar ist - der "beste Fall" wäre es dann sogar, wenn der Service einfach abraucht; aber im schlechteren Fall hängt dann das ganze (Sub-)System an einem Leseversuch des Kernels für ein Volume, auf das nicht mehr zugegriffen werden kann.

---

Über die "generelle Sicherheit" solcher Lösungen, bei denen direkt (und ohne Validierung der dort hinterlegten Dateien) Prozesse von einem USB-Stick gestartet werden, sollte man hier lieber auch nicht nachdenken ... das ganze Konstrukt wäre jedenfalls so leicht "zu hacken" (einfach durch Kopieren des Inhalts des Sticks und das Ersetzen durch ein - passend konfiguriertes - eigenes Device), daß sich mir die Nackenhaare aufstellen.

Dabei wäre es doch eigentlich sogar sehr einfach, eine Lösung zu bauen, bei der man die Dateien für das gesamte Projekt (zumindest die Binaries) entsprechend sichert (das kann dadurch geschehen, daß man die Dateien direkt in ein signiertes Image packt oder man nimmt dort nur die Liste mit den Hash-Werten für die zu überwachenden Dateien auf) und VOR deren Verwendung noch prüft (bzw. von der AVM-Firmware prüfen läßt), ob dieses "plugin image" mit einer korrekten Signatur versehen wurde. Die Bausteine dafür existieren alle ... und ob man nun aus der rc.custom heraus irgendwelche Schleifen anschiebt oder das System so modifiziert, daß es auf neu gemounteten Volumes nach entsprechenden Image-Dateien sucht und diese dann (nach der Prüfung durch die AVM-Firmware) startet, ist am Ende vollkommen egal.

Das MUSS also nicht so unsicher sein, wie es von Dir oben beschrieben wird ... man KANN es auch so implementieren, daß ein Angreifer schon Zugriff auf den eigenen (privaten) Schlüssel zum Signieren (der Freetz-NG-Images) bräuchte, um sich da einzuklinken - zumindest kann man den Aufwand für einen potentiellen Angreifer mit wenig Aufwand so weit erhöhen, daß die meisten davon bereits von einem erfolgreichen(!) Angriff abgehalten würden.

 

[John Paden]

Hallo,

zunächst mal Danke an Peter, daß Du meinen Ansatz von allen Seiten beleuchtest, und ich freu mich wirkich über konstruktive Kritik.

- Pfad immer neu setzen:
mkdir /var/apache2
# ist nach dem reboot mmer weg
ln -s /var/media/ftp/Intenso-cMobileLine-01/apache2/logs /var/apache2/logs

ansonsten wirft der apache Fehlermeldungen beim Start.
Das Verzeichnis /var/apache2 ist immer nach dem reboot verschwunden. Gibt es eine Möglochkeit, das fest in den Flash zu schreiben?
Natürlich könne ich hier nochmal einen 'if exist dann nicht neu anlegen' einbauen - kommt noch

Die Logs liegen ja physikalisch auf dem externen Device, daher sind sie nicht weg.
Warum das so ist, habe ich nicht herausbekommen, ich hatte gehofft, alle Pfade in der apache2.conf hingebogen zu haben.
Diese Implementierung weicht an allerlei Stellen von der Debian variante ab (kein a2ensite usw.).

- korrekter Umgang mirt der ar7.cfg
... habe ich vermutlich einfach nicht verstanden. Hier in den Foren gibt es
cp /var/flash/ar7.cfg irgendwo/ar7.cfg
und
cat /var/flash/ar7.cfg > irgendwo/ar7.cfg
aber das ist ja nur das auslesen.
Wie genau soll das rückschreiben passieren, wenn nicht mit cp?
Und ist das für meine Box jetzt noch reparierbar? Sonst ... eben beim nächsten aufsetzen.

- autostart des Apapche servers
Kritik ist verstanden und akzeptiert, ist nicht schön, aber geht bisher zuverlässig, und wenn es mal nicht geht, kann man es auf 10 oder 15 Sekunden erweitern.
Den Freetzmount - heisst jetzt udevmount im menuconfig, korrekt? hab ich probiert, er hat aber keine autorun.sh ausgeführt. Werde ich nochmal untersuchen.
autorun.sh muss im root des USB devices liegen, also im /var/media/ftp/usbdevice/autorun.sh, korrekt?

- Deine Beschreibung, die udev Scripte zu dynamisieren - ich verstehe den Kontext ... das ist aktuell ausserhalb meiner Kompetenz.

- Implementierung innerhalb des signierten Pakets
In der Anleitung hier (Stand Juli 2011) https://freetz-ng.github.io/freetz-ng/make/apache2.html wird die Vorgehensweise, das getrennt zu installieren, empfohlen. Damit habe ich auch alles auf der angeschlossenen USB SSD, einigermassen schnell und separiert von den Speichern in der Box im Falle eines Box Crashes.
Das eröffnet natürlich auch Fehlerpotential und eine gewisse Hackbarkeit - da hast Du auf jeden Fall recht.

Stand der Dinge ist

vhosts für sites auf der Fritzbox funktioniert

<VirtualHost *:90>
ServerAdmin [email protected]
DocumentRoot "usr/share/apache2/htdocs/www.domain.de"
ServerName domain.de
ServerAlias www.domain.de
ErrorLog "logs/domain.de-error_log"
CustomLog "logs/domain.de-access_log" common
</VirtualHost>


vhosts für proxy sites auf der Pi, die hinter der Fritzbox hängt, funktioniert

<VirtualHost *:90>
ServerAdmin [email protected]
ServerName domain2.de
ServerAlias www.domain2.de
ProxyPreserveHost On
ProxyRequests Off
ProxyPass "/" "http://192.168.1.102:80/" nocanon
ProxyPassReverse "/" "http://192.168.1.102:80/"
ErrorLog "logs/domain2.de-error_log"
CustomLog "logs/domain2.de_log" common
</VirtualHost>

Jetzt muss ich mal sehen wie ich ssl für beide Varianten hinbekomme. Letsencrypt läuft ja vermutlich nicht auf der Firtzbox, oder hat das schon mal jemand probiert?

 

[PeterPawn]

Wie genau soll das rückschreiben passieren, wenn nicht mit cp?

Der TFFS-Treiber von AVM unterstützt nur "zeichenorientierte Ein-/Ausgabe-Operationen" (character-oriented I/O) und daher KANN man dort Daten auch nur mit solchen Operationen auslesen verarbeiten - das sieht im Quelltext des Treibers dann so aus bei der Definition der unterstützten Operationen:

 63 struct file_operations tffs_fops = {
 64         owner: THIS_MODULE,
 65         open: tffs_open,
 66         flush: tffs_flush,
 67         release: tffs_release,
 68         read: tffs_read,
 69         write: tffs_write,
 70         unlocked_ioctl: tffs_unlocked_ioctl,
 71 };

Solange jetzt beim Zugriff keine anderen Operationen verwendet werden (z.B. Positionieren mittels seek(), es sind ja deutlich mehr Operationen "vorgesehen", die nicht jeder Treiber implementieren muß: https://github.com/torvalds/linux/b...56d4c7ba2cbba22238e1/include/linux/fs.h#L2094), funktioniert tatsächlich auch das cp-Kommando in beide Richtungen, wie ich gerade getestet habe.

Nur vertraut(e) AVM selbst auch nur dem cat-Kommando bei diesen Operationen (es funktionierte tatsächlich auch früher nicht beim Zurückschreiben in einen TFFS-Node, wie man hier mehrfach nachlesen kann und zwar in Form von Erfahrungsberichten und ebenso in Form von Erklärungen, warum das so ist/war) und so findet sich noch heute in der AVM-Firmware ein Shell-Skript mit folgendem Inhalt, das für das Editieren von Textdaten in einem TFFS-Node gedacht ist:

# cat /usr/bin/nvi
#! /bin/sh
if [ -z "$1" ] ; then
        echo "use: $0 <config-filename>"
        exit 1
fi
cat $1 >/var/nvi.tmp && vi /var/nvi.tmp && cat /var/nvi.tmp >$1
rm -f  /var/nvi.tmp

#

Dort wird also ebenfalls (immer noch) zuerst der Inhalt des TFFS-Nodes in eine temporäre Datei kopiert, für diese dann ein Editor (hier vi) aufgerufen und danach der Inhalt der temporären Datei wieder in den TFFS-Node geschrieben ... wobei alle Zugriffe auf den TFFS-Node (sowohl beim Lesen als auch beim Schreiben) eben mittels cat ausgeführt werden.

Allerdings funktioniert (wie oben geschrieben: gerade getestet) in 07.39 tatsächlich auch der Schreibzugriff mittels cp sauber (zumindest wenn das Ziel beim Zurückkopieren bereits existiert und ein "character device" ist) ... insofern muß ich mich (und alte Erkenntnisse, die über lange Zeit Bestand hatten) korrigieren.

Da sich am Quelltext des cp-Kommandos (zumindest auf den ersten Blick) jetzt nichts Entscheidendes geändert hat, vermute ich mal, daß dieses geänderte Verhalten mit einer Überarbeitung des TFFS-Quellcodes Einzug gehalten hat (als "TFFS3"), bei der auch die ganzen neuen Formate (NAND-Flash als TFFS-Speicher, Client-/Server-Implementierung speziell für die DOCSIS-Boxen, etc.) implementiert wurden.

---

Ich weiß ja nicht, wieviel Platz der Apache2-httpd in Freetz-NG jetzt als Paket benötigt ... aber aus diversen Gründen (u.a. eben auch dem Schutz gegen "Verlust" des Volumes im laufenden Betrieb) würde ICH in diesem Fall hingehen und die Dateien für das Paket (bei jedem Neustart des Services) irgendwo ins tmpfs der Box kopieren (bei einer 7490 sind da > 100 MB verfügbar in der AVM-Firmware, bei der 3490 müßte es eher noch mehr sein, weil einige Services von AVM fehlen) und von dort starten ... und exakt dieses Kopieren ins tmpfs könnte (nein: sollte) man aus/mit einer signierten Image-Datei machen (selbst wenn Du das nicht so umsetzen willst, schaffe ich es vielleicht, anderen diesen Ansatz "schmackhaft" zu machen).

Das ist eigentlich auch sehr simpel (ich habe einige Beispiele im YourFritz-Repo liegen, wie so ein (per tr069fwupdate packet ...-Aufruf installierbares) Image erstellt werden kann, z.B. hier: https://github.com/PeterPawn/yf_bin/tree/10853cff8192081b282652bfa3e1082ef551b68a/scripts) und man ist - quasi automatisch - auf der sicheren Seite, daß einem da niemand Schadcode (zumindest nicht im Rahmen dieses Pakets) unterschieben kann.

Gleichzeitig löst man damit das Problem des Startens von einem "externen Datenträger" (bis hin zum Entfallen der Notwendigkeit, das noexec-Attribut beim Mounten zu entfernen) und alles weitere, was sich aus dem "plötzlichen Ausfall" so eines externen Mediums (z:B. durch "Abziehen" des Datenträgers oder auch durch das (software-seitige) Deaktivieren des USB-Stacks, ohne den Service vorher sauber zu beenden, denn bei AVM steht der natürlich NICHT in der Liste der zu beendenden Prozesse in der /var/post_install oder in der /bin/prepare_fwupgrade) an Problemen ergeben kann.

Ebenso kann man natürlich auch das gesamte Apache2-Paket in ein eigenes SquashFS-Image packen ... dann belegt es noch weniger Platz im tmpfs (weil die Daten ja komprimiert werden) und man kann es (in den meisten Modellen zumindest und die 3490 gehört dazu) auch problemlos irgendwo mounten und danach auf die Dateien in diesem SquashFS-Image zugreifen - auch DAS ist deutlich sicherer als der direkte Aufruf von einem externen Volume.

Es führen viele Wege nach Rom und man muß sicherlich nicht jeden davon nehmen ... aber gegenüber den (weiter oben zitierten) alten "Anleitungen" von fritzmod.net und auch die (geänderte) Anleitung für Freetz-NG ist nicht so richtig "taufrisch" (teilweise wird noch Version 2.2.4 referenziert und der Link auf den Thread aus 2011 für einen statisch gelinkten Server mit mod_proxy ist ja auch offensichtlich nicht wirklich aktuell), hat sich schon einiges geändert und als "Kochrezept", wenn man sich mit Cross-Compiling und Apache-Konfigurationen nicht wirklich auskennt (was man ja selbst in der Hand hat, die Beschreibungsseite in Freetz-NG verlinkt ja einiges an Quellen zu diesen Themen), taugte das eigentlich noch nie (und so war es nach meinem Verständnis auch nie gedacht).

---

Letsencrypt läuft ja vermutlich nicht auf der Firtzbox

1. Was ist eine Firtzbox?
2. Was genau von "Let's Encrypt" läuft denn auf anderen Geräten? Ich kenne das eigentlich nur als Zertifizierungsstelle (https://letsencrypt.org/de/) - wie genau "läuft" eine solche auf einem Gerät, bei dem es sich NICHT um einen der dortigen Server handelt?
3. Hast Du mal VERSUCHT, nach Beiträgen/Threads zu diesem Thema im Kontext von AVM-FRITZ!Boxen zu SUCHEN?

 

[John Paden]

Danke für den deep dive zu ar

>> Hast Du mal VERSUCHT, nach Beiträgen/Threads zu diesem Thema im Kontext von AVM-FRITZ!Boxen zu SUCHEN?
Ganz ehrlich - nein, noch nicht. Ich stecke noch zu tief in der Lernkurve, die .conf des Apache nachzuvollziehen.
Dann kommt SSL und Letsencrypt dran, wäre schön wenn das mal mit dem Proxy läuft.
Hab noch Strecke vor mir

 

[John Paden]

Hallo zusammen, diverse Nachtschichten mit lesen und testen später...

Status:
Habe die Box nochmal neu aufgesetzt, jetzt mit Apache und OpenSSL im Image. Apache läuft auf der FritzBox, ist von innen (port 90 und 453 und aussen Port 10080 und 100443 zu erreichen. yey. Braucht auch keinen noexec Patch.

http:// funktioniert. Aber https:// nicht. Ich habe ein SSL Wildcard Zertifikat, das zur Domain paßt. Aber:

curl https://domain.de:10443 -vs
* Trying 192.168.188.4:10443...
* Connected to domain.de (192.168.188.4) port 10443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0

Das zugehörige Log weist in die gleiche Richtung: SSL alert number 48 - findet den Weg zu einer trusted CA nicht.

[Mon Aug 08 16:45:14.183898 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2215): [client 192.168.188.200:52027] OpenSSL: Loop: SSLv3/TLS read client hello
[Mon Aug 08 16:45:14.199713 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2215): [client 192.168.188.200:52027] OpenSSL: Loop: SSLv3/TLS write server hello
[Mon Aug 08 16:45:14.204904 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2215): [client 192.168.188.200:52027] OpenSSL: Loop: SSLv3/TLS write change cipher spec
[Mon Aug 08 16:45:14.205653 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2215): [client 192.168.188.200:52027] OpenSSL: Loop: TLSv1.3 write encrypted extensions
[Mon Aug 08 16:45:14.212273 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2215): [client 192.168.188.200:52027] OpenSSL: Loop: SSLv3/TLS write certificate
[Mon Aug 08 16:45:14.500431 2022] [core:trace4] [pid 5457:tid 16277504] mpm_common.c(540): mpm child 5579 (gen 0/slot 3) started
[Mon Aug 08 16:45:14.506831 2022] [watchdog:debug] [pid 5579:tid 16277504] mod_watchdog.c(583): AH02981: Watchdog: Created child worker thread (_proxy_hcheck_).
[Mon Aug 08 16:45:14.508661 2022] [proxy:debug] [pid 5579:tid 16277504] proxy_util.c(2125): AH00925: initializing worker proxy:reverse shared
[Mon Aug 08 16:45:14.509104 2022] [proxy:debug] [pid 5579:tid 16277504] proxy_util.c(2185): AH00927: initializing worker proxy:reverse local
[Mon Aug 08 16:45:14.509604 2022] [proxy:debug] [pid 5579:tid 16277504] proxy_util.c(2217): AH00930: initialized pool in child 5579 for (*:80) min=0 max=25 smax=25
[Mon Aug 08 16:45:14.628928 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2215): [client 192.168.188.200:52027] OpenSSL: Loop: TLSv1.3 write server certificate verify
[Mon Aug 08 16:45:14.629508 2022] [ssl:trace6] [pid 5463:tid 1994535824] ssl_engine_io.c(219): [client 192.168.188.200:52027] bio_filter_out_write: 3324 bytes
[Mon Aug 08 16:45:14.629617 2022] [ssl:trace4] [pid 5463:tid 1994535824] ssl_engine_io.c(2406): [client 192.168.188.200:52027] OpenSSL: write 3324/3324 bytes to BIO#10960d0 [mem: 10db210]
[Mon Aug 08 16:45:14.629675 2022] [ssl:trace6] [pid 5463:tid 1994535824] ssl_engine_io.c(156): [client 192.168.188.200:52027] bio_filter_out_write: flush
[Mon Aug 08 16:45:14.630375 2022] [core:trace6] [pid 5463:tid 1994535824] core_filters.c(830): [client 192.168.188.200:52027] writev_nonblocking: 3324/3324
[Mon Aug 08 16:45:14.631606 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2215): [client 192.168.188.200:52027] OpenSSL: Loop: SSLv3/TLS write finished
[Mon Aug 08 16:45:14.631709 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2215): [client 192.168.188.200:52027] OpenSSL: Loop: TLSv1.3 early data
[Mon Aug 08 16:45:14.688907 2022] [ssl:trace4] [pid 5463:tid 1994535824] ssl_engine_io.c(2406): [client 192.168.188.200:52027] OpenSSL: read 5/5 bytes from BIO#10cc828 [mem: 10de2d3]
[Mon Aug 08 16:45:14.689114 2022] [ssl:trace4] [pid 5463:tid 1994535824] ssl_engine_io.c(2406): [client 192.168.188.200:52027] OpenSSL: read 2/2 bytes from BIO#10cc828 [mem: 10de2d8]
[Mon Aug 08 16:45:14.689180 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2220): [client 192.168.188.200:52027] OpenSSL: Read: TLSv1.3 early data
[Mon Aug 08 16:45:14.689288 2022] [ssl:trace3] [pid 5463:tid 1994535824] ssl_engine_kernel.c(2244): [client 192.168.188.200:52027] OpenSSL: Exit: error in error
[Mon Aug 08 16:45:14.689352 2022] [ssl:info] [pid 5463:tid 1994535824] [client 192.168.188.200:52027] AH02008: SSL library error 1 in handshake (server domain.de:453)
[Mon Aug 08 16:45:14.689631 2022] [ssl:info] [pid 5463:tid 1994535824] SSL Library Error: error:14094418:lib(20):func(148):reason(1048) (SSL alert number 48)
[Mon Aug 08 16:45:14.689701 2022] [ssl:info] [pid 5463:tid 1994535824] [client 192.168.188.200:52027] AH01998: Connection closed to child 0 with abortive shutdown (server domain:453)

Meine Fragen:
gehe ich recht in der Annahme, daß das die CA in
/mod/etc/ssl/certs/ca-bundle.crt
liegt? Welches auf
/etc/ssl/certs/ca-bundle.crt
zeigt...

Ein Test mit
openssl verify /etc/ssl/certs/ca-bundle.crt
gibt
C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
error 18 at 0 depth lookup: self signed certificate
error /etc/ssl/certs/ca-bundle.crt: verification failed
-> das würe passen.

Wenn das so ist
- wie kopiert man da hin, ohne die Box zu instabilisieren?
- woher eine ca-bundle.ctr nehmen, die funktioniert? Eine testweise kopierte ca-bundle.ctr von einer Pi funktioniert nicht
- wie startet man Openssl neu. ohne die Box zu instabilisieren? Für den Fall daß die neue ca-bundle beim Start eingelesen wird...
- Oder könnte man die /etc/ssl/openssl.cnf ändern / überkopieren, die ja auch im TFFS liegt? Das müßte aber vor dem Start von openssl geschehen...
cat /var/media/ftp/ssd120gb/openssl.cnf > /etc/ssl/openssl.cnf tut nicht...
(Und nein, ich bin dazu aus der Forums-Recherche nicht schlauer geworden)
Danke für jeden Input ...

 

[John Paden]

.. es ist zum Verzweifeln.

Auch das Problem, das richtige CA zu bauen habe ich mit Hilfe eines Freundes lösen können.

<VirtualHost *:453>
    ServerAdmin [EMAIL][email protected][/EMAIL]
    ServerName domain.de:453
    ServerAlias [URL='http://www.domain.de:453']www.domain.de:453[/URL]
    DocumentRoot "usr/htdocs/www.domain.de"

    ErrorLog  "logs/error_log"
    CustomLog "logs/error_log" common
    CustomLog "logs/error_log"  "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

    SSLCertificateFile       etc/ssl/domain.de/fullchain1.pem
    SSLCertificateKeyFile    etc/ssl/domain.de/privkey1.pem
    SSLCACertificateFile  etc/ssl/domain.de/ca-bundle.crt

</VirtualHost>

Wir haben den Apache auch mal ohne statische Links und mit loadable modules gebaut. Geht auch. Macht aber das gleiche Problem, denn ich stehe wieder an einer Stelle an der ich schon zig mal stand:

Der Client und Apache verhandeln brav die Protokolle, Apache schickt die index.html zurück an den Client - curl oder Browser - aber auf dem Client kommt nichts mehr an.
Als ob die Fritzbox den Rückweg zusperrt.

Das Problem gibt es bei http nicht, da kommt das Paket an.

Versucht der Apache in irgendein File zu schreiben, was im read-only Filesystem liegt?

Oder gibts beim Portmapping noch was zu beachten, damit die Daten auf dem Rückweg nicht verschluckt werden?
Ich habe in der ar7.cfg eingetragen:

internet_forwardrules = "tcp 0.0.0.0:10080 0.0.0.0:90",
"tcp 0.0.0.0:10443 0.0.0.0:453";

Jeder Hinweis willkommen...... (@PeterPawn , hab ich wieder einen Patch vergessen?!)

Hier z.B der curl (Ergänzug, die Reaktion ist die gleiche ob vom inneren Netz der Box
curl https://domain.de:453 -v insecure --cacert ca-bundle.crt oder extern jeweils den DNS angepasst)

curl [URL]https://domain.de:10443[/URL] -v insecure --cacert ca-bundle.crt
*   Trying 192.168.188.4:10443...
* Connected to domain.de (192.168.188.4) port 10443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: ca-bundle.crt
*  CApath: none
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=domain.de
*  start date: Jul 31 17:43:21 2022 GMT
*  expire date: Oct 29 17:43:20 2022 GMT
*  subjectAltName: host "domain.de" matched cert's "domain.de"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/1.1
> Host: domain.de:10443
> User-Agent: curl/7.84.0
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing

Und das Server Log im Trace6:

[Wed Aug 10 18:49:13.109506 2022] [ssl:trace1] [pid 6693:tid 1996992512] ssl_engine_init.c(1000): Configuring permitted SSL ciphers [HIGH:MEDIUM:!SSLv3:!kRSA:!aNULL:!eNULL:!EXP]
[Wed Aug 10 18:49:13.110458 2022] [ssl:debug] [pid 6693:tid 1996992512] ssl_engine_init.c(527): AH01893: Configuring TLS extension handling
[Wed Aug 10 18:49:13.118034 2022] [ssl:trace3] [pid 6693:tid 1996992512] ssl_util_ssl.c(440): [domain.de:453] modssl_X509_match_name: expecting name 'domain.de', matched by ID 'domain.de'
[Wed Aug 10 18:49:13.118922 2022] [ssl:debug] [pid 6693:tid 1996992512] ssl_util_ssl.c(451): AH02412: [domain.de:453] Cert matches for name 'domain.de' [subject: CN=domain.de / issuer: CN=R3,O=Let's Encrypt,C=US / serial: 044BC668646FEE93DFFEBA23C5BB>
[Wed Aug 10 18:49:13.119086 2022] [ssl:info] [pid 6693:tid 1996992512] AH02568: Certificate and private key domain.de:453:0 configured from /var/media/ftp/ssd120gb/apache/etc/ssl/domain.de/fullchain1.pem and /var/media/ftp/ssd120gb/apache/etc/ssl/pa>
[Wed Aug 10 18:49:13.123529 2022] [ssl:info] [pid 6693:tid 1996992512] AH01876: mod_ssl/2.4.54 compiled against Server: Apache/2.4.54, Library: OpenSSL/1.1.1q
[Wed Aug 10 18:49:13.129245 2022] [core:trace4] [pid 6693:tid 1996992512] mpm_common.c(540): mpm child 6698 (gen 0/slot 0) started
[Wed Aug 10 18:49:13.130826 2022] [core:trace4] [pid 6693:tid 1996992512] mpm_common.c(540): mpm child 6699 (gen 0/slot 1) started
[Wed Aug 10 18:49:13.132281 2022] [core:trace4] [pid 6693:tid 1996992512] mpm_common.c(540): mpm child 6700 (gen 0/slot 2) started
[Wed Aug 10 18:49:13.132503 2022] [mpm_worker:notice] [pid 6693:tid 1996992512] AH00292: Apache/2.4.54 (Unix) OpenSSL/1.1.1q configured -- resuming normal operations
[Wed Aug 10 18:49:13.132573 2022] [mpm_worker:info] [pid 6693:tid 1996992512] AH00293: Server built: Aug 10 2022 17:01:04
[Wed Aug 10 18:49:13.132792 2022] [core:notice] [pid 6693:tid 1996992512] AH00094: Command line: '/usr/sbin/apache2 -f /var/media/ftp/ssd120gb/apache/etc/apache2.conf'
[Wed Aug 10 18:49:13.132891 2022] [core:debug] [pid 6693:tid 1996992512] log.c(1573): AH02639: Using SO_REUSEPORT: yes (1)
[Wed Aug 10 18:49:13.132973 2022] [mpm_worker:debug] [pid 6693:tid 1996992512] worker.c(1805): AH00294: Accept mutex: sysvsem (default: sysvsem)
[Wed Aug 10 18:49:24.712114 2022] [core:trace5] [pid 6698:tid 1986286848] protocol.c(713): [client 192.168.188.209:65261] Request received from client: GET / HTTP/1.1
[Wed Aug 10 18:49:24.713221 2022] [http:trace4] [pid 6698:tid 1986286848] http_request.c(436): [client 192.168.188.209:65261] Headers received from client:
[Wed Aug 10 18:49:24.714390 2022] [http:trace4] [pid 6698:tid 1986286848] http_request.c(440): [client 192.168.188.209:65261]   Host: domain.de:10080
[Wed Aug 10 18:49:24.714636 2022] [http:trace4] [pid 6698:tid 1986286848] http_request.c(440): [client 192.168.188.209:65261]   User-Agent: curl/7.84.0
[Wed Aug 10 18:49:24.714784 2022] [http:trace4] [pid 6698:tid 1986286848] http_request.c(440): [client 192.168.188.209:65261]   Accept: */*
[Wed Aug 10 18:49:24.715476 2022] [authz_core:debug] [pid 6698:tid 1986286848] mod_authz_core.c(818): [client 192.168.188.209:65261] AH01626: authorization result of Require all granted: granted
[Wed Aug 10 18:49:24.715663 2022] [authz_core:debug] [pid 6698:tid 1986286848] mod_authz_core.c(818): [client 192.168.188.209:65261] AH01626: authorization result of <RequireAny>: granted
[Wed Aug 10 18:49:24.715809 2022] [core:trace3] [pid 6698:tid 1986286848] request.c(362): [client 192.168.188.209:65261] request authorized without authentication by access_checker_ex hook: /
[Wed Aug 10 18:49:24.717901 2022] [http:trace3] [pid 6698:tid 1986286848] http_filters.c(1132): [client 192.168.188.209:65261] Response sent with status 200, headers:
[Wed Aug 10 18:49:24.718174 2022] [http:trace5] [pid 6698:tid 1986286848] http_filters.c(1139): [client 192.168.188.209:65261]   Date: Wed, 10 Aug 2022 16:49:24 GMT
[Wed Aug 10 18:49:24.718308 2022] [http:trace5] [pid 6698:tid 1986286848] http_filters.c(1142): [client 192.168.188.209:65261]   Server: Apache/2.4.54 (Unix)
[Wed Aug 10 18:49:24.718498 2022] [http:trace4] [pid 6698:tid 1986286848] http_filters.c(961): [client 192.168.188.209:65261]   Last-Modified: Wed, 10 Aug 2022 12:13:04 GMT
[Wed Aug 10 18:49:24.718684 2022] [http:trace4] [pid 6698:tid 1986286848] http_filters.c(961): [client 192.168.188.209:65261]   ETag: \\"160-5e5e1f88dd400\\"
[Wed Aug 10 18:49:24.718827 2022] [http:trace4] [pid 6698:tid 1986286848] http_filters.c(961): [client 192.168.188.209:65261]   Accept-Ranges: bytes
[Wed Aug 10 18:49:24.718961 2022] [http:trace4] [pid 6698:tid 1986286848] http_filters.c(961): [client 192.168.188.209:65261]   Content-Length: 352
[Wed Aug 10 18:49:24.719099 2022] [http:trace4] [pid 6698:tid 1986286848] http_filters.c(961): [client 192.168.188.209:65261]   Content-Type: text/html
[Wed Aug 10 18:49:24.721122 2022] [core:trace6] [pid 6698:tid 1986286848] core_filters.c(830): [client 192.168.188.209:65261] writev_nonblocking: 579/579
[Wed Aug 10 18:49:28.871050 2022] [ssl:info] [pid 6699:tid 1984189696] [client 192.168.188.209:65264] AH01964: Connection to child 66 established (server domain.de:453)
[Wed Aug 10 18:49:28.877597 2022] [ssl:trace2] [pid 6699:tid 1984189696] ssl_engine_rand.c(126): Server: Seeding PRNG with 1160 bytes of entropy
[Wed Aug 10 18:49:28.880797 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2206): [client 192.168.188.209:65264] OpenSSL: Handshake: start
[Wed Aug 10 18:49:28.885017 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: before SSL initialization
[Wed Aug 10 18:49:28.893144 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: read 5/5 bytes from BIO#8df4b0 [mem: 933503]
[Wed Aug 10 18:49:28.894087 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: read 512/512 bytes from BIO#8df4b0 [mem: 933508]
[Wed Aug 10 18:49:28.894405 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: before SSL initialization
[Wed Aug 10 18:49:28.894988 2022] [ssl:debug] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2397): [client 192.168.188.209:65264] AH02043: SSL virtual host for servername domain.de found
[Wed Aug 10 18:49:28.897033 2022] [core:debug] [pid 6699:tid 1984189696] protocol.c(2461): [client 192.168.188.209:65264] AH03155: select protocol from , choices=h2,http/1.1 for server domain.de
[Wed Aug 10 18:49:28.899466 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: SSLv3/TLS read client hello
[Wed Aug 10 18:49:28.917016 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: SSLv3/TLS write server hello
[Wed Aug 10 18:49:28.923193 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: SSLv3/TLS write change cipher spec
[Wed Aug 10 18:49:28.924051 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: TLSv1.3 write encrypted extensions
[Wed Aug 10 18:49:28.929963 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(219): [client 192.168.188.209:65264] bio_filter_out_write: 4096 bytes
[Wed Aug 10 18:49:28.932658 2022] [core:trace6] [pid 6699:tid 1984189696] core_filters.c(830): [client 192.168.188.209:65264] writev_nonblocking: 4096/4096
[Wed Aug 10 18:49:28.932939 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: write 4096/4096 bytes to BIO#8df430 [mem: 93c6b8]
[Wed Aug 10 18:49:28.936868 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: SSLv3/TLS write certificate
[Wed Aug 10 18:49:29.156451 2022] [core:trace4] [pid 6693:tid 1996992512] mpm_common.c(540): mpm child 6795 (gen 0/slot 3) started
[Wed Aug 10 18:49:29.318225 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: TLSv1.3 write server certificate verify
[Wed Aug 10 18:49:29.319390 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(219): [client 192.168.188.209:65264] bio_filter_out_write: 494 bytes
[Wed Aug 10 18:49:29.319550 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: write 494/494 bytes to BIO#8df430 [mem: 93c6b8]
[Wed Aug 10 18:49:29.319656 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(156): [client 192.168.188.209:65264] bio_filter_out_write: flush
[Wed Aug 10 18:49:29.320370 2022] [core:trace6] [pid 6699:tid 1984189696] core_filters.c(830): [client 192.168.188.209:65264] writev_nonblocking: 494/494
[Wed Aug 10 18:49:29.322794 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: SSLv3/TLS write finished
[Wed Aug 10 18:49:29.322939 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: TLSv1.3 early data
[Wed Aug 10 18:49:29.394512 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: read 5/5 bytes from BIO#8df4b0 [mem: 93f6fb]
[Wed Aug 10 18:49:29.394818 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: read 1/1 bytes from BIO#8df4b0 [mem: 93f700]
[Wed Aug 10 18:49:29.394939 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: read 5/5 bytes from BIO#8df4b0 [mem: 93f6fb]
[Wed Aug 10 18:49:29.395058 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: read 69/69 bytes from BIO#8df4b0 [mem: 93f700]
[Wed Aug 10 18:49:29.395330 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: TLSv1.3 early data
[Wed Aug 10 18:49:29.397362 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: SSLv3/TLS read finished
[Wed Aug 10 18:49:29.397686 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2210): [client 192.168.188.209:65264] OpenSSL: Handshake: done
[Wed Aug 10 18:49:29.397886 2022] [ssl:debug] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2259): [client 192.168.188.209:65264] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits)
[Wed Aug 10 18:49:29.400156 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(219): [client 192.168.188.209:65264] bio_filter_out_write: 303 bytes
[Wed Aug 10 18:49:29.400604 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: write 303/303 bytes to BIO#8df430 [mem: 93c6b8]
[Wed Aug 10 18:49:29.400719 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(156): [client 192.168.188.209:65264] bio_filter_out_write: flush
[Wed Aug 10 18:49:29.401550 2022] [core:trace6] [pid 6699:tid 1984189696] core_filters.c(830): [client 192.168.188.209:65264] writev_nonblocking: 303/303
[Wed Aug 10 18:49:29.401722 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: SSLv3/TLS write session ticket
[Wed Aug 10 18:49:29.404020 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(219): [client 192.168.188.209:65264] bio_filter_out_write: 303 bytes
[Wed Aug 10 18:49:29.404183 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: write 303/303 bytes to BIO#8df430 [mem: 93c6b8]
[Wed Aug 10 18:49:29.404284 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(156): [client 192.168.188.209:65264] bio_filter_out_write: flush
[Wed Aug 10 18:49:29.404900 2022] [core:trace6] [pid 6699:tid 1984189696] core_filters.c(830): [client 192.168.188.209:65264] writev_nonblocking: 303/303
[Wed Aug 10 18:49:29.405043 2022] [ssl:trace3] [pid 6699:tid 1984189696] ssl_engine_kernel.c(2215): [client 192.168.188.209:65264] OpenSSL: Loop: SSLv3/TLS write session ticket
[Wed Aug 10 18:49:29.420067 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: read 5/5 bytes from BIO#8df4b0 [mem: 93919b]
[Wed Aug 10 18:49:29.420340 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: read 95/95 bytes from BIO#8df4b0 [mem: 9391a0]
[Wed Aug 10 18:49:29.420714 2022] [core:trace5] [pid 6699:tid 1984189696] protocol.c(713): [client 192.168.188.209:65264] Request received from client: GET / HTTP/1.1
[Wed Aug 10 18:49:29.421214 2022] [ssl:debug] [pid 6699:tid 1984189696] ssl_engine_kernel.c(422): [client 192.168.188.209:65264] AH02034: Initial (No.1) HTTPS request received for child 66 (server domain.de:453)
[Wed Aug 10 18:49:29.421355 2022] [http:trace4] [pid 6699:tid 1984189696] http_request.c(436): [client 192.168.188.209:65264] Headers received from client:
[Wed Aug 10 18:49:29.421642 2022] [http:trace4] [pid 6699:tid 1984189696] http_request.c(440): [client 192.168.188.209:65264]   Host: domain.de:10443
[Wed Aug 10 18:49:29.421728 2022] [http:trace4] [pid 6699:tid 1984189696] http_request.c(440): [client 192.168.188.209:65264]   User-Agent: curl/7.84.0
[Wed Aug 10 18:49:29.421810 2022] [http:trace4] [pid 6699:tid 1984189696] http_request.c(440): [client 192.168.188.209:65264]   Accept: */*
[Wed Aug 10 18:49:29.422312 2022] [authz_core:debug] [pid 6699:tid 1984189696] mod_authz_core.c(818): [client 192.168.188.209:65264] AH01626: authorization result of Require all granted: granted
[Wed Aug 10 18:49:29.422430 2022] [authz_core:debug] [pid 6699:tid 1984189696] mod_authz_core.c(818): [client 192.168.188.209:65264] AH01626: authorization result of <RequireAny>: granted
[Wed Aug 10 18:49:29.422562 2022] [core:trace3] [pid 6699:tid 1984189696] request.c(362): [client 192.168.188.209:65264] request authorized without authentication by access_checker_ex hook: /
[Wed Aug 10 18:49:29.423504 2022] [http:trace3] [pid 6699:tid 1984189696] http_filters.c(1132): [client 192.168.188.209:65264] Response sent with status 200, headers:
[Wed Aug 10 18:49:29.423621 2022] [http:trace5] [pid 6699:tid 1984189696] http_filters.c(1139): [client 192.168.188.209:65264]   Date: Wed, 10 Aug 2022 16:49:29 GMT
[Wed Aug 10 18:49:29.423702 2022] [http:trace5] [pid 6699:tid 1984189696] http_filters.c(1142): [client 192.168.188.209:65264]   Server: Apache/2.4.54 (Unix)
[Wed Aug 10 18:49:29.423811 2022] [http:trace4] [pid 6699:tid 1984189696] http_filters.c(961): [client 192.168.188.209:65264]   Last-Modified: Wed, 10 Aug 2022 12:13:04 GMT
[Wed Aug 10 18:49:29.424122 2022] [http:trace4] [pid 6699:tid 1984189696] http_filters.c(961): [client 192.168.188.209:65264]   ETag: \\"160-5e5e1f88dd400\\"
[Wed Aug 10 18:49:29.424221 2022] [http:trace4] [pid 6699:tid 1984189696] http_filters.c(961): [client 192.168.188.209:65264]   Accept-Ranges: bytes
[Wed Aug 10 18:49:29.424302 2022] [http:trace4] [pid 6699:tid 1984189696] http_filters.c(961): [client 192.168.188.209:65264]   Content-Length: 352
[Wed Aug 10 18:49:29.424384 2022] [http:trace4] [pid 6699:tid 1984189696] http_filters.c(961): [client 192.168.188.209:65264]   Content-Type: text/html
[Wed Aug 10 18:49:29.424576 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(1856): [client 192.168.188.209:65264] coalesce: have 0 bytes, adding 227 more (buckets=1)
[Wed Aug 10 18:49:29.424686 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(1856): [client 192.168.188.209:65264] coalesce: have 227 bytes, adding 352 more (buckets=1)
[Wed Aug 10 18:49:29.425275 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(1917): [client 192.168.188.209:65264] coalesce: passing on 579 bytes
[Wed Aug 10 18:49:29.425548 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(892): [client 192.168.188.209:65264] ssl_filter_write: 579 bytes
[Wed Aug 10 18:49:29.426322 2022] [ssl:trace6] [pid 6699:tid 1984189696] ssl_engine_io.c(219): [client 192.168.188.209:65264] bio_filter_out_write: 601 bytes
[Wed Aug 10 18:49:29.426510 2022] [ssl:trace4] [pid 6699:tid 1984189696] ssl_engine_io.c(2406): [client 192.168.188.209:65264] OpenSSL: write 601/601 bytes to BIO#8df430 [mem: 93f6fb]

[Edit Novize: Logs und Co in Code gefasst]

 

[John Paden]

Versuch mit anderen Ports, auch mit voip_forwardrules

        mcupstream = "internet";
        voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                            "tcp 0.0.0.0:5060 0.0.0.0:5060",
                            "udp 0.0.0.0:7078+20 0.0.0.0:7078",
                            "tcp 0.0.0.0:180 0.0.0.0:180",
                            "tcp 0.0.0.0:543 0.0.0.0:543";

        voip_ip6_forwardrules = "udp 5060 # SIP", "tcp 5060 # SIP",
                                "udp 7078-7097 # RTP";
        tr069_ip6_forwardrules = "tcp 8089";
        internet_in_nat_rules_enabled = yes;
        internet_out_nat_rules_enabled = yes;
        internet_forwardrules = "tcp 0.0.0.0:280 0.0.0.0:280",
                                "tcp 0.0.0.0:643 0.0.0.0:643";

-> apache funktioniert mit port 180 und port 280, aber nicht mit port 543 oder 643.

Versuch mit Openssl 3.0 (experimental)

Versuch mit Openssl extra als Paket hinzugelinkt



Und zwar jedesmal mit dem Problem, daß die

Cypherverhandlungen funktionieren
Der request vom Client ankommt
Apache den Request mit 200 beantwortet
Openssl das Ergebnis zum BIO Worker zurückschickt
und dann die Kommunikation abbricht, und nichts beim Client ankommt.

Hast das jemand am laufen?

[Sun Aug 14 17:57:09.065013 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(436): [client 192.168.150.215:63312] Headers received from client:
[Sun Aug 14 17:57:09.065057 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Host: domain.de:543
[Sun Aug 14 17:57:09.065100 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   User-Agent: Mozilla/5.0 (Windows NT 10.                                                                0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0
[Sun Aug 14 17:57:09.065148 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Accept: text/html,application/xhtml+xml                                                                ,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
[Sun Aug 14 17:57:09.065219 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Accept-Language: de,en-US;q=0.7,en;q=0.                                                                3
[Sun Aug 14 17:57:09.065266 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Accept-Encoding: gzip, deflate, br
[Sun Aug 14 17:57:09.065307 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   DNT: 1
[Sun Aug 14 17:57:09.065348 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Connection: keep-alive
[Sun Aug 14 17:57:09.065388 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Upgrade-Insecure-Requests: 1
[Sun Aug 14 17:57:09.065429 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Sec-Fetch-Dest: document
[Sun Aug 14 17:57:09.065470 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Sec-Fetch-Mode: navigate
[Sun Aug 14 17:57:09.065512 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Sec-Fetch-Site: none
[Sun Aug 14 17:57:09.065552 2022] [http:trace4] [pid 5208:tid 1979892992] http_request.c(440): [client 192.168.150.215:63312]   Sec-Fetch-User: ?1
[Sun Aug 14 17:57:09.065821 2022] [authz_core:debug] [pid 5208:tid 1979892992] mod_authz_core.c(818): [client 192.168.150.215:63312] AH01626: authorization result of R                                                                equire all granted: granted
[Sun Aug 14 17:57:09.065881 2022] [authz_core:debug] [pid 5208:tid 1979892992] mod_authz_core.c(818): [client 192.168.150.215:63312] AH01626: authorization result of <                                                                RequireAny>: granted
[Sun Aug 14 17:57:09.065925 2022] [core:trace3] [pid 5208:tid 1979892992] request.c(362): [client 192.168.150.215:63312] request authorized without authentication by a                                                                ccess_checker_ex hook: /
[Sun Aug 14 17:57:09.066413 2022] [http:trace3] [pid 5208:tid 1979892992] http_filters.c(1132): [client 192.168.150.215:63312] Response sent with status 200, headers:
[Sun Aug 14 17:57:09.066472 2022] [http:trace5] [pid 5208:tid 1979892992] http_filters.c(1139): [client 192.168.150.215:63312]   Date: Sun, 14 Aug 2022 15:57:09 GMT
[Sun Aug 14 17:57:09.066511 2022] [http:trace5] [pid 5208:tid 1979892992] http_filters.c(1142): [client 192.168.150.215:63312]   Server: Apache/2.4.54 (Unix)
[Sun Aug 14 17:57:09.066561 2022] [http:trace4] [pid 5208:tid 1979892992] http_filters.c(961): [client 192.168.150.215:63312]   Last-Modified: Wed, 10 Aug 2022 12:13:0                                                                4 GMT
[Sun Aug 14 17:57:09.066780 2022] [http:trace4] [pid 5208:tid 1979892992] http_filters.c(961): [client 192.168.150.215:63312]   ETag: \\"160-5e5e1f88dd400\\"
[Sun Aug 14 17:57:09.066828 2022] [http:trace4] [pid 5208:tid 1979892992] http_filters.c(961): [client 192.168.150.215:63312]   Accept-Ranges: bytes
[Sun Aug 14 17:57:09.066870 2022] [http:trace4] [pid 5208:tid 1979892992] http_filters.c(961): [client 192.168.150.215:63312]   Content-Length: 352
[Sun Aug 14 17:57:09.066911 2022] [http:trace4] [pid 5208:tid 1979892992] http_filters.c(961): [client 192.168.150.215:63312]   Keep-Alive: timeout=5, max=100
[Sun Aug 14 17:57:09.066953 2022] [http:trace4] [pid 5208:tid 1979892992] http_filters.c(961): [client 192.168.150.215:63312]   Connection: Keep-Alive
[Sun Aug 14 17:57:09.067218 2022] [http:trace4] [pid 5208:tid 1979892992] http_filters.c(961): [client 192.168.150.215:63312]   Content-Type: text/html
[Sun Aug 14 17:57:09.067312 2022] [ssl:trace4] [pid 5208:tid 1979892992] ssl_engine_io.c(1856): [client 192.168.150.215:63312] coalesce: have 0 bytes, adding 283 more                                                                 (buckets=1)
[Sun Aug 14 17:57:09.067370 2022] [ssl:trace4] [pid 5208:tid 1979892992] ssl_engine_io.c(1856): [client 192.168.150.215:63312] coalesce: have 283 bytes, adding 352 mor                                                                e (buckets=1)
[Sun Aug 14 17:57:09.067721 2022] [ssl:trace4] [pid 5208:tid 1979892992] ssl_engine_io.c(1917): [client 192.168.150.215:63312] coalesce: passing on 635 bytes
[Sun Aug 14 17:57:09.067807 2022] [ssl:trace6] [pid 5208:tid 1979892992] ssl_engine_io.c(892): [client 192.168.150.215:63312] ssl_filter_write: 635 bytes
[Sun Aug 14 17:57:09.068126 2022] [ssl:trace6] [pid 5208:tid 1979892992] ssl_engine_io.c(219): [client 192.168.150.215:63312] bio_filter_out_write: 657 bytes
[Sun Aug 14 17:57:09.068196 2022] [ssl:trace4] [pid 5208:tid 1979892992] ssl_engine_io.c(2406): [client 192.168.150.215:63312] OpenSSL: write 657/657 bytes to BIO#8dff                                                                10 [mem: 909f0b]
root@fritz:/var/media/ftp/usb64gb/apache#

[Edit Novize: Logs und Co in Code gefasst]

 

[John Paden]

Da ich auf diesem Wege nicht weiterkomme, habe ich HAProxy 'entdeckt'.

Erste Schritte mit http sind schon im Blindflug erfolgreich, aaaber...
HAProxy error-loggt nur in Zusammenarbeit mit syslogd aus der Busybox.
Wie geht hier die Integration?
Oder brauche ich einen zweiten syslogd?
Und nein - ich habe keine Link zu diesem Thema gefunden.

Vielen Dank für jeden Tip.

 

[John Paden]

Die Idee war es, mit Freetz (auf der 7580) einen flexiblen Reverse Proxy zu bauen
- der FB typisch eben nur eine Eingangs IP hat
- hinter der Provider FB hängt (Portforwarding von Port 80 und 443 auf in diesem Fall 1080 und 1443)
- nicht mit ctlmgr etc in Konflikt kommt
- mehrere domains und mehrere Websites auf der Box hosten kann, mit SSL und ohne - tendenziell einfache, statische Pages, um die Box nicht zu überlasten
- mehrere domains und mehrere Websites (z.B. auf einer Pi) hinter der Box zu hosten, ebenfalls mit SSL und ohne.

Nach allerlei Lernkurve, z.B.
- 7580 neu aufsetzen mit Adam und Eva
- Portdurchreichung von in ar7.cfg
cat /var/flash/ar7.cfg > /var/media/ftp/usbdevice/ar7.cfg
nano /var/media/ftp/usbdevice/ar7.cfg

        internet_out_nat_rules_enabled = yes;
        internet_forwardrules = "tcp 0.0.0.0:1080 0.0.0.0:180",
                                "tcp 0.0.0.0:1443 0.0.0.0:543";

ctlmgr -s; voipd -s; cp /var/media/ftp/usbdevice/ar7.cfg /var/flash/ar7.cfg; reboot

- mehreren Apache Installationen, schlussendlich in der Variante mit loadable modules und nicht statisch gelinkt, die den "Drop noexec for (external) storages" patch nicht braucht
bin ich vermutlich an diesem Apache Bug https://bz.apache.org/bugzilla/show_bug.cgi?format=multiple&id=46952 stehen geblieben.
Trotz allen möglichen Versuchen gibt Apache unter SSL ganz am Ende der Transaktion die Daten nicht korrekt zurück, unabhängig von den Cyphers, SSL Varianten und Umfang der ca-bundles. Logs siehe oben.
Ernüchternd. Über Zusendung einer funktionierenden Konfiguration per PM würde ich mich freuen.

Wenn nicht so, dann eben anders - HA-Proxy.

Hier stellte es sich als knifflich heraus, einerseits die Domains zu trennen, andererseits auch die wegen des Apache Bugs von oben, für die Websites auf der Box SSL schon bei HA-Proxy zu terminieren. Dazu brauchte es einen loopback unter Verwendung von abns@haproxy-tls .
Hier Dank an zeusz4u 18.08.2018 https://discourse.haproxy.org/t/tls...oth-tls-and-plain-tcp-on-the-same-port/2885/9

Die Gui Page für Zertifikate funktioniert prima, aber nur für ein vollständiges Zertifikat-Set, für eine Domain.
Für mehrere Domains brauchts mehrere Dateien, z.B. ...... ssl crt /tmp/flash/haproxy/haproxy-domain1.de.pem

Noch einzubauende Verbesserungen würden z.B. eine default website unter default_backend für den Fehlerfall enthalten, uvm.

Hier die Konfiguration, die schon mal läuft:

global
     tune.ssl.default-dh-param 2048
     pidfile /var/run/haproxy.pid

# Verfügbare Log Levels: emerg alert err warning notice info debug
# Schickt Logs in den Freetz syslog (anders als in der default Konfiguration)
        log /dev/log syslog debug

# Schickt Logs auf einen externen syslog, z.B. auf einer Pi
#        log xxx.xxx.xxx.xxx:514  local0 debug

defaults
# use log info from global
    log global

# Test: SSL Termination
#    mode http
# erweitertes Logformat
#       option httplog

# SSL durchreichen
    mode tcp
# erweitertes Logformat
       option tcplog

# timeouts
        timeout connect 10s
        timeout client 30s
        timeout server 30s

# - KAL : keep alive ("option http-keep-alive")
# - TUN: tunnel ("option http-tunnel")
# - SCL: server close ("option http-server-close")
# - CLO: close ("option httpclose")
    option http-server-close

# Frontend für port 180 - http -
frontend http-all
    bind *:180
    mode http
        option httplog

# test auf die domain
    acl host-is-domain1.de       hdr_dom(host) eq domain1.de
    use_backend http.domain1.de if host-is-domain1.de

# test auf die domain
    acl host-is-domain2.de       hdr_dom(host) eq domain2.de
    use_backend http.domain2.de if host-is-domain2.de

# Frontend für port 543 - https / SSL
frontend https-all
        bind *:543
        mode tcp
        option tcplog

        tcp-request inspect-delay 5s
        tcp-request content accept if { req.ssl_hello_type 1 }

# domain1.de use the tls loopback backend if SSL handshake and terminate
        use_backend domain1_tls_loopback if { req.ssl_sni -i domain1.de }
        use_backend domain1_tls_loopback if { req.ssl_sni -i www.domain1.de }

#  domain2.de does not need to use the tls loopback. It does not terminate. Move on directly
        use_backend https.domain2.de if { req.ssl_sni -i domain2.de }
        use_backend https.domain2.de if { req.ssl_sni -i www.domain2.de }
        use_backend https.domain2.de if { req.ssl_sni -i test.domain2.de }

# alle anderen, die nicht terminieren, gehe direkt raus
#        default_backend https.domain2.de

# domain1.de backend proxying connection to TLS front-end
backend domain1_tls_loopback
         mode tcp
         server domain1-loopback-for-tls abns@haproxy-tls send-proxy-v2

# proxy accept loopback - used as TLS termination proxy unencrypting traffic before sending to the main backend
# https domain1.de - hier terminiert
frontend fix_tls
         mode tcp
         log global
         option tcplog
# für domain3.de mehr crt /.. anhängen
         bind abns@haproxy-tls accept-proxy ssl crt /tmp/flash/haproxy/haproxy-domain1.de.pem
         use_backend http.domain1.de if { ssl_fc_sni -i domain1.de }
         use_backend http.domain1.de if { ssl_fc_sni -i www.domain1.de }
#         default_backend http.domain1.de

backend http.domain1.de
        mode http
    server http.fritzbox 127.0.0.1:280 check port 280

backend http.domain2.de
    mode http
        server http.pi1 pi1.domain.de:80 check port 80

backend https.domain2.de
    mode tcp
        log global
        server https.pi1 pi1.domain.de:443 check port 443

Jetzt Freetz zu überreden, mit dem ACME Paket die Zertifizate automatisiert upzudaten, wäre reiner Luxus ;-).
Das ACME braucht das korrekte Datum auf der Box ,
z.B.

date -s 2022.08.22-19:28

Aus diesem Thread https://www.ip-phone-forum.de/threads/lets-encrypt-zertifikat-auf-der-fritzbox.282964/page-2
habe ich in Essenz verstanden
- das ACME Script bzw das Protokoll besteht auf Port 80
- den gibt der ctlmgr aber nicht her
=> keine Lösung, also doch die Zertifikate auf der Pi managen und dann für HAProxy und Apache auf Freetz bringen?

 

[John Paden]

acme.sh muss extern, also am Internetrouter port 80 haben, was man am Kabelrouter ja mit Portforwarding erreichen kann.

Nun läuft alles - bis auf den Apache Bug - wie es soll.

Freetz(-NG) ist einfach super.
Dank an alle die dran gebaut haben und die mir hier geholfen haben.

Case closed.