Beiträge von eripek

  • DNS-Eintrag ändern schon vor Umzug sinnvoll?

    Worauf ich bei DNS-Umzügen achten würde:

    1. Export meiner Zone beim alten Provider.

    2. Importfunktion beim neuen Registrar.

    3. Eventuell sowieso immer externe Nameserver nehmen (eigene oder Cloudflare)

    4. Vor dem eigentlichen Umzug die TTL der Zone runterschrauben. Normalwert: 1 Woche.

    5. Nameserver-Reload-Times der Registry raussuchen - Änderungen kurz vor dem Reload machen. T-15 bis T-30 Minuten oder so.

    6. Auf DNSSEC aufpassen...

  • Das längste Thema

    Zitat von frank_m

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

    Ich stelle einmal die Behauptung in den Raum, dass es auch dann Sinn macht, wenn die valid_lft (nicht zu verwechseln mit der preferred_lft) einer Adresse zu kurz oder zu lang bemessen ist.

    Angenommen mein WAN fällt (kurz) aus und der Prefix hängt am WAN:

    Im Fall der statischen Konfiguration sehe ich dann im NDP ein neighbor FAILED für den Gateway. Bis sich das erfängt, kann es etwas dauern. Der zugewiesene Prefix ist dann zwar lokal noch verfügbar, solange das interface aktiv ist, was bei einer LAN-Schnittstelle kein Problem darstellt, aber bei non-persistent ppp (pppoe, pptp, ...) schon.

    Lasse ich hingegen RA zu, hänge ich zwar weiter von einer erfolgreichen neighbor solicitation ab, bekomme die (Default-)Routen aber angekündigt, die funktionieren, und zwar dann, wenn NDP erfolgreich war. Habe ich nun den Prefix als Alias eingerichtet und nicht an die Schnittstelle gebunden, ist er stets verfügbar, was bei pfsense/OPNsense mit den Watch-Interfaces sonst auch deren Ausfall bewirkt.

    Zugegeben, die Auswirkungen sind eher minimal, aber das Design gefällt mir schlicht auch besser als die Statik.

    BTW: OPNsense und pfSense implementieren für dieselbe Funktion CARP.

  • Das längste Thema

    Zitat von frank_m

    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?

    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

    pfsense und OPNsense sind meiner Erfahrung nach ein wenig eigen, wenn Du statische Konfigurationen am WAN machst. Im Fall meines DSL-Providers kommt etwa - anders als bei netcup immer ein anderer Gateway zum Zug. Da habe ich mir angewöhnt, dass ich SLAAC fahre, damit das Interface sich einmal stateless konfiguriert und seinen Gateway per RA übernimmt. Den statischen /48er-Präfix trage ich als IP-Alias für WAN oder loopback ein.

    Damit habe ich den Prefix, der mir ja aufs WAN geroutet wird und daher nicht selber nochmal announct werden muss, immer statisch auf der Firewall, während ich bei den Gateways den RAs meines Providers vertrauen kann. Und dabei sollte es völlig egal sein, ob es nun um das mitgelieferte, ein zusätzliches oder ein failover prefix geht, solange ich ein router advertisement hinsichtlich des Gateways bekomme.

    Und die bekomme ich auch laut

    tcpdump -n -i eth0 icmp6

    18:24:58.128083 IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 24

    richtiger wäre aber wohl:

    tcpdump -n -i eth0 icmp6 and ip6[40] == 134

    Yep:

    18:26:22.241816 IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 24

    18:28:21.895010 IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 24


    Wie geschrieben, verwechsle SLAAC und RA nicht mit DHCPv6. SLAAC weist Dir nicht zwangsläufig ein (Host-)Prefix zu, das ist Aufgabe von einem entsprechend konfigurierten RA und/oder DHCPv6. Siehe https://www.networkacademy.io/ccna/ipv6/stat…iguration-slaac

  • Das längste Thema

    Zitat von mainziman

    eripek diese Link-Local-Unicast-Adressen sind Teufelswerk; ^^

    diese fe80::1 default Gateway, welches wir lt. Anleitung auf unseren vServern eintragen,

    ist nicht immer das Selbe; 8o

    des kommt im gesamten netcup-Netzwerk x-fach vor; ich würd fast meinen auf jedem Host einmal; ;)

    Das ist ja die Idee hinter HSRP und VRRP. Und Du verwechselst, denke ich, gerade ::1 (loopback) mit fe80::1 (beliebige linklokale Adresse, nicht EUI64).

    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.

    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.


    BTW: Haben wir mal wieder eine Spam-Welle wegen der Microsoft gehäuft seien S3150-Liebenswürdigkeiten der Geiselhaftnahme auf uns niederlässt?

  • Netcup Domain mit Cloudflare Nameserver macht probleme

    Beachte die Nameserver reload times Deiner jeweiligen TLD-Registry.

    Wenn Du diese Zeiten kennst und die Änderung zeitnah zur Reload Time ausführst, hält sich die Downtime in engen Grenzen.

    Beispiel: .at

    https://www.nic.at/en/how-at-works/faqs?_formID=searchFaqForm&search=reload

    Aha, alle ungeraden Stunden wird die .at Zone neu geladen. Ich mache meine Nameserveränderung um 14:45 Uhr, die Änderung ist 15 Minuten später +/- 5 Minuten erledigt.

    Mache ich die Änderung um 13:24, muss ich bis 15 Uhr mit Problemen rechnen.

  • Das längste Thema

    Zitat von frank_m

    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.

    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.

    Linklokal? fe80::/64

    Wie sonst auch? https://de.wikipedia.org/wiki/IPv6#Link…nicast-Adressen

    Man darf nicht den Fehler machen, zu glauben, dass SLAAC mit DHCPv6 gleichzusetzen wäre. Es genügt ja, wenn NDP funktioniert und router advertisement vorhanden ist. Mit welcher IP der Host dann seine Pakete versendet, bleibt ihm überlassen. Ich kann also mein /64 auf lo setzen und dem WAN-Interface einen (preferred) prefix /128 als IP-Alias geben. Der wird dann auch verwendet, um über einen Router aus fe80::/10 - hier wohl fe80::1 zu routen.

    Was hätte netcup denn getan, um diese hervorragenden Mechanismen zu unterbinden?

  • Das längste Thema

    Zitat von engine

    Mich bringt diese IPv6 Thematik noch um mit der pfsense. Ich habe unter WAN das "originale" Subnet statisch eingetragen, sprich das Subnet was beim Server von Haus aus dabei ist. Gehen wir davon aus es ist 1234:12c0:3:4::/64, als Gateway habe ich fe80::1 gesetzt. Soweit so gut, damit kann ich von der pfsense weg IPv6 Adressen erreichen (über das WAN Interface, logisch)

    Nun zum LAN: Dort habe ich das Zusatz-IPv6 Subnet eingetragen, gehen wir davon aus es ist 4567:12c0:3:4::1/64. Gateway natürlich keines, was aber vermutlich schonmal falsch bzw. unlogisch ist (für mich). Pings schlagen natürlich fehl, weil meiner Meinung nach das Subnet keine Ahnung hat, wohin es soll.

    Ich stehe ehrlich gesagt auf dem Schlauch. Muss man nicht noch irgendwo das Gateway aus dem SCP eintragen?

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

    Und für Forenpostings mit Example-Prefix nimm bitte den documentation prefix: 2001:db8::/32

    Lass ipv6 auf WAN automatisch zuweisen und setz dann den Alias 2001:db8:3:4::/64 für WAN, respektive 2001:db8:3:4::1/128 als IP der Firewall.

    So bekommst Du in der Regel funktionierendes NDP und den Gateway fe80::1 oder was immer es sonst ist, zugewiesen.

  • Das längste Thema

    Zitat von mainziman

    ich hatte mal bei einem Mitbewerber einen vServer, da gabs das 2te /64 zwar kostenlos, man musste aber dennoch alle IPv6-Adressen, welche man davon dahinter verwendete - sprich ich hatte diese zu Hause in Verwendung, sollte ja ein 6in4-Tunnel werden - musste diese allesamt manuell mit ip neigh ... erstellen;

    HÄ?!?

  • Das längste Thema

    Zitat von Borgqueen

    Nach nun ein paar Tage in diesem Forum, was ich suche, ich biete von ehemaligen Angebots-Server betrifft - als befinde ich mich unter der Star-Trek Spezies Ferengi.

    Wer die meisten Server hat ist dann sicherlich der große Nagus der Ferengi. ^^

    Species 180 Ferengi. Profit ist irrelevant. Großer Nagus ist irrelevant. Ihre virtuellen Server werden transferiert werden. Widerstand ist zwecklos.

  • Z-Push

    Dieser Moment, wenn Du als erkennst, dass die Kids von heute einfacher spammen können, als Du um die Jahrtausendwende mit einem kaputten sendmail m4 geschafft hast.

  • Z-Push

    Zitat von CUPPY1089

    Nein, die MX Einträge haben auf Apple und Netcup zugleich gezeigt. Ich habe an den MX Einträgen an der Priorität rumgespielt und da kamen nach entsprechender Veränderung die E-Mails nur bei Netcup oder nur bei Apple an. Das ging relativ schnell (unter 5 Minuten).

    MX-Priorisierung bewirkt nur, dass im Fall, dass ein Server nicht erreichbar wäre, der mit der numerisch höheren Priorität als Fallback benützt wird.

    Dementsprechend nimmt der Server mit der numerisch niedrigeren Priorität die Mails an, wenn er erreichbar ist.

    Gleiche Priorisierung bewirkt einen Round-Robin-Mechanismus. https://de.wikipedia.org/wiki/Lastverteilung_per_DNS