ich bin bei Connect nicht 100% von deren Neutralität überzeugt
Solche Aussagen sind halt ein klares Indiz einer Verschwörungserzählung.
Gleich noch Accenture/Umlaut mit in den Verdacht gezogen.
ich bin bei Connect nicht 100% von deren Neutralität überzeugt
Solche Aussagen sind halt ein klares Indiz einer Verschwörungserzählung.
Gleich noch Accenture/Umlaut mit in den Verdacht gezogen.
Schöne Verschwörungserzählungen. 🤣
Das ist aus meiner Sicht genau die richtige Einstellung. Zumindest wenn man derzeit SV-VDSL oder Kabel Internet hat. Damit kommt man heute ja in den allermeisten Szenarien auch noch sehr gut zurecht. Ich bin immer überrascht, wenn Leute ihren FTTH Vertrag wieder kündigen wollen, weil der Ausbau nicht schnell genug kommt. Entscheiden sich im ersten Schritt für FTTH und verzichten dann auf einmal gänzlich. Crazy.
Die sind genau in dieser komfortablen Situation und haben oft auf den Anbieter keine Lust mehr. Ist dann deren Option zu zeigen, dass sie weiterhin das Sagen haben und wollen ihre Ruhe haben.
Ich kann auch entspannt warten, da anderweitig gut versorgt.
Aber die Unfähigkeit, über ihre Arbeit und den Fortschritt zu berichten, lässt mich auch ein wenig skeptisch werden, wie das Netz unseres kleinen Anbieters einmal laufen wird.
AON ist sehr oft mit aktiver Technik im Feld realisiert. Daher kann eine PON-Topologie Kostenvorteile ausspielen. Nur passive nahezu wartungsfreie Installationen.
Spätestens bei SDN wie NSX ist diese Art der Diskussion doch recht müßig.
Man muss beim ISP nachfragen wegen einer öffentlichen (meist dynamischen) IPv4 Adresse. Der ISP ist dazu verpflichtet (laut EU Verordnung bzw. RTR Bescheid) eine öffentlich IPv4 GRATIS zur Verfügung zu stellen.
Wohnst du denn in Österreich? Das würde es anderen Lesern ermöglichen, das einzuschätzen.
Abgesehen davon, dass ich die Interpretation der RTR für durchaus fragwürdig halte.
Zweiteres richtet sich ebenfalls an die WAN-Adresse?
Permission Denied ist aber kein Routing Fehler, sondern kommt vom Server, also von der Fritzbox.
Deswegen bin ich ja gerade skeptisch, ob nicht doch die FB hier was hat.
Bei einer von zwei bekomme ich keine Verbindung hin.
Die Funktion habe ich bisher nie in Anspruch genommen, aber ich finde aktuell keinen Anhaltspunkt, warum das auf der Fritzbox meines Bruders nicht funktionieren sollte.
Wenn ich die Option "Internetzugriff auf die FRITZ!Box über HTTPS aktiviert" setze, kann ich trotzdem keine Verbindung zu weder der öffentlichen IPv4- noch der IPv6-Adresse herstellen. VPN habe ich jetzt aus Bequemlichkeit nicht getestet.
Der Verbindungsaufbau zum angegeben Port schlägt mit einem "Permission denied" fehl. Der Name wird bei myfritz.net mit den richtigen Records gefüllt.
Keine Idee, ob das mit meinen Versuchen, eine Portfreigabe für die LAN-seitige Adresse der FB zu setzen, zusammenhängt. Ich habe gerade aber auch keine Muße, die FB aus der Ferne zurückzusetzen und meinen Bruder anzuleiten, die Verbindung wieder herzustellen.
Meine eigene FB (anderes Modell, aber auch FritzOS 8.00), die selbst nur Client hinter dem OpenWRT-Router ist, kann ich von einem dritten Anschluss aus erreichen, nachdem ich das WebUI freigegben habe und die FB einen Port gewürfelt hat. Den musste ich zwar in der FW des OpenWRT-Routers freischalten, aber das hat ja mit dem Problem nichts zu tun.
Was ich auf Verdacht hin machen würde: Die FB bei den betroffenen Nutzern zurücksetzen und vergleichen.
Wobei ich adhoc HTTPS als schnellen Test bei meinem Bruder über die WAN-Adresse nach Setzen des Hakens auch nicht erreichen kann.
Muss ich mir gleich mal genauer anschauen.
Also die mit 7380 im dritten Block?
Hast du mal versucht, den Zugriff über HTTPS zuzulassen?
Diese Adresse kannst du nicht pingen und es kommt auch kein Tunnel zustande, korrekt?
Dann waere es einen Versuch wert mal zu sehen ob der OP fuer diese LAN seitige GUA der Fritzbox eine Firewallregel bauen kann...
Ich habe es auf der FB meines Bruders probiert.
Man kann die Regel erstellen, sie bleibt aber wirkungslos. Ich vermute, da ist ein Reject (oder Drop?) mit höherer Priorität, bevor diese Regel greifen würde.
In den Unübersicht (
) fehlt mir die Info, mit welcher Adresse du die Box adressierst, DrFroeschle . Über die IP direkt oder über myfritz? Welche Adresse ist dort registriert?
Aber registriert der AVM-Service nicht die WAN-seitige Adresse unter myfritz.irgendwas?
Vielleicht sollte man dieses Bridgekonstrukt tatsächlich mal entfernen, um es als Fehlerursache auszuschließen.
Wie ich ihn verstanden habe, war die Bridge nur temporär drin.
Ich sehe nicht, wie das eine Rolle spielen soll, denn Bridges sind unter Linux Dekaden alt.
Aber an dieser Stelle würde ich auch Try/Error machen, siehe vorherigen Post.
Was ich noch testen würde: Setze bei deinem Server im LAN die IP mal bewusst auf eine EUI-64 mit einer getürkten AVM-MAC.
Das war auch mein Gedanke.
Ich hätte verstanden, dass das WAN-Prefixes ohne dazu gehörige Verbindung droppt, aber nicht beim delegierten Prefix.
Andererseits bleibt es bei der Beobachtung, dass das Paket die Fritzbox wieder verlässt.
Aber gut, ich habe keine Einblicke in das Innenleben eines ISPs - falls du oder sonst jemand da Erfahrungswerte liefern kann, gerne mehr.
kingpin42 ist im Netzbetrieb tätig. Zwar nicht bei DG, aber vielleicht kann er sich einen Reim machen.
Aber was ist, wenn du vom VPS diese LAN-Adresse statt der im WAN pingst?
Bzw. die Adresse müsstest du für ICMP vermutlich noch freigeben.
Wir nutzen Cookies und ähnliche Technologien für den Betrieb der Seite, Reichweitenmessung und Werbung. Du entscheidest, was Du erlaubst. Details in unserer Datenschutzerklärung. Deine Auswahl kannst Du jederzeit über den Link „Cookie-Einstellungen“ im Fußbereich ändern.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum