• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Mehrere Fragen zu Networking bei VNET Jails

SolarCatcher

Well-Known Member
Themenstarter #1
Im Rahmen eines OS-Upgrades von 11 auf 12 habe ich kürzlich die Jails auf einem Server auf VNET geändert. Sie sind alle über die Bridge bridge0 direkt mit dem Ethernet-IF des Hosts verbunden. Diese bridge0 hat die IP-Adresse 10.0.0.10.

1. Frage:
Ist es richtig/sinnvoll, den Jails als defaultrouter diese IP-Adresse 10.0.0.10 mitzugeben? Es funktioniert, aber ich frage mich ob das der empfohlene Weg ist.


Hetzner, bei denen der Server läuft, hat mich jetzt angemailt, weil der Server "verbotene" MAC-Addressen nutzt. Die beiden monierten Adressen sind 1x von der bridge0 und 1x von der Datenbank-Jail (diese müsste gar nicht direkt im Internet stehen - ich werde sie auf eine separate bridge1 legen, in der das Enternet-IF des Hosts nicht Mitglied ist). Daher

2. Frage:
Mir ist nicht klar, warum diese MAC-Addressen, nach außen gezeigt werden. Wie kann ich das abstellen? Wie kann ich selbst nachprüfen, welche MAC-Adressen nach außen verwendet werden? Die anderen Jails, in denen jeweils ein Webserver läuft, haben dieses Problem offenbar nicht - ich vermute mal, weil ich die Webserver per Redirect-Rule in PF anspreche und damit die MAC-Adresse des Hosts zur Anwendung kommt?

Noch eine Hintergrund Info: Der Server hat zwei öffentliche IP-Adressen, aber bisher(!) nur eine erlaubte MAC-Adresse auf der ersten IP-Adresse. Muss ich für die zweite IP-Adresse eine separate MAC beantragen und auf die bridge0 legen (diese zweite IP-Adresse wird per NAT auch von den Jails für den Kontakt nach draußen verwendet).
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#2
Sie sind alle über die Bridge bridge0 direkt mit dem Ethernet-IF des Hosts verbunden.
Hier ist dein Denkfehler. Also: Eine Bridge verhält sich (im Großen und Ganzen) wie ein Switch. Wenn du die epair-Interfaces der vnet-Jails mit der NIC des Hosts per Bridge verbindest, werden die epair-Interfaces ein Teil des großen Hetznernetzes. Die Pakete laufen dann vom epair-Interface des vnet-Jails über die Bridge zur NIC des Hosts und von dort weiter zu Hetzer. Und Hetzner wundert sich, dass ihnen unbekannte MAC-Adressen im Log auftauchen. Das sind mindestens die MACs der epair-Interfaces, wenn die IP des Hosts auf der Bridge liegt, dann auch noch die MAC-Adresse der Bridge.

Wenn du verhindern willst, dass Hetzner die MAC-Adressen der epair-Interfaces sieht, gibt es so lala gesagt nur zwei Möglichkeiten:
  • Du routest zwischen den epair-Interfaces und der Host-NIC. Du hast also die epair-Interfaces auf der einen Seite, die Host-NIC auf der anderen und net.inet.ip.forwarding=1. Die epair-Seite im Host wird im vnet-Jail als Router eingetragen. Das wird bei Hetzner nicht gehen, da die Rückroute von Hetzner zu deinen vnet-Jails fehlt
  • Du machst ein NAT zwischen den epair-Interfaces und der Host-NIC. Das hat den Vorteil, dass Hetzner nicht mehr sehen kann, was hinter der Host-NIC passiert. Der Nachteil ist, dass du mit Port Forwards hantieren musst, um Dienste in den vnet-Jails öffentlich erreichbar zu machen. Und natürlich die generelle Unschönheit von NAT.
 

medV2

Well-Known Member
#4
Yamagi hat ja schon alles beantwortet. Wenn du Hetzner Cloudserver benutzt bekommst du zusätzliche IPs quasi nachgeschmissen (1.2/Mon). Nur zur Info. Ob das auch für dedizierte gibt weiß ich nicht.
 

SolarCatcher

Well-Known Member
Themenstarter #5
@Yamagi Vielen Dank einmal wieder für die Erklärungen. Mit Deiner 2. Möglichkeit und MWL's FreeBSD Mastery Jails, habe ich es nun geschafft: Die Jails sind über eine Bridge miteinander verbunden, aber das Ethernet-Interface des Hosts gehört nicht zu deren Members.

Dabei tat sich dann noch ein Problem auf, weil iocage, das ich für das Jail-Management nutze, immer wieder das Ethernet-Interface hinzufügte - mit jeder hochgefahrenen Jail. MWL's Tipp, eine Bridge mit einem Loopback-Interface statt mit dem echten Ethernet-Interface einzurichten, klappte aber nicht und ich im FreeBSD-Forum den Hinweis, dass das erst ab FreeBSD 13 geht. Vorher kann man kein Loopback-IF in eine Bridge einfügen.

Aber natürlich hatten schon andere bei iocage die Möglichkeit angefragt, eine Bridge ohne echtes Ethernet-Interface zu haben. In 2018 wurde das dann zunächst auch so eingeführt, aber wenige Monate danach wieder zurückgenommen. Dafür wurde später die Option vnet_default_interface=none eingeführt (standardmäßig ist der Wert nämlich "auto"), die letztlich dasselbe ermöglicht. Mit einem iocage set vnet_default_interface=none default kann man das für alle iocage-Jails voreinstellen. Zur Sicherheit aber nochmal jede einzelne Jail nach dieser Property durchschauen - es kann per Jail natürlich überschrieben werden.

Ich habe mittlerweile in 2 der Jails Redis laufen. Nur mit VNET hast Du aber in der Jail ein separates Loopback-Interface, so dass Du Redis z.B. auf 127.0.0.1 legen kannst und dieses dann von den anderen separiert ist (diesen Tipp habe ich schon vor ein paar Jahren von Patrick M. Hausen bekommen).
 

jmt

Well-Known Member
#6
Alternativ kann man die Jails auch mit FreeBSD Bordmitteln bauen. Dann kann man dies alles selber steuern.
 

SolarCatcher

Well-Known Member
Themenstarter #7
Alternativ kann man die Jails auch mit FreeBSD Bordmitteln bauen. Dann kann man dies alles selber steuern.
Ja, würde ich für neue Server auch (wieder) überlegen.

Als ich mit Jails auf Servern anfing, hatte ich das auch ohne spezielle Jail-Manager gemacht. Aber ich fand bald das händische freebsd-update'n von mehreren Jails recht mühselig/langwierig und bin deshalb auf Iocage und Base-Jails umgeschwenkt: Einmal alle Jails runterfahren, Basis aktualisieren, alle Jails wieder hochfahren.

Mittlerweile bin ich aber eher wieder für klassische Jails zu haben, insofern vermutlich in Zukunft auch ohne Iocage.
 

SolarCatcher

Well-Known Member
Themenstarter #9
Interessant, ich bin kein Redis-Experte und wusste nicht, dass das auch über UNIX-Sockets geht. Dann wäre die Änderung zu VNET vielleicht wirklich gar nicht "notwendig" gewesen. Ich werde es demnächst einmal mit Sockets probieren, einfach aus Interesse.
 
#10
redis.conf

Code:
...
# If port 0 is specified Redis will not listen on a TCP socket.
port 0
...
unixsocket /tmp/redis.sock
unixsocketperm 777
...
Die Permissions kannste ja nach deinen Anforderungen anpassen.

Rob