Beiträge von frank_m

    Dabei hatte ich mich auf das zusätzliche Netz bezogen.

    Ach, du hast ein zusätzliches Netz? Das war mir nicht klar. Ich dachte, du arbeitest auf dem mitgelieferten Netz.


    Beim Standardnetz hatte ich keine "anfänglichen Paketverluste" sondern es ging überhaupt nicht.

    Dann war aber noch irgendwas falsch eingerichtet. Denn grundsätzlich funktioniert das, bis auf die Startschwierigkeiten, die man zwar minimieren, aber nicht beseitigen kann.

    Du hast wieder Recht: ich habe das Proxy NDP mal rausgenommen und es funktioniert immer noch

    Wann habe ich das gesagt? Du brauchst einen NDP Proxy, entweder durch ip Einträge, ndppd oder den ndpresponder. Sonst ist nach kurzer Zeit Schluss.

    Wobei ich mich dann frage, warum denn das Standard Netz nicht auch geroutet wird.

    Das ist auch bei anderen Anbietern üblich, und eigentlich auch nicht schlimm. Das Problem sind die anfänglichen Paketverluste. Alles andere kann man lösen.

    Den ndppd verwende ich nicht - ich mache Proxy NDP für jede Adresse einzeln.

    Das ist ok. Nach meinen Erkenntnissen macht es keinen Unterschied, ob man selber Proxy Einträge erzeugt, den ndppd oder den ndpresponder verwendet.

    Mein Routing arbeitet mit einem /96er Netz, das innerhalb des /64er Netzes liegt. Anders geht es nicht, wenn man nur ein /64er Netz hat.

    Ja, das ist grundsätzlich ok. Es funktioniert sogar, wenn man /64 auf dem WAN Interface des Servers aktiv lässt, wobei man dort theoretisch auch mit einem kleineren

    Subnetz arbeiten kann.

    Wichtig ist, dass die Routen zum Interface mit dem /96 Netz stimmen. Hast du das kontrolliert? Und iptables (bzw. vergleichbare Tools) erlauben ebenfalls das Zustellen weitergeleiteter Pakete?

    Was es mit dem "Cache der Infrastruktur" auf sich hat weiß ich nicht. Auf die habe ich ja eh keinen Einfluss.

    Doch, hast du. Siehe den verlinkten Beitrag.

    Eigentlich müsste doch das komplette /64er Netz an meinen Host durchgereicht werden. Oder verstehe ich da etwas falsch?

    Es werden natürlich nur Pakete durchgereicht, für die es ein Neighbor Advertisement gibt. Es gibt keine Gateway Adresse, an die alle Pakete zugestellt werden, wie bei einem gerouteten Subnetz.

    Dann müsste ich doch zumindest mit tcpdump ankommende Pakete sehen.

    Ja, die sieht man auch, wenn alles richtig eingerichtet wird. Aber wie im anderen Beitrag dargestellt: Anfänglich kommt es zu masiven Paketverlusten, wenn du keine Gegenmaßnahmen ergreifst. Hast du das bedacht?

    Was ich aus dem Post, den du geschickt hast herauslese: ist es richitg, das man ein zusätzliches IPv6 Netz buchen muss, damit Proxy NDP funktioniert?

    Nein, wenn du ein zusätzliches IPv6 Netz buchst, dann brauchst du keinen NDP Proxy mehr. Den braucht man nur fürs mitgelieferte Subnetz.

    wieso macht Netcup eigentlich sowas per default und ohne Hinweis?

    Warum hast du beim Installieren des Images nicht einfach angegeben, dass du die ganze Platte nutzen willst? Danach wird man ja gefragt.


    Diesen Hinweis findet man in solchen Foren leider immer. Immer ein bisschen von oben herab formuliert.

    Wir sind halt hier bei Netcup gebrannte Kinder, weil die Netcup Subnetze immer wieder auf Blacklists landen, weil über die Server Schadsoftware verteilt wird. Über die öffentlichen IPs kommt im Schnitt ein Hack-Versuch pro Sekunde rein. Und jemanden, der nicht mal mit den Partitionierungstools umgehen kann, den fragt man schon gar nicht mehr nach iptables ...

    Denk dran: Du wirst vor Gericht landen und zahlst für den Scheiß, den andere mit deinem Server machen. Der Hinweis war kein Scherz.

    Ich nehme mal an, IP-Forwarding, Routing und Firewall hast du entsprechend aufgesetzt? Das würde auch zuverlässig erklären, warum die Pakete nicht ankommen.


    Wenn die Einträge aus dem Cache der Infrastruktur weg sind, kommt es zu Paketverlusten, vor allem am Anfang der eingehenden Verbindungen. Je nach Maßnahmen, die man ergriffen hat, mal mehr und mal weniger:

    IPv6 Paketverlust bei LXC und mitgeliefertem /64 Subnetz - netcup Kundenforum
    Hey netcup-Forum! Ich habe mir vor kurzem LXC (nicht LXD!) auf Debian 10 eingerichtet und wollte nun neben dem IPv4 NAT (lxc-net) jedem Container eine eigene…
    forum.netcup.de

    Bitte mal ins Wiki schauen, die Lösung für dieses Problem wurde da erklärt. Wurde die Installations-CD nach der Treiber-CD wieder eingelegt?


    Bitte beachten: Windows Server direkt am Internet zu betreiben, kann sehr gefährlich sein. Stimmt das Firewall Konzept? Das sollte vor der Installation angepasst werden.

    Is it always the case that Proxmox puts the main LAN port in a bridge (ens3 in vmbr0)? Which ports are additionally in vmbr0? If ens3 is the only port: Why do you need this bridge?


    As far as I remember the main LAN port of the server was active as usual having the public IPs of the server. Additionally, there was one bridge (vmbr0) containing the ports of the containers having a private network for IPv4 as well as for IPv6. Finally, NAT for IPv4 and IPv6 was activated in order to bring the containers on the internet.

    Um die Sache hier zu einem möglichst friedlichen Ende zu bringen: Es hat alles wie vorgesehen funktioniert. Ich hab zwar nach wie vor keine Ahnung, warum das CCP die manuell erstellten Einträge nicht akzeptieren wollte. Aber die bei der automatischen Signierung durch bind9 erstellten Einträge ließen sich auf Anhieb eintragen und nun sind auch alle gängigen DNS Validierer glücklich, inkl. der Überprüfung mit "dig".

    Das DNSSEC bezieht sich auf deine Top-Level-Domain und die Subdomains bzw. alles was darunterliegt, erbt diese Einstellungen.

    Aber nur solange für diese Sub Domain kein eigener Nameserver angegeben wird. Wenn es einen Nameserver gibt, dann muss der auch wieder dnssec lernen.


    Möglicherweise hab ich das Problem nun gelöst. Ich habe noch mal neu angefangen und habe das offizielle Howto der bind Seite befolgt:

    https://bind9.readthedocs.io/en/v9_18_2/dnssec-guide.html


    Da purzelte am Ende ein DS Eintrag heraus, der direkt vom Netcup CCP akzeptiert wurde. Jetzt warte ich darauf, dass der Eintrag exportiert wird, und dann werde ich mal einige der üblich verdächtigen DNS Validierer drauf loslassen.

    Hallo,


    Vorgeschichte:

    Ich betreibe einen eigenen kleinen DNS Server für meine dyndns Hosts. Dafür gibt es eine Subdomain für eine bei netcup registrierte .com domain:

    dyn.example.com


    Die einzelnen Hosts heißen demnach

    hostX.dyn.example.com


    Dafür läuft ein bind9 in einem lxd Container auf einem RS bei netcup, für den eine kleine API exportiert wird, damit die Clients ihre Adressen aktualisieren können. Im CCP bei netcup gibt es einen entsprechenden Nameserver Eintrag:

    dyn NS ddns.example.com (vereinfacht)

    ddns ist der Hostname des DNS Servers (bzw. des entsprechenden lxd Containers). Das funktioniert soweit super und war in den letzten Monaten sehr stabil.


    Vorhaben:

    Das ganze soll nun dnssec lernen. Entsprechend hab ich mir dieses Know-How angesehen:

    https://doku.lrz.de/display/PUBLIC/DNSSEC+mit+BIND+9.9


    Die Vorgehensweise funktioniert augenscheinlich, bis auf ein Problem: Ich kriege den DS Eintrag für den Parent NS nicht ins Netcup CCP. Die dsset Datei wird wie beschrieben erzeugt, da drin ist aber nur ein Eintrag (nur der für RSASHA2):

    dyn.example.com. IN DS 34939 8 2 BEB40DC948274BD637720B77694564B6C785283F1F89C3FF901466A3 B1BB5D25


    Wenn ich nun aber einen DNS Eintrag im Netcup CCP vornehmen möchte, mit Host "dyn", Type "DS" und der Destination "34939 8 2 BEB40DC948274BD637720B77694564B6C785283F1F89C3FF901466A3 B1BB5D25", dann kriege ich einen Fehler:


    Destination des DS-Records falsch


    Was lauft da schief? Fehlt ein Eintrag für RSASHA1? Wird der Algorithmus für .com nicht unterstützt? Oder die Länge von 2048 Bit?

    Hier auf einem RS 2000 G9 und einem RS Ostern M 22 ebenfalls kein Problem.

    umgekehrt erreicht ich vom Heimnetzt bereits das VPN-Gateway.

    Vom gesamten Heimnetz? Oder nur vom VPN Client?



    In einem ersten Schritt möchte ich gerne vom Heimnetz auch den zweiten VPS im Netcup VLAN erreichen

    Siehe mein Bild oben, dafür braucht es eine Route im Heimnetz, eine im VLAN VPS und eine entsprechende VPN Konfiguration.


    Der erste deiner Links funktioniert nicht. NAT kann evtl. die Route im VLAN VPS sparen, aber alles andere muss trotzdem passen.

    Muss ich hier jetzt überhaupt keine Routen setzen, damit mein VPS dem VPN-Gateway sagt, wie es die IP des anderen VPS findet? So verstehe ich deine Erklärung.

    Vorsicht, das kann man so nicht sagen. Einige Routen auf Seiten des VPN Clients braucht man trotzdem noch. Durch die NAT Regeln tauchen die IPs deines VPN Netzes bzw. aus dem Netz des VPN Clients nicht im VLAN des VPS auf. Der antwortet nur auf IP-Anfragen, die er kennt. Für den Zugriff aus dem Netz des VPN Clients auf die Ressourcen im VLAN ist das super. Aber der Rückweg funktioniert dann nicht, damit ist es praktisch keine Site-to-Site Verbindung mehr. Man kann von den VLAN Rechnern nicht auf die Geräte im Netz des VPN Clients zugreifen, weil NAT das verhindert. Dafür müsstest du vollwertig routen, und dann brauchst du wieder Routen auf beiden Seiten, wie oben bereits beschrieben.

    Oben hatte ich ja bereits das Vorhandensein von NAT als mögliche Problemursache beshrieben. Das würde nämlich zuverlässig erklären, warum du von einem Netz aufs andere zugreifen kannst, aber nicht vom anderen aufs eine.


    Ob das Fehlen von PostUp das Problem ist müsste ich doch mittels kurzzeitigen Ausschaltens der Firewall prüfen können?

    Nein, NAT macht mehr. Der ändert Adress- und Portinformationen in den Paketen. Nur durch Ausschalten der Firewall erreichst du kein vergleichbares Verhalten.


    Bevor ich weitermache, würde ich das gerne grundsätzlich verstehen.

    Ja, das würde ich auch empfehlen. Fang oben mit dem Bild an. Was ist daran unklar? Oder was davon entspricht nicht deiner Zielvorstellung?