Beiträge von frank_m

  • Proxmox: Netzwerk.Verzweifelung

    Es ist halt ein Installer, der alle Abhängigkeiten mitbringt. Dass er einem vorgefertigt alle Konfigurationen mitbringt, steht da nicht.

    Es ist ja auch nicht so, dass man das nicht auch auf einem Standard Debian hinbekommen würde. Bei dir war es nur so, dass sich ufw, docker und Proxmox dann am Ende in die Quere kamen. Du hättest ein sauberes Standard Debian auch hinbiegen können, und du kannst problemlos auch dein laufendes Proxmox in den gleichen hoffnungslosen Zustand versetzen.

    Denke noch an die Firewall. Da ist bei Proxmox auch einfach nichts drin.

  • Proxmox: Netzwerk.Verzweifelung

    Zitat von mfnalex

    Verstehe nicht was die SSHD-Einstellungen auf dem Host mit dem Netzwerk in der VM zu tun haben

    SSHD nicht. Das "nichts gemacht außer SSHD" ist das Problem.

    Zitat von mfnalex

    Da ich Proxmox per ISO installiert habe, und dabei auch automatisch eine Bridge angelegt wird, sollte doch eigentlich auf dem Host nichts weiter zu tun sein um Netzwerk in den VMs zu bekommen

    Nein. IP Settings, Routen, Firewall, ... alles muss eingerichtet werden.

  • Proxmox: Netzwerk.Verzweifelung

    Um noch mal auf die ursprüngliche Frage zurückzukommen:

    Zitat von mfnalex

    ip a und ip r auf dem Host:

    Da sind halt schon unnötige Routen in der Liste. Aber ob die stören, steht auf einem anderen Blatt.

    Ich vermute auch, dass die verschiedenen Frameworks sich da in die Quere kommen. ufw, docker und ProxMox sind am Ende vermutlich einfach zu viel.

  • Proxmox: Netzwerk.Verzweifelung

    Zitat von KB19

    Das ist doch der Debian Installer in einem Proxmox Tab im Browser

    Sieh an. Den hab ich noch nie gesehen.

    Zitat von mfnalex

    Okay jetzt bin ich echt am verzweifeln. Die VM kann 8.8.8.8 anpingen, aber nicht das Gateway:

    Dann zeige doch mal ip a, ipr und die iptables Ausgaben der VM. Welcher Nameserver ist eingestellt?

    ip a und ip r wären auch auf den Host insteressant, wenn die VM läuft.

    Um durch die ufw Regeln durchzusteigen, brauch ich ne Zeit. ich weiß schon, warum ich sowas von Hand mache. :(

  • Proxmox: Netzwerk.Verzweifelung

    Zitat von mfnalex

    up route add -net 188.40.80.128 netmask 255.255.255.192 gw 188.40.80.129 dev enp9s0

    Die Route ist unnötig. Der Eintrag sollte von allein entstehen durch die Angabe "address 188.40.80.147/26" weiter oben.

    Zitat von mfnalex

    Welche Adressen etc muss ich jetzt in den VMs hinterlegen? Kann ich mir einfach eine 10.3.5.X aussuchen?

    Ja.

    Zitat von mfnalex

    Wenn ja, was muss ich als Gateway eintragen?

    Natürlich die 10.3.5.1.

    Zitat von mfnalex

    Also z.b. wenn ich einen Webserver in der VM laufen habe, wie kann ich dann erreichen dass der unter der öffentlichen Host-IP ebenfalls unter 80/443 erreichbar ist?

    Über eine iptables Regel, z.B.

    Code
    iptables -t nat -A PREROUTING -i enp9s0 -p tcp --dport 80 -j DNAT --to-destination 10.3.5.2:80

    Achte darauf, dass der Port offen ist.

    Denke daran, dass du das alles auch für IPv6 brauchst.

  • iptables- seltsames Verhalten

    Ist sichergestellt, dass es vorher keine andere Regel gibt, die den Zugang zulässt?

    Was ist das für ne iptables Implementierung? Bei mir funktionieren die Kommandos so gar nicht.

    Ich blocke IP-Adressen bzw. Subnetze über ipset. Da brauche ich keine einzelnen Regeln in IP-Tables.

  • Das längste Thema

    Mal ne andere Frage:

    Es gibt ja oben rechts in der Ecke den Link für Themen mit ungelesenen Beiträgen, allerdings nur, wenn es auch ungelesene Beiträge gibt. Außerdem gibt es auf der Startseite die Box mit "ungelesenen Beiträgen", allerdings nur 5 Einträge. Frage: Gibt es auch einen Link oder Shortcut, die "letzten Beiträge" für einen längeren Zeitraum abzurufen? Dann braucht man nicht durch alle Foren zu suchen, wenn man noch mal einige Dinge der jüngeren Vergangenheit in Ruhe nachlesen will.

  • Das längste Thema

    Zitat von whoami0501

    Könnte natürlich sein, aber ich habe nichts an den originalen Regeln von Docker verändert.

    Was natürlich immer noch bedeuten kann, dass es blockiert wird. Das solltest du noch mal prüfen.

    Zitat von whoami0501

    Das kann ich nicht zu 100% sicher sagen, aber ich gehe davon aus, dass die Container ihre ULA Adressen nutzen. Müssen sie ja, wenn ich innerhalb des ULA Subnet bleibe und versuche, einen anderen Container darin anzusprechen.

    Ja, sie müssen schon. Aber tun sie es auch?

    Ich denke, es wird dir nichts anderes übrig bleiben, als mit tcpdump an drei Stellen zu sniffen: Im Quellcontainer, auf dem Host und im Zielcontainer. Dann musst du dir ansehen: Was schickt der Quell-Container auf die Reise, was sieht der Host, was kommt im Ziel-Container an, und wie antwortet er darauf, was kommt am Host wieder vorbei und was kommt im Quell-Container an.

  • Das längste Thema

    Zitat von whoami0501

    Hat jemand von euch eine Idee, woran das liegen könnte?

    Dafür kann es diverse Gründe geben.

    Zum einen könnte IPv6 Forwarding auf dem Host generell deaktiviert sein. Dann könnten Firewall Regeln auf dem Host die Kommunikation verhindern.

    Sind die Interfcaces der Container in einer Bridge zusammengefasst? Die könnte auch eine Rolle spielen. Nicht zuletzt: Welche Subnetzmasken benutzen die Container intern? Wissen sie, wo sie das Container Netz suchen müssen? Und: Welche Source Address nutzen sie für die Kommunikation im Container Netz? Vielleicht eine Link-lokale?

  • Das längste Thema

    Da ist schon der Fehler. Innerhalb eines LANs sollte es niemals Prefixes kürzer als /64 geben. Wenn man ein kürzeres Prefix hat, sollte man sich /64 Netze daraus machen, die man an gegebener Stelle einsetzt. Aber innerhalb eines LANs, wo die Geräte unmittelbar miteinander kommunizieren sollen (z.B. für den Zugriff auf Drucker/SMB), vergibt man dann natürlich nur Adressen aus einem /64 Netz.

    Ich bin auch nicht Glücklich mit der Verhaftung auf /64, z.B. für SLAAC. Aber es führt nun mal dazu, dass viele Geräte mit anderen Prefix Längen nicht zurecht kommen (auch Drucker etc.). Deshalb: Ein LAN IMMER mit /64 planen und die Infrastruktur (RADVD, DHCPv6) darauf ausrichten. Wenn dann 65534 Subnetze eines /48 ungenutzt bleiben, dann ist das halt so.

  • iCloud Mail-Domain

    Du könntest natürlich auch von dir zu Hause oder von einer öffentlichen Gegenstelle die txt records abrufen und prüfen, ob sie korrekt ausgeliefert werden.

    Bietet das iCloud Framework keine weiteren Diagnose-Möglichkeiten? Ich kenne es von Office365, dass man in den Domainsettings prüfen und präzise anzeigen lassen kann, was Microsoft findet und was es erwartet. Damit findet man auch Tippfehler.