Das längste Thema

    Zitat von Gunah

    Oder halt VLAN Only, sodass die Server untereinander erreichbar wäre?

    Würde auch das einspielen von Updates um einiges erschweren ;)

    Davon ab dürft es bei IPv6 kaum einen Unterschied für netcup machen ob nur intern geroutet wird oder man Zugriff auf das ganze Internet hat, IPv6-Adressen gibt es auch mehr wie genug. Im Gegenteil, der Zugriff auf das komplette Internet ist bereits implementiert, die Implementierung für den Sonderfall "nur intern" kostet vermutlich mehr wie die möglicherweise anfallenden Kosten für den zusätzlichen externen Traffic. Und wer sich aus dem Internet aussperren will kann dies ja immer noch über iptables und co machen ;)

    Zitat von julian-w

    Würde auch das einspielen von Updates um einiges erschweren ;)

    Davon ab dürft es bei IPv6 kaum einen Unterschied für netcup machen ob nur intern geroutet wird oder man Zugriff auf das ganze Internet hat, IPv6-Adressen gibt es auch mehr wie genug. Im Gegenteil, der Zugriff auf das komplette Internet ist bereits implementiert, die Implementierung für den Sonderfall "nur intern" kostet vermutlich mehr wie die möglicherweise anfallenden Kosten für den zusätzlichen externen Traffic. Und wer sich aus dem Internet aussperren will kann dies ja immer noch über iptables und co machen ;)

    Da wäre aber ein Dual-Stack Lite Setup ganz interessant, sodass die VMs nur eine Adresse aus dem 10.0.0.0/8er Netz bekommen, aber Internetzugang trotzdem IPv4 Outbound möglich ist.

    Zitat von julian-w

    Davon ab dürft es bei IPv6 kaum einen Unterschied für netcup machen ob nur intern geroutet wird oder man Zugriff auf das ganze Internet hat

    das denke ich sollte sich auf IPv4 bezogen haben; weil bei IPv4 eben irgendwann ein Mangel entstehen könnte;

    aber was brächte eine RFC1918-IPv4 zum IPv6/64-Prefix?

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Zitat von H6G

    Da wäre aber ein Dual-Stack Lite Setup ganz interessant, sodass die VMs nur eine Adresse aus dem 10.0.0.0/8er Netz bekommen, aber Internetzugang trotzdem IPv4 Outbound möglich ist.

    DS-Lite brauchst Du nicht wirklich, weil die Update Repositories sind kiloweise via IPv6 erreichbar; ich würd es echt IPv6only machen;

    (vereinfacht einiges)

    Mittlerweile ist es doch so, daß jede Linux/Unix Distri IPv6 nur mit irgendwelchen Schaltern in den Untiefen deaktiviert werden kann, aber IPv4 geht ziemlich oberflächlich zum deaktivieren;

    nachdem ich zu Hause - habe eine echte IPv4only-DMZ - danach suchte, auf meinem Router WAN seitig IPv6 zu deaktivieren;

    eine fe80::/64 scope-link addr macht bei IPv4only nicht wirklich Sinn;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Zitat von killerbees19

    Naja, ein eigenes VLAN pro Kunde wird als Preisbrecher nicht drinnen sein. Aber kein Routing ins öffentliche Netz, nur RZ intern würde gut klingen. Vielleicht hast Du es eh so gemeint, das kam mit dem Begriff VLAN nicht ganz durch.

    Zitat von [netcup] Kai

    Das wird nicht funktionieren, da zumindest ein Uplink Richtung unseren Installationsservern, Rettungssystem etc. gegeben sein muss. Der zugriff darauf läuft nur über die öffentlichen IP-Adressen.

    yep es war nur Intern im NetCup Netz gemeint.

    Zitat von [netcup] Felix

    Wie wichtig ist Ihnen eigentlich unsere doch recht hohe garantierte Mindestverfügbarkeit von 99,6% bei unseren VPS? Würde jemand von Ihnen VPS mit 98% Mindestverfügbarkeit kaufen, wenn der Preis dafür halbiert wäre?

    Ich habe nur einen VPS als Backup Speicherplatz. Ansonsten bevorzuge ich die Root Server wegen der hohen Verfügbarkeit und besseren garantierten Ressourcen. Ich nehme also nur beim Backup-System Abstriche bei der Mindestverfügbarkeit hin, nicht bei Produktiv Servern.

    Ich stehe gerade auf dem Schlauch.

    Ich habe folgende VPN Site Konfigurationen:


    Code
    172.20.20.0/24 <=> 172.20.20.172 < = OPENVPNLINK 10.8.0.128/25 = > Netcup Server

    Die Netcup Server sind untereinander mit Tinc verbunden (172.20.25.0/24) der Server auf dem OpenVPN läuft, hat eine interne Tinc IP 172.20.25.7

    Von 172.20.20.172 aus kann ich 172.20.25.7 anpingen.

    Von dem restlichem 172.20.20.0/24 Netz nicht.


    Ich sehe die Pakete auf dem Gerät 172.20.20.172 in das Interface tun1 reingehen (Routen stimmen also), aber sie tauchen auf dem Interface-Gegenstück tun0 auf dem NC Server nicht auf. Weder mit tcpdump noch mit iptables-log. Firewalls sind offen (sowohl implizit als auch explizit) - ich vermute ein Problem mit OpenVPN.

    Wo muss ich da ansetzen, was mache ich falsch?

    Wenn man glaubt, man kennt schon alle Warnungen der verwendeten Software:

    Zitat

    dsync(user@example.net): Warning: Maildir foo/bar: Synchronization took 75 seconds (18237 new msgs, 0 flag change attempts, 0 expunge attempts)

    Ja, lieber Dovecot, ich weiß dass diese Maildirs groß sind, die Anbindung über NFS zum Storage trotz SSD suboptimal und Deine CPU lahm ist… ^^


    (kein netcup Produkt; System zu Hause)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Zitat von voja

    IP Forwarding ist an? Sind auf den tinc Nodes überall Routen auf das VPN Netz via OpenVPN Server gesetzt?

    IP Forwarding ist an. Hat ja schonmal funktioniert - nur auf beiden Systemen getrennt.

    Der erste Tinc Node hat die Route zurück (ist ja auch der erste OpenVPN Server) - ich komme ja aber nichtmal zu dem Endpunkt, weil am Tunnel ist Schluss.

    Zitat von Gunah

    iptables -t nat -A POSTROUTING -o tunDeviceWelchesSourceIstALsoTincd -j MASQUERADE

    Kein Masquerading - die Header sollen gleich bleiben. Links und rechts vom Tunnel soll jeder jeden erreichen.

    Zitat von Gunah

    hast du die route mal statisch gesetzte was dann passiert?

    es kommt ja schon am richtigen Interface an, nur durch den Tunnel gehen die Pakete nicht.

    Die Pakete sind am Interface tun1 abgreifbar. Mit den Routen stimmt also alles. Ich muss irgendwas bei OpenVPN übersehen.

    Code
    client-to-client

    aktiv?


    Edit:

    Code
    # Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..