Beiträge von frank_m

Zitat von Interessent

- soll als DNS Server per (DoT) in der Fritzbox hinterlegt werden,
- Adguard, und nur Adguard soll nur über eine Wireguard Verbindung erreichbar ein, der Rest des Servers normal.

Warum denn DoT UND VPN? Doppelt verschlüsselt hält besser? Wenn du die Erreichbarkeit per VPN einschränkst, reicht auch normales DNS. Sei dir bewusst, dass DoT mit dem nötigen Zertifikatsmanagement nicht leicht wird, wenn der Server nur hinter einem VPN versteckt agieren kann.

Zitat von Interessent

- Wie bringe ich der Fritzbox bei, dass sie dazu eine Wireguard Verbinung zum Adguard Server (dauerhaft) aufrechthalten muss und diese nur für die Adguard DNS Anfragen nutzt, den restlichen Traffic aber nicht über diesen Server schickt.

Das geht hervorragend über die Allowed IPs des Wireguard Tunnels. Da kannst du sehr konkret angeben, dass die Box über VPN nur die Adresse des DNS Servers erreichen darf.

Zitat von Interessent

- Was muss am Server konfiguriert werden, damit Adguard nur auf die Pakete der Fritzbox hört, der rest des Servers aber ganz normal Anfragen annimmt. Geht das überhaupt? Oder denke ich zu quer?

Das wiederum ist einfach. Sowohl ein DNS Server (für unverschlüsseltes DNS) als auch ein vHost auf einem Web-Server (für DoT) können konkret an ein Interface gebunden werden. Aber sei dir bewusst, dass dieses Vorgehen dann zusätzliche Aufwände und öffentlich erreichbare Server benötigt, um die erforderlichen Zertifikate zu erstellen.

Das Zertifikat beinhaltet keine Informationen zur IP, nur zur Domain. IP-Wechsel sind unkritisch.

Arbeitest du nur via IPv4 oder auch mit IPv6? Weil bei IPv6 wird mit dyndns etc. alles anders.

Der "nahtlose" Übergang setzt aber voraus, dass der Content vorher reibungslos umgezogen wurde. Wenn du DNS umsetzt, um dann auf technische Schwierigkeiten zu stoßen, ist das alles andere als nahtlos.

Ich würde erst mal den Content umziehen und durch aufwendige Tests sicherstellen, dass alles reibungslos läuft. Dann kann man den DNS umstellen, und so lange laufen beide Hostings parallel. 48 Stunden später kann man den alten Content dann löschen.

Wenn du die Umstellungszeit verkürzen willst, dann stelle 2 Tage vor dem Umzug die TTL runter.

xaas ist übrigens i_onos und hat mit netcup nicht das geringste zu tun.

Ah, ok. So mach ich das auch für Windows Server. Allerdings mit einer Linux Firewall, nicht mit pfSense. Kommt aber aufs gleiche raus.

Zitat von engine

Konfiguriere ich das Netz statisch über das nicht-VLAN funktioniert alles perfekt, sprich an IPv6 Forwarding kann’s auf der VM nicht liegen, sonst ginge das direkt auch nicht.

Was genau meinst du damit? Nutzt du sonst VLANs?

Zitat von eripek

Im Fall meines DSL-Providers kommt etwa - anders als bei netcup immer ein anderer Gateway zum Zug.

Ok, wenn das Gateway sich ändert, macht das natürlich Sinn.

Zitat von eripek

Und ja frank_m linklokale Adressen werden in der Tat von jedem Gerät (mit dem prefix fe80:/10 und der MAC-Adresse selbst erzeugt, wobei ein paar Füllbits dazukommen, was in einer Adresse in fe80::/64 mündet. Sie sind das IPv6-Äquivalent zu APIPA.

Ja, ich weiß. Ich mach das auch nicht erst seit gestern. Aber

1. was hat das mit der Fragestellung zu tun
2. warum sollte das Einfluss auf SLAAC im Netcup Netz haben?

Zitat von eripek

In den Anleitungen haben wir früher die Variante der statischen Eintragung bevorzugt, weil es offenbar Probleme mit RA, respektive der Neighbor Lifetime gegeben hat. Was da die Ursache war, habe ich mir nicht gemerkt. Jedenfalls kann man SLAAC aber auch feiner granulieren, als es ganz abzuschalten. Duplicate Address Detection (DAD) sollte man jedenfalls drinnen lassen.

Ich werd das auf einem meiner VPS mal wieder testen.

Woraus willst du hinaus? Geht es wirklich noch um die Konfiguration des mitgelieferten /64 auf dem eth0 des VPS? Da kann ich dir versichern: aus der Netcup Infrastruktur kommt diesbezüglich gar nichts. Ich hab kürzlich noch auf einem VPS ein Ubuntu über eine ISO installiert, wo dann die Default Netzwerkkonfiguration auf "Auto" sowohl für IPv4 und IPv6 steht. Eine IPv4 Adresse gibts sofort, bei IPv6 tut sich nichts. Ein tcpdump auf meinem aktuellen VPS zeigt RAs, die aber keine Prefixes verteilen, siehe Screenshot. Ansonsten nur NDP Pakete.

RA.png

Zitat von engine

Jep, allerdings kommen keine Antworten zurück.

Dann ist das das sicherste Zeichen, dass das Forwarding nicht funktioniert. Entweder das IP-Forwarding vom Kernel, oder die Firewall blockt. Da wirst du jetzt ran müssen.

Wie sehen die Regeln denn aus? Am besten low-level auf System-Ebene, nicht in der Oberfläche. Es ist nicht sicher, dass da alles angezeigt wird.

Zitat von engine

Von aussen ist die IP nicht erreichbar (IPv6 Pings sind erlaubt).

IPv6 Forwarding (sysctl) und die Firewall Regeln fürs Forwarding sind die Punkte, die ich prüfen würde. Kannst du die Pings mit tcpdump auf dem WAN Interface sehen?

Zitat von eripek

Es genügt ja, wenn NDP funktioniert und router advertisement vorhanden ist.

Nur gibt es das RA nicht. Oder willst du dir das selber auf deinem Server generieren? Den radvd mit dem statischen Subnetz einrichten, nur damit man das Netzwerk nicht direkt damit einrichten muss? Ist das dein Plan? Was hätte das für einen Vorteil?

Zitat von engine

Wenn ich dann allerdings auf dem LAN interface versuche zu pingen, schlägt der Ping mit 100% Packetloss fehl

Du hast im Ping Befehl das Interface angegeben? Oder die Source Adresse? Beim Interface schlägt es natürlich fehl. Das LAN Interface hat keine Verbindung zum WAN. Wenn du nur die Source Adresse setzt, sähe das anders aus, aber dann würde das Paket trotz der source Adresse über das WAN Interface fließen.

Zitat von engine

Ich kann vom LAN aus nicht mal das Default Gateway pingen O_o

Auch das ist normal, denn das Gateway hängt nicht am LAN Interface, und das LAN Interface hat sein eigenes fe80:: Netz.

Zitat von engine

Pings schlagen natürlich fehl, weil meiner Meinung nach das Subnet keine Ahnung hat, wohin es soll.

Von wo nach wo hast du denn gepingt? Ein Gateway auf dem Router brauchst du nicht für das 2. Subnetz. Der Router hat ein Gateway auf dem WAN, das reicht. Dass er die Pakete fürs 2. Subnetz in sein LAN routen muss, weiß er über die Subnetzmaske.

Zitat von eripek

Stell WAN nicht statisch ein, sondern lass radvd das erledigen. Das statische Netz leg als IP-Alias an.

Wie oben schon beschrieben, das geht nicht bei netcup. Siehe u.a. die Doku zur Einrichtung von IPv6 auf VPS. Es gibt bei netcup aus der Infrastruktur keine Autokonfiguration für IPv6, weder DHCP noch RAs. Auf welchem Prefix sollten sie die auch durch die Gegend schicken? Jeder Server hat ja ein anderes. Es würde helfen, nur dann Tipps zu geben, wenn man weiß, worüber man schreibt.

Zitat von engine

Damit müsste es funktionieren, dass alles über die FW läuft und ich müsste Ruhe haben, wenn ich das richtig verstanden habe?

Ja, das sollte klappen. In der Firewall solltest du dann noch einrichten, was für die WAN Adressen erlaubt ist und was ins LAN weitergeleitet werden soll. Aber das ist natürlich komfortabel möglich auf so einer Router Distribution.

Zitat von perryflynn

Ich hab die neigh Einträge händisch über "ip" gesetzt.

Ja, wie gesagt, macht keinen Unterschied. Ich hab sogar damals noch Dauer-Pings aus den VMs heraus laufen lassen, um NAT, ARP und MAC Tabellen in der Netcup Infrastruktur immer aktuell zu halten. Entspannt die Situation ein wenig, hilft aber nicht vollständig.

Zitat von Valkyrie

Ich stehe gerade auf dem Schlauch. Was meinst du mit original?

Mit "original" meinte ich die ursprüngliche Adresse, die aus dem /64 Prefix des Servers und der EUI-64 Host-ID gebildet wird. Das ist z.B. das Routing Ziel für ein zusätzliches /64 Subnetz.

Zitat von perryflynn

Mich hat das damals nicht gestört, einfach die NDP Einträge händisch zu machen.

Das allein reicht leider nicht. Egal, ob die IPs händisch eingetragen werden oder man einen ndppd benutzt, es kommt trotzdem zu Paketverlusten bei eingehenden Verbindungen. Die Suche nach "ndppd" hier im Forum fördert einige Threads zutage, wo das diskutiert wurde.

Alles das gleiche Problem. Und Stand heute nicht lösbar. Da hilft nur ein zusätzliches (kostenpflichtiges) /64 Subnetz. Das funktioniert dann problemlos.

Zitat von perryflynn

engine Du könntest auch subnetten. Dann brauchst Du kein NAT6 machen.

Da hat man aber bei netcup das NDP Problem, für das es keine befriedigende Lösung gibt. Man muss immer mit Paketverlusten und Delays rechnen für die VMs bzw. das LAN des Routers.

Zitat von engine

Aber dem LAN Interface muss ich dann eine "lokale" IPv6 Adresse geben und diese trage ich dann als Gateway auf ner VM ein, damit die dann über die PFsense rausgeht?

Ja, das würde funktionieren. Musst du der pfSense natürlich NAT6 beibringen. Du kannst auf LAN Seite natürlich auch mit RAs und DHCPv6 arbeiten.

Zitat von engine

Angenommen ich geb der Firewall statisch die netcupaddresse::1/64, dann funktionieren auch die Pings nach aussen von der Pfsense.

Nur als Hinweis, ich würde auf den WAN Interface auch die "originale" Netcup IP aktiv lassen. Sie ist z.B. Ziel für das Routing zusätzlicher Subnetze, und ich könnte mir vorstellen, dass das früher oder später interessant für dich wird. Die ::1 kannst du natürlich hinzufügen, und über die preferred_lft auch gern zur primären Adresse machen.

Zitat von engine

Die vergabe über DHCP sollte dann dennoch gehen, oder bedarf es da weiterer Einstellungen.

Die Vergabe über DHCP geht bei IPv6 natürlich nicht. Da musst du alles von Hand einrichten.

Zitat von CUPPY1089

Na ich bin doch auf Z-Push Version 2.7.0 aber leider funktioniert da wohl SSL nicht. Laut Netcup sollte auch Port 143 (unverschlüsselt) laufen, geht aber nicht. Will man auch nicht.

Also die veralteten Verschlüsselungsprotokolle, die ich oben schon mal ins Spiel brachte. In dem Fall noch mal die dringende Empfehlung, die Finger davon zu lassen. Es gibt einen Grund, warum diese Protokolle von den Mailservern nicht mehr akzeptiert werden.

Zitat von CUPPY1089

Ja, zwischen Akku "ruinieren" oder das Geld für's Hosting der Toilette in Zimmer 111 runterzuspülen.

Du könntest auch einfach darüber nachdenken, einen vernünftigen Mail-Client zu benutzen. Dann wäre beides kein Problem. Scheint mir unter den gegebenen Randbedingungen die mit Abstand sinnvollste Alternative.

Zitat von EduLind

Das komische ist, sobald ich mich über eine Verbindung mit einen öffentlichen VPN Dienst verbinde, es keine Probleme mit dem Verbindungsaufbau via SSH zum Server gibt.

Was schon wieder auf ein IPv4/IPv6 Problem hindeutet ... denn über einen VPN Dienst hast du kein IPv6.