Da du seit meiner letzten Antwort recht viele Informationen beigetragen hast, wird meine Antwort etwas umfangreicher. Fangen wir also an:
Ich denke das funktioniert mit deaktivierten iptables nicht.
Der Vorschlag ging in die Richtung, dass du iptables erst einmal auf Durchzug bzw. Standardeinstellungen umstellen solltest (sprich: Policies aller Chains auf ACCEPT und alle Regeln rauswerfen). Solltest du davon abhängig sein, dass dein LAN über den Server/Router ins Internet kommt, bitte die Regeln zum MASQUERADING drin lassen oder wieder reinsetzen.
Der Apache läuft auf br0 mit 192.168.0.100 Irgendjemand muß ja den Verkehr von eno2 auf br0 und auch umgekehrt umleiten... Oder liege ich da falsch?!
Der Server ist ein phyischer Host und sowohl die Routing-Funktion als auch der Webserverdienst sollen in dieser phyischen Umgebung laufen, richtig? Wenn du nicht mehrere Netzwerkkarten für z.B. einen simulierten Switch zusammenfasst, ist in dem Szenario eine Netzwerkbrücke (br0 weist auf eine solche hin) nicht notwendig.
Hier nun ein paar Gedanken/Feststellungen, die sich aus meinen allgemeinen Kenntnissen von IPv4-Netzwerken mit Linux-Gateway und deinen Informationen abgeleitet sind:
Dein Server erhält vom Provider eine öffentliche IP-Adresse auf der Modem-Schnittstelle (hier anscheinend eno2)
Dein Server erhält von dir auf der LAN-seitigen Schnittstelle eine IP-Adresse (anscheinend die 192.168.0.100/24)
Die anderen LAN-Teilnehmer erhalten eine IP-Adresse aus dem Netzerk 192.168.0.0/24 und als Standard-Gateway (und vermutlich DNS-Server?) die 192.168.0.100 (vorher 192.168.0.1)
Das Forwarding von Paketen auf dem Server wird aktiviert (bereits erledigt, aber auch gem. sysctl.conf persistiert?)
Konfiguration eines einfachen NAT-Gateways mittels MASQUERADE (sehr empfehlenswert Simple_stateful_firewall)
Was mir in deinen iptables-Regeln aufgefallen ist: Du versuchst mittels DNAT Pakete auf die interne IP-Adresse des Servers umzuschreiben, die über das Modem hereinkommen. Da der Apache auf dem Server selbst die Anfragen beantworten soll, ist das aber gar nicht notwendig. Du musst den Apache an die Schnittstellen/IP-Adressen (oder eben alle) binden, auf denen der Server erreichbar sein soll. Im nächsten Schritt machst du für diese Schnittstellen die Ports 80 und 443 auf - allerdings in der INPUT-Chain, da die Pakete ja direkt an den Server geschickt werden. An diesem Punkt angekommen sollten zumindest alle internen Hosts, die auf den Webserver (192.168.0.100) zugreifen, auch die angebotenen Webseiten sehen können.
Was mich nach wie vor beschäftigt ist die Angelegenheit mit der webbasierten Konfiguration des Modems. Wenn ein von außen kommender Browser tatsächlich immer auf der Webkonfiguration des Modems landet, ist das meiner Meinung nach nicht nur ein kaputtes Design, sondern auch problematisch für die Umsetzung deiner Idee.
Die Hilink-Schnittstelle in Verbindung mit deinem alten Router hat das Modem vermutlich in einen Modus versetzt, in dem es sich "dumm" stellt. Jetzt unter Linux arbeitet es eben mit voller Pracht. Ich habe einen Thread 🇩🇪 gefunden, der mir ganz neue Dimensionen dieser Modems aufzeigen konnte. Leider gab es keine konkreten Hinweise zur Lösung. Schau dennoch mal dort vorbei: Die angeboten ähnlichen Themen klingen so, als könntest du dort auch Hilfe erhalten. Falls du dort einen Thread aufmachst, unbedingt in beiden Foren darauf aufmerksam machen. Crossposting ist insgesamt eher unbeliebt, weil Helfer nicht gern pendeln und dadurch Informationen verloren gehen könne. Ich denke allerdings, wenn du dich hier auf den Server und das Routing konzentrierst und dort auf die Technik/Modemkonfiguration, kann das klappen.
Eine Erkenntnis aus dem verlinkten Thread ist allerdings, dass das Modem selbst wohl als Router mit DHCP-Server auftritt und das Netzwerk 192.168.1.0/24 verteilt. Kannst du das bestätigen? Und wenn ja, wirkt sich das gerade nur auf den Server aus oder auch den Rest des LAN? Kann es sein, dass dein LAN durch den Server genattet wird (*urgs*) und das Modem denkt, es bekommt einfach nur sehr viele Pakete vom Server, die es selbst auch nochmals mittels NAT gegen das öffentliche Netzwerk abgrenzt?
Eine weitere Idee ist, dass du Modem- und LAN-Schnittstelle auf dem Server genau deshalb als Brücke konfiguriert hast: Der Server funktioniert gar nicht richtig als Router, sondern nur als Switch. Haben deine anderen LAN-Teilnehmer IP-Adressen aus dem 192.168.1.0/24 Netz der 192.168.0.0/24?
Ich denke, das ist erstmal genug für diesen Teil des Problems. Jetzt gehe ich mal zu wvdial über. 😉
Die verlinkten Beiträge zur wvdial-Meldung weisen auf eine fehlerhafte wvstreams hin. Coscmic hätte da die gefixte Version.
Ein Möglichkeit wäre, dir hier die Paketquellen des Ubuntu-Pakets zu besorgen, dir vom Debian-Paket den Patch zu beschaffen (vermutlich der hier) und dann nach viel Lesen und Ausprobieren der Doku (Mögliche Startpunkte: dpkg-buildpackage, Debian Anwenderhandbuch 🇩🇪) ein gepatchtes Paket zu kompilieren und installieren.
Da ich sowas noch nicht gemacht habe, kann ich nicht sagen, wie erfolgreich das am Ende sein wird und ob du damit ggf. sogar die Stabilität deines Systems gefährdest. ☹
Ich hoffe, dass wir gerade mit den Erkenntnissen aus den Fragen im ersten Abschnitt voran kommen, denn das mit den selbstgebauten Paketen sieht mir aufgrund des hohen Aufwandes eher nach einer Option für später aus.