Posts by rpi444

    Das man im Terminal vom RaspAP /RPi4) das logging sieht, das der Client mit dem RaspAP IP verbunden ist und mir den traffic anzeigt was abgerufen/bzw. gesendet wird.

    Wenn nicht DoT oder DoH benutzt wird, versuch mal mit:

    Code
    sudo tcpdump -c 700 -vvveni eth0 port 53

    EDIT:

    Was Du auch probieren kannst, ist dnstop:

    Code
    apt policy dnstop
    Display Spoiler

    Per Terminal ssh auf 192.168.42.1 kam ich auch beim !!! 1.mal die Möglichkeit angezeigt diverse Daten einstellen zu können. Dann funktionierte auf meinem alten Apple iMac mit OS 10.12.6

    sogar der Zugriff aufs Internet.

    Nachdem ich nun aber nach ein paar Tagen wieder auf die Torbox via ssh zugreifen wollte, bekomme ich aber keine Verbindung mehr. Über Firefox klappt der Zugriff ebenfalls nicht mehr (bei Safari wurde der Port 22 geblockt und bei Firefox konnte ich ihn zwar freigeben,aber gebracht hat es auch nichts. .

    Wie sind die Ausgaben von:

    Code
    arp -a
    ping -c 3 192.168.42.1
    nc -zv 192.168.42.1 22

    (oder gleichwertig)?

    ..., wäre mir eine grafische Oberfläche ganz lieb. Gibt es sowas für den headless-Betrieb?

    Nein, das gibt es nicht. Wenn dein Server richtig konfiguriert ist, brauchst Du keine iptables-Firewall (oder gleichwertig).

    iptables wird evtl. für destination-NAT, source-NAT (MASQUERADE) und gleichwertig benötigt. Diese Regeln werden dann entweder via systemd-networkd oder manuell (Kommandozeile, Texteditor) mit netfilter-persistent gesetzt bzw. benutzt.

    Das geht auch erst einmal prima, nur sind die Einträge nach einiger Zeit wieder weg und ich muß sie neu erstellen.
    Woran liegt das? Doch nicht an dem TTL, oder?

    Hast Du evtl. feststellen können, wann (bzw. nach welcher Zeit) die Einträge weg sind?

    Die TTL kann evtl. nur indirekt Einfluss auf diese Zeit haben, denn die TTL sagt dem Anfragenden nur für welche Zeitdauer dieser record gültig ist. D. h. vor dem Ablauf der TTL kann der lokale dns-cache gefragt/benutzt werden und nach dem Ablauf der TTL muss erneut der DNS-Server (hier die FritzBox) gefragt werden.

    Test: Benutze eine TTL von 5 Tagen und mach nach 4 Tagen und 22 Stunden (nach der Registrierung) eine dns-Anfrage (per cronjob oder gleichwertig) an die FritzBox.

    EDIT:

    Es kann aber auch sein, dass die FritzBox die TTL die Du mit nsupdate setzen willst, ignoriert und immer ihre eigenen TTLs (für statisch, dhcp, ...) benutzt.

    Testen sollte mit:

    Code
    dig +ttlid +ttlunits web.raspberrypi.fritz.box

    möglich sein. Du könntest aber auch einen cronjob oder eine service-unit/timer-unit für die regelmäßige/erneute/rechtzeitige (Re)Registrierung benutzen. Es muss nicht interaktiv (in der Kommandozeile) gemacht werden, d. h. es geht auch mit einer Datei (mit der richtigen Syntax):

    Code
    nsupdate   [filename]

    ... ein einfacher Reboot hat das Zeitproblem gestern auch nicht behoben, das Datum blieb in der Vergangenheit.

    OK.

    Für den Fall, dass Du sntp mal testen willst, hier die service-unit die ich benutze:

    (eth0 evtl. anpassen und die IP-Adresse für den lokalen Zeitserver auch anpassen).

    Testen im Vorfeld auf Eignung, mit:

    Code
    sudo sntp --kod=/dev/null <IP-Adresse-lokaler-Zeitserver>

    Siehe auch die manpage für sntp.

    Schlussfolgernd könnte es also gestern der Fall gewesen sein dass die Raspis den Debian Zeitserver nicht erreicht haben?

    Ja.

    BTW: Haben die (vielen) PIs in deinem Heimnetz, verschiedene hostname und user-Namen?

    Du musst das ja auch nicht über .profile und .xinitrc starten, oder? Es sollte doch auch etwas später möglich sein (+desktop-Datei, oder service-unit/timer-unit, ...)?
    Könntest ja an einem PI was probieren/experimentieren.

    Ja, im Netzwerk fungiert ein Windows Domain Controller (DC) Server als Zeitserver.

    Teste mal ob der PI Zugang zu diesem Zeitserver hat und wenn ja, wie bzw. ob er mit rdate die Zeit/Datum von diesem Zeitserver holen kann.
    Z. Zt. benutzt systemd-timesyncd die hardcodierten Zeitserver (von debian) und ist somit auch auf eine funktionierende Namensauflösung (DNS) zum Zeitpunkt der Syncronization angewiesen. In die config kannst Du aber die IP-Adressen von Zeitserver eintragen und Du kannst auch Zeitserver für fallback dort eintragen.

    Die Zeitverzögerung alleine wird nichts bringen, denn auch nach längerer wartetzeit war noch das falsche Datum gesetzt. Und zwar solange bis ich das Overlay Filesystem deaktiviert und den Rapsberry neu gestartet habe - erst dann wurde das heutige Datum gesetzt.

    Dann mach mal folgenden Test:

    Installiere rdate, boote nach 5 Minuten mit readonly und führe aus bzw. poste hier die Ausgaben von:

    Code
    date && rdate -4npu 156.106.214.52
    sudo rdate -4nu 156.106.214.52
    date && rdate -4npu 156.106.214.52

    Ausgabe der 3 Befehle:

    Code
    Feb 16 11:41:58 raspberrypi systemd-timesyncd[438]: Initial synchronization to time server 156.106.214.52:123 (2.debian.pool.ntp.org).


    Ich könnte mir nun aber vorstellen, dass ich einfach den von dir genannten Befehl beim Aufstarten ausführe - systemctl status systemd-timesyncd

    und anschliessend (hoffentlich) immer die korrekte Zeit gesetzt ist.

    Nein, das bringt nichts. Ich wollte nur wissen ob Du systemd-timesyncd benutzt.

    In welchem Zeitabstand nach dem booten, wird der chromium-browser gestartet und wie wird der chromium-browser gestartet? ... manuell oder ... ?

    EDIT:

    Wenn es nicht so schnell gehen muss mit dem Browser, kannst Du systemd-time-wait-sync.service als Abhängigkeit benutzen und wenn es schnell gehen muss, dann kannst Du sntp oder ntpdate oder rdate oder gleichwertig benutzen, aber der Browser muss _immer_ warten bis die Zeit/Datum durch einen dieser Dienste gesetzt ist.