Wenn Glasfaser von der Installation eine zu große Herausforderung wird, könntest du natürlich über Telefonleitungen nachdenken, die du dann "G.hn" Modulen bestückst. Man wird wohl nicht auf 1 GBit/s kommen, aber ich denke, über eine dedizierte Telefonleitung sind mehrere 100 MBit/s recht stabil drin, jedenfalls deutlich stabiler, als über Stromkabel.
Beiträge von frank_m
-
-
Ich habe für deine EInstellung und deine Äußerungen wirklich keinerlei Verständnis. Da muss ich die Anbieter einfach mal in Schutz nehmen.
ann soll der Laden doch erstmal ds fertig machen, was er (die UGG) angefangen hat, statt immer mehr Baustellen aufzumachen, aber nichts wirklich fertig zu stellen? - Was soll das?
Unsinn! Das sind doch vollkommen unterschiedliche Gewerke. Soll der Tiefbautrupp 9 Monate in der Pausenhalle versauern, während man auf die Fertigstellung der Vermittlungstechnik eines Ausbaugebietes wartet? Nein, natürlich ziehen die schon ins nächste Gebiet. Und Planung und Antragsverfahren laufen schon fürs übernächste. Also da ist deine Vorstellung von der Vorgehensweise einfach nur naiv. Sorry, anders kann man es nicht sagen.
Man könnte das auch in Nachhinein klären, aber so läuft die UGG, bzw die Porenziellen-Neukunden sehenden Auges im schlimmsten Fall in eine Unterversorgung (alter Anbieter weg, da gekündigt - Glasfaser aber noch nicht da.)
NEIN! Einen Tarifwechsel macht man AUF JEDEN FALL so, dass man den neuen Anbieter beauftragt und ihn die Kündigung beim alten Anbieter machen lässt. Sonst funktioniert die Rufnummernportierung möglicherweise nicht, und auch die Übergabe nicht. Das steht so in jedem Ratgeber, und auch bei der BNetzA. NIEMALS selber kündigen!!!
Es ist kein Wunder, dass ihr unzufrieden seid, wenn ihr mit so merkwürdigen Vorstellungen und Annahmen an die Sache herangeht.
-
Der Stern ist dazu da, die IP-Adresse und den Port des Verbindungsursprungs nicht einzuschränken
Ja, aber seine Eingabe wird standardmäßig von der Adressvalidierung des Webfrontends abgelehnt, zumindest bei IPv6. Warum also nicht mal eine gültige IPv6 Adresse probieren? ::0/0 oder sowas? Oder meinetwegen auch ausgeschrieben.
Und bei den Ports wird die Eingabe augenscheinlich durch eine "0" ersetzt, was zumindest bedenklich stimmt. Wenn das 1:1 an die Generierung der Regel übergeben wird, dann kann da sonstwas rauskommen, weil ein angeforderter Port "0" durchaus zu einem ein zufällig zugewiesenen Port führen kann - je nach Implementierung.
Wie sicher sind wir uns denn, dass die in der GUI eingegebenen Regeln zu dem passen, was dann im System erzeugt wird?
-
Warum macht ihr eigentlich diese Klimmzüge mit der Eingabe auf der Konsole, um ein "*" eingeben zu können? Gebt doch einfach eine gültige IPv6 Adresse ein, um das Ziel zu beschreiben. Ggf. kommt die Firewall damit besser zurecht, wenn sie auf Regeln stößt, die auch ihren Vorgaben entsprechen.
-
Die Frage: warum bekomme ich an meinen Clients das Gateway nicht automatisch zugewiesen?
Wie hast du die Router Advertisements konfiguriert? Die sind dafür verantwortlich, das Gateway zu verteilen. Das muss nicht zwangsläufig eine öffentliche IP sein, Fritzboxen z.B. verteilen ihre link-lokale Adresse als Gateway.
-
es sieht ja wohl so aus denke ich, als ob das dg netz den dg router nach ablauf kurzer zeit nicht mehr versorgt.
Danach sieht das für mich überhaupt nicht aus. Ich würde sagen, dass die connection tracking Tabelle Zeit ihre Gültigkeit verliert. Das erklärt die temporären Einflüsse, die du siehst, am besten. Da ihr durch Manipulation Einträge erzeugt habt, die die GUI eigentlich nicht zulassen will, kam mir der Verdacht, dass es daran liegen könnte. Deshalb der Versuch ohne Regeln.
-
Warum macht der Laden (die UGG) dann Versprechnungen, die nicht zu halten sind
Weil die das zu dem Zeitpunkt selber noch geglaubt haben. Die dramatische Entwicklung der letzten Monate in der Versorgung mit Rohstoffen und Elektronik konnte niemand voraussehen. Du erwartest morgen eine Lieferung und bekommst heute die Nachricht, dass nur die Hälfte kommt - oder auch gar nichts.
Und jetzt schenkt euch die UGG reinen Wein ein, und was ist die Konsequenz? Eben. Und wie wäre sie gewesen, wenn sie das früher getan hätten? Genau so. Ich kann den Frust verstehen, aber mit der Situation kann man nur konstruktiv vorgehen. Die sind bei der UGG auch frustriert. Dein Verhalten bescheunigt gar nichts, eher im Gegenteil. Da sollte man sich als Kunde fragen, was man will: Meckern oder schnellstmöglich einen Glasfaseranschluss. Das schließt sich schnell mal gegenseitig aus.
-
Was mich wundert ist, dass die Portnummern bei ICMP Freigaben angeben kannst. Das passt nicht zusammen.
Funktionieren die ausgehenden Pings ohne Firewall-Regeln?
-
Ich installiere zwei WG Clients, einer auf dem Handy, einer auf dem RP im Heimnetz.
Bei WG gibt es diese strikte Trennung in Server und Client nicht. Es gibt zwei Knoten, die miteinander kommunizieren können. Je nach Konfiguration kann es dann auch Knoten geben, die Datenverkehr zwischen anderen Knoten weiterleiten.
Ich installiere einen WG Server auf dem VPS und das nicht unter root
Doch, unter root. Alles andere funktioniert nicht.
und wie schließe ich den SSH zugang?!
Hoffentlich gar nicht. Sicher ihn ab, verlege ihn auf einen zufälligen Port, aber deaktiviere ihn niemals. Er kann im Zweifel die letzte Möglichkeit sein, den VPN Tunnel wieder zum Leben zu erwecken.
Ich denke ich würde hier auf einen Strato Server im Moment mit für 5 Euro setzen... der hat auch PLESK
Der Server ist ungeeignet.
Man kommt deutlich günstiger an hinreichende Produkte, bei 1&1 oder netcup zum Beispiel. Wichtig ist: Du brauchst echten root Zugang mit der Möglichkeit, Kernelmodule zu kompilieren. Sonst läuft wireguard nicht vernünftig. Achte also auf Begriffe wie "KVM Virtualisierung", das ist gut. Schlecht sind hingegen Technologien wie "Virtouzzo" oder "OpenVZ". Letztere werden häufig zusammen mit Plesk angeboten und kommen auch auf deinem verlinkten Produkt zum Einsatz.
Aber wie sage ich dem Server das er quasi durchrouten soll?!
Er muss IP forwarding aktiviert haben, ggf. für IPv4 und IPv6, falls du beides nutzen willst. Außerdem müssen die Firewall Regeln ggf. entsprechend ausgelegt werden.
Auf dem RP Client muss ich dann noch wie bei Tailscale das interne Netzwerk freigeben
Wenn du es selber einrichtest, musst du auf dem VPS und dem Handy dafür sorgen, dass sie das Netz finden, aber nicht auf dem Raspi. Der Raspi muss ähnlich wie der VPS IP Forwarding machen, da er zum Router wird. Das muss er jetzt für Tailscale auch schon.
Bei Tailscale kann man einfach den DNS der Frizbox angeben und dann lüppt das für alle Clients...
Einen DNS Server kannst du auch bei wireguard direkt mitkonfigurieren. Aber sei dir bewusst, dass das dann für alle DNS Anfragen gilt, und damit ggf. "normale" Internetverbindungen zeitlich negativ beeinflusst, weil die DNS Auflösung länger dauert (sie muss ja durch den Tunnel). Das ist bei Tailscale übrigens auch so.
Was brauch ich noch?!!!
Im Heimnetz müssen die Clients wissen, dass das VPN Netz auf dem Raspi erreichbar ist. Tailscale scheint mit NAT zu arbeiten, weil das offenbar "einfach so" funktioniert. Darum musst du dich bei wireguard selber kümmern.
-
Ja, die Beschreibung bestätigt im Grunde meine schlimmsten Befürchtungen. Es sind genau die sensiblen Informationen, die zum Verbindungsaufbau nötig sind, die bei denen hinterlegt sind. Da wage ich in aller Form zu bezweifeln, dass ein offener IPv6 Port im Heimnetz das größere Sicherheitsrisiko ist.
Since users do not have a separate Tailscale account, there is no way for it to be hacked, adding an extra layer of security.
Ah, ok, der Account kommt über Google, also kann man ihn nicht hacken. Der Schluss ist ... mutig. Vielleicht kann der individuelle Account bei denen nicht direkt gehackt werden, aber dann arbeiten sie mit SSO Methoden und Authentifizierungstoken. SSO ist komfortabel für den Benutzer, weil er sich nur einmal Zugangsdaten merken muss. Ein zusätzliches Sicherheitsmerkmal ist es nur bedingt. Auch ein Server, in den man sich per SSO einloggt, kann unsicher sein, und damit können sensible Nutzerinformationen im Falle einer Attacke abfließen.
Also durch das Doppelte NATen bei eiem DG-Anschluss, also einmal die öffentliche IP der DG ins DG Netzwerk und dann nochmal das NATen ins Heimnetz über die Fritzbox... sollte das Endgerät nicht scanbar sein... und damit auch nicht anfällig auf Attacken...
Du vergisst IPv6, da ist nichts mit NAT. Aber auch da hilft eine geeignete Firewall. Das ist verhältnismäßig einfach, und vor allem: Du hast es selbst in der Hand.
Wie gesagt, ich starte einen Client auf dem Raspi und keinen Server und da ich auch kein Port-Freigegeben habe kann man da auch nix scannen...
Wenn die Verbindung Peer-to-Peer abläuft, dann ist einer von beiden ein Server und öffnet auch einen Port. Auch wenn die Ports natürlich nur temporär offen sind, und möglicherweise auch nur für das jeweilige Gegenüber. Was mir da eher zu denken gibt, sind diese "DERPs". Die haben ggf. permanent Zugriff auf dein Netz, je nachdem, wohin deine Clients ihre Verbindung aufbauen.
Ich will tailscail hier nicht unnötig runter machen. Es ist unglaublich komfortabel, und ich denke auch, dass die alles dafür tun, dass die Kundendaten sicher sind. Ebenfalls werden die nicht unnötig auf Kundenendgeräte zugreifen oder Daten abfließen lassen. Andernfalls wären die schneller vom Markt verschwunden, als man "Piep" sagen kann.
Man wird das Produkt sicher nutzen können. Aber wenn es eine harte Securitiy Analyse gibt und Sicherheit ein hohes Ziel ist, dann ist tailscail raus. Da ist eine eigene Lösung ohne Cloud Einbindung garantiert sicherer.
-
Ums ganz deutlich zu sagen: Ich halte die Konfiguration an mehreren Stellen für kompletten Unsinn und bin sicher, dass man sie anders eingerichtet auch zum Laufen bekommt, und dann auch so, wie von der DG vorgesehen. Das oben beschriebene ist definitiv nicht deren angedachter Weg.
-
Die Kommunikation läuft nicht direkt und nicht über deren Server.
Das verstehe ich nicht. Wenn sie nicht direkt läuft und nicht über deren Server, woher läuft sie denn dann?
Ich vermute, die Nutzdaten werden direkt übertragen, aber die Vermittlung läuft sehr wohl über deren Server. Heißt: Die verschlüsselten Nutzdaten laufen direkt, während die sensiblen Infos über offene Ports, IP-Adressen und Zugangsinformationen bei denen bekannt sind. Ich kenne das Produkt nicht, aber so sieht es von außen aus.
Was die generelle Bedrohungslage angeht: Da dein VPS eine öffentliche IPv4 hat, ist er natürlich deutlich exponierter Im Netz, als dein heimischer Internetanschluss, der lediglich über eine öffentliche IPv6 verfügt. Auf meinem VPS kann ich auf IPv4 ca. 50 - 100x so viele Portscans und PHP Attacken sehen, als auf IPv6. Irgendwo muss der ServerPort für die Verbindung ja offen sein: Entweder auf deinem VPS oder im Heimnetz. Und du musst bedenken: Wenn der Hacker auf dem VPS ist, ist er in deinem Heimnetz, die haben eine uneingeschränkte VPN Verbindung.
Also wenn größtmögliche Sicherheit das Ziel ist, dann sollte die Umsetzung ohne VPS erfolgen. Allerdings ist die Umsetzung mit einem VPS natürlich deutlich komfortabler, spätestens dann, wenn mehr als ein Netz erreicht werden soll (deshalb mache ich es auch so). Aber man sollte sich der Risiken bewusst sein. Das heißt, dass man vor allem sehr genau weiß, wie man einen VPS von außen zuverlässig verriegelt.
-
Ich glaube, es ist wirklich an der Zeit, dich ein wenig mit den Wireguard Grundlagen zu beschäftigen.
Wireguard bietet zwar einen Modus für Clients hinter NAT Routern ("PersistentKeepalive"), aber das ist im Grunde eine Vergewaltigung des Protokolls. Standardmäßig arbeitet das stateless bi-direktional, sprich: beiden Knoten können sich gegenseitig jederzeit erreichen, ohne das irgendwelche Ports in Firewalls mit Gewalt alle paar Sekunden offengehalten werden. Mit IPv6 an einem Glasfaseranschluss lässt sich das problemlos realisieren, und das würde ich auch massiv empfehlen.
Um dich in deinem Heimnetzwerk uneingeschränkt bewegen zu können, muss das Routing natürlich passen. Dazu gehört als erster Schritt ein geeignetes Setup der jeweiligen IP-Adressen der VPN Knoten als auch das korrekte Einrichten der allowedIPs. Im zweiten Schritt musst du dann dafür sorgen, dass alle Endgeräte in deinem Heimnetz den Weg ins VPN finden, da dein VPN Gateway ja auch nicht auf deinem Default-Gateway untergebracht ist. Sprich: Du brauchst eine statische Route in jedem einzelnen Endgerät, oder eine im Internetrouter fürs gesamte Netz. Details können wir gern auseinander dividieren, wenn du genauer beschreibst, wie das Setup aussieht, dass dir zu Haue zur Verfügung steht. Die bestmögliche Einrichtung hängt ein wenig von den Geräten ab, die es gibt.
-
Trotzdem frag ich mich dann aber, wie kriegt das Handy direkt zugriff auf die Wireguard-Server in meinem Heimnetz?!
Für die entsprechenden Portfreigaben im Router musst du natürlich sorgen. Aber das musst du auch, wenn du den Server auf einem VPS betreibst. Wireguard benötigt Portfreigaben auf Server und Client wenn kein NAT im Spiel ist (ist jedenfalls dringend zu empfehlen).
-
Ja. Aber wenn es ausschließlich um die Verbindung vom Handy geht, brauchst du den VPS vermutlich nicht, denn die Mobilfunkprovider in Deutschland bieten inzwischen alle eine IPv6 Adresse.
-
atari: Musstest du was besonderes einstellen, damit Router Advertisements akzeptiert werden?
-
Ja, bis auf die unterschiedlichen Adressen sieht das exakt so aus, wie bei mir.
Ich bin bei @alfalfa: Das Router Advertisement wird gar nicht ausgewertet. Weder die Adresse noch die MTU der Route passen. Möglicherweise sind das Überbleibsel einer vorherigen statischen Konfiguration? Auf jeden Fall solltest du bei der Behandlung und Auswertung der RAs ansetzen.
-
Kundendienst ist gut wenn er mir dabei hilft zu bekommen was ich will und worauf ich sowieso Anspruch habe, nicht wenn er meint mich belehren oder mir anderweitig "helfen" zu sollen, dass ich doch einfach was anderes tun soll.
Solange es nur darum geht, das zu bekommen, worauf du Anspruch hast, ist das ok. Aber wenn du dich beim Support beklagst, dass du deine Dachpfannen nicht aufhängen kannst, und der stellt fest, dass du noch nicht mal ein Fundament für ein Haus gegossen hast, was soll er dann machen? Da bleibt dann nur ein "belehren" und "was anderes tun". Ungefähr so stellt sich das in diesem Fall dar.
-
Kurzer Prozess: niemand muss sich dafür rechtfertigen warum er was wie macht oder machen will
Richtig. Nur darf er sich dann auch nicht wundern, wenn es nicht funktioniert.
auch Kundendienst von Unternehmen kann sowas aber gut, also auf "Ich hätte gerne.." mit "Wozu?" oder "Machen Sie doch lieber.." zu reagieren.
Wenn das "Ich hätte gern ..." nicht funktioniert und hinter dem "Machen Sie doch lieber ..." die Lösung kommt, dann hat der Kundendienst seine Aufgabe erfüllt.
Wenn dir gemäß Schnittstellenbeschreibung und Leistungsbeschreibung etwas zusteht das du nicht erhälst
Und da ist der Hund begraben. Das ist hier offensichtlich nicht der Fall.
-
Und Leider hat mir die Deutsche Glasfaser besagte Informationen zur korrekten Konfiguration nach mittlerweile 4 Wochen immer noch nicht mitgeteilt.
Wie ich schon sagte: Wer den Pfad der Tugend verlässt, der muss sich selber zurecht finden. Es gab schon einen Grund, warum sich die Internetprovider damals mit Händen und Füßen gegen die freie Routerwahl gestemmt haben ...
Nur zur Info: Beim kundeneigenen Router endet die Verantwortung von DG am NT. Alles, was danach kommt, ist dein Problem. Was du zu erwarten hast, steht in der Schnittstellenbeschreibung. Darüber hinaus gibt es einige exemplarische Anleitungen für ausgesuchte Router. Da hilft auch kein Vorstand oder eine BNetzA.
Zu den Routen: Wie @alfalfa schon ausgeführt hat: Das Defaultgateway kommt über die RAs. Dabei wird keine IP-Adresse übermittelt, sondern lediglich eine MAC Adresse. Die Quell-Adresse der Pakete vom Defaultgateway ist eine link-lokale fe80:: Adresse. In der DHCPv6 Nachricht ist kein Gateway, und das ist schon seit Ewigkeiten so, siehe hier:
Erfahrungen gesucht mit Draytek VIGOR 28xx Router an DG Anschluss IPv6
