Wenn ich das richtig interpretiere, kann ich die API sehr wohl mittels Script direkt mit der FritzBox verwenden:
Das "Script" läuft aber nicht auf der Fritzbox, sondern benötigt einen extra Webservice.
Beiträge von frank_m
-
-
Auf der Fritzbox direkt kannst du die netcup API nicht nutzen. Aber vom NAS aus wäre es vermutlich möglich.
Generell ist es natürlich heikel, im eigenen Heimnetz Serverdienste anzubieten, zumal du das Netz mit einer Fritzbox nicht vernünftig trennen kannst (in einen privaten und einen öffentlichen Teil).
-
Ich bin mir nicht sicher, ob du einen Windows Server am Internet betreiben solltest. Weißt du, wie du ihn gegen Angriffe richtig absicherst? Bedenke, dass eine Attacke pro Sekunde (!) auf deinen Server ausgeführt wird, sobald du die öffentliche IP eingegeben hast, und dass es allein im Remote Dektop 300 ungepatchte Sicherheitslücken gibt, die eine sofortige Übernahme des Servers durch Hacker erlauben.
Wenn du einen Windows-Server betreibst, häng einen kleinen Linux Server als Firewall davor. Zugriff auf sensible Windows Dienste dann nur per VPN vom Linux Host aus.
Die IP steht übrigens im SCP.
-
Ist dieses Verhalten so "korrekt", dass der ACME-Client probiert Einträge für die DynDNS-Domain zu ändern, statt für meine?
Ja, ich denke, das ist richtig. Die Zertifikatsprüfung wird später auch auf der dyndns Domain erfolgen, nicht auf der netcup Domain. Wenn du willst, dass die netcup Domain die Basis fürs Zertifikat ist, solltest du da mit A bzw. AAAA Einträgen arbeiten und die IP direkt eintragen. Da du ja die netcup API im Griff hast, sollte das ja möglich sein.
-
Was soll das bringen? Du musst die Konfiguration doch eh an die Serverdienste, Domains, Proxies, VMs, Container ... anpassen.
-
Du musst den SSH Server installieren und entsprechend konfigurieren (zertifikatsbasierte Anmeldung, Portnummer, kein Root Login etc). Dazu brauchst du einen standard Nutzer für den SSH Zugang, um den Root Account zu schützen.
Dann noch fail2ban und die Firewall einrichten. Das musst du bei netcup alles selber machen, da es keine Systemfirewall gibt.
-
Denke daran, Netcup vergibt ein /22 IPv4, also Subnet anpassen.
Nein, das ist abhängig vom jeweiligen Subnetz. Es gibt auch andere Größen als /22. Aber das steht im SCP, ich verstehe überhaupt nicht, warum das eine Frage ist. Die DNS Server stehen auch in der Netcup Doku. Suchdauer: 30 Sekunden. Wartezeit im Forum auf Antworten: > 60 Minuten.
-
Laut Heise war es nach wenigen Monaten der dritthäufigste genutzte DNS record - nach den A und AAAA Einträgen, aber vor MX und TXT.
-
Du kannst bei SSH Servern konfigurieren, auf welchen Schnittstellen oder IPs sie lauschen sollen. Genau da, wo man auch den Port einstellt. Überprüfe mit netstat -tulpen, auf welchen IPs der SSH Server lauscht und korrigiere es bei Bedarf.
-
Ein Ping sagt aber überhaupt nichts darüber aus, ob der SSH Server richtig konfiguriert ist.
-
Die Reihenfolge der Optionen ist wichtig bei scp. Lauscht der ssh Server auf dem VLAN?
-
Dann gib doch den richtigen Port an ... man scp oder scp --help.
-
Wann hast du das letzte Mal den Speicher optimiert? Nach 12 Monaten ohne Optimierung sahen meine Werte auch so aus. Dann einmal trim und direkt danach die Optimierung, und die Werte waren wieder wie am Anfang und wie im Screenshot von tab.
-
Zitat
da auf meinem 3ten vServer das Problem nicht exisitert; habe ich dort mal den tcpdump f. einige Minuten laufen lassen;
4891 Einträge in 6¼ Minuten => rd 13 Einträge pro Sekunde
beim Piko mit diesem Problem 21875 Einträge in 4¼ Minuten => rd. 85 Einträge pro Sekunde
beim RS mit diesem Problem waren es gewaltige 596781 Einträge in 96¾ Minuten => rd. 103 Einträge pro Sekunde
Ich denke, die Anzahl pro Sekunde ergibt sich einfach aus der Anzahl der Maschinen, die in dem Bereich aktiv sind. Ich hab auf meinen drei Maschinen auch erhebliche Unterschiede in der Anzahl dieser Solicitations festgestellt, aber grundsätzlich sind sie auf allen Maschinen da, aber auf der Maschine mit den wenigsten Solicitations ist die Neighbour Table am längsten.
Sollten es nicht auch eher die neighbor advertisements, die die Tabelle füllen?
-
Ich hab exakt diese neighbor solicitations auch im Dump. Sie kommen von Juniper Hardware, also vielleicht von Switches.
Aber bei mir führen sie nicht zum Overflow der Neighbour Table. Vor allem auf meinem Piko hab ich da nur ne Handvoll Einträge, obwohl die solicitations tonnenweise vorbeikommen. Ich bin da auf Standard Einstellungen von Ubuntu und Debian unterwegs. Hast du da was verändert?
-
Das sieht erst mal alles ok aus. Ich bleibe dabei, wir müssen uns den Traffic ansehen. Ich denke immer noch, dass der Traffic nicht da hinfließt, wo er hin soll.
-
Zeig mal mit tcpdump den resultierenden Traffic auf den Systemen (auf allen Interfaces), um exakt nachzuvollziehen, was die clients auf die Reise schicken (und wohin), was beim Server ankommt, was dieser Server als Antwort auf die Reise schickt (und wohin) und was davon beim Client wieder ankommt.
-
Vielleicht die Routen? Wie sieht die gesamte Netzwerkkonfiguration aus auf dem OPNSense System? Von welcher Quell-IP greifst du zu?
-
Das ist das Problem an den Foren in letzter Zeit. Unverständliche, unvorstellbare Broken hinwerfen.
Sie sind nur so lange unverständlich, wie man sich nicht damit befasst.
Bei tailscale und zerotier muss man sich darüber klar sein, dass wertvolle Metadaten auf jeden Fall und ggf. auch Nutzdaten für den Betreiber sichtbar sind. Das muss kein Problem sein, aber man sollte es auf dem Schirm haben. Dann doch lieber eine Portfreigabe und alles selber unter Kontrolle.
-
Naja also ich habe es noch nicht fertig bekommen das man mit der normalen Installationsroutine eine Datei Namens /etc/network/interfaces.d/50-cloud-init.cfg bekommt.
Eben. Deshalb ist es nicht vergleichbar. Genau davon rede ich.
