Umbenennen von Netzwerk Schnittstellen
-
Hallo Zusammen,
habe 2 Pfsense Boxen im HA Verbund und würde gerne die Firewall States Syncen.
Eine Box ist virtuell und die andere ist Hardware, aufgrund dessen haben die beiden auch unterschiedliche Namen für die Schnittstellen (vtnetx und rex.Um pfsync nutzen zu können müssen die Schnittstellen aber auch die gleichen Namen haben.
Habe hier diese Anleitung gefunden:
- Open the xml-file and pretty at the beginning of the file you will find somethin similar to:
<?xml version="1.0"?> <pfsense> <version>21.7</version> <lastchange></lastchange> <system> <optimization>normal</optimization>- Between <system> and <optimization> you can add <earlyshellcmd>-lines. Right below <system> you add something similar to:
<earlyshellcmd>/sbin/ifconfig vtnet0 name WAN; /sbin/ifconfig vtnet1 name LAN; /sbin/ifconfig vtnet2 name DMZ;</earlyshellcmd>- Now you only have to find the lines where your "old" interface names are in e.g. <if>vtnet0</if> and replace the interface with the new name accordingly
Gibt es evtl. bessere Möglichkeiten oder Ideen
Prinzipell funktioniert es aber, habe es schon auf einem Testsystem probiert.(Ist eher ne Spielerei... Ob ich wirklich machen soll, ist mir noch nicht ganz klar...)
-
@beerman
Da steht aber nix, dass dies für ein HA-Setup auf unterschiedlicher Hardware empfohlen ist.Soweit ich weiß, müssen alle Interface gleich heißen, weil die Regeln übertragen werden. Und dafür wird bei unterschiedlicher Hardware empfohlen, alle verwendeten Interfaces durch LAGG zu ersetzen, auf beiden in derselben Reihenfolge.
-
@viragomann
Danke!Geht tatsächlich um die "Firewall States". Der Rest funktioniert und wird zwischen den beiden Boxen gesynct, zumindest das was ich in der HA-Konfiguration ausgewählt habe (Firewall Regeln / Aliasse, usw.).
Wenn ich aber die Synchronisation der States aktiviere, funktioniert das leider nicht so wirklich. Hierfür müssen die Interface (auf OS Ebene) wirklich gleich heißen, inkl. vlan. Also z.B. vtnet0.100.
Das mit dem LAGG erfordert natürlich ŵesentlich mehr Aufwand, als die Lösung oben... Könnte aber nachhaltiger sein.
-
@beerman
Laut dem Manual "pfSense XML-RPC Config Sync Overview" müssen die jeweiligen Interfaces nur in derselben Reihenfolge angeordnet sein.
Das hat sich vermutlich mit FreeBSD 12 geändert. Früher wurde LAGG benötigt, denn da wurde ein State an den Hardwarenamen des Interfaces gebunden bzw. an den des LAGG.Wenn nun dieselbe Reihenfolge reicht, wäre meine Praxis, die Konfiguration der beiden Firewalls zu exportieren, in einen Editor zu laden und die der 2. gemäß der ersten anpassen. Also die vtnetx in die entsprechende Reihenfolge bringen.
Das Ergebnis in ein neues File speichern (für den Fall, dass das Original noch benötigt wird) und wieder zu importieren.
Das geht relativ rasch und ist keine große Sache. -
@beerman said in Umbenennen von Netzwerk Schnittstellen:
Eine Box ist virtuell und die andere ist Hardware, aufgrund dessen haben die beiden auch unterschiedliche Namen für die Schnittstellen (vtnetx und rex.
Ab hier wirds unsupported. Ja kann man machen, kann aber auch übelst knallen, wenn man Maschinen nimmt, die komplett unterschiedlich sind.
@beerman said in Umbenennen von Netzwerk Schnittstellen:
Um pfsync nutzen zu können müssen die Schnittstellen aber auch die gleichen Namen haben.
Ignorier irgendwelche komischen Howtos für sowas. Das Einzige was identisch sein MUSS(!) ist die intern verwendete Interface Bezeichnung. Sprich: die IFs müssen in korrekter Reihenfolge genau wie auf dem ersten System angelegt sein. Dazu muss man nicht in Configs rumpfuschen, da muss man nur einmal beim Neuanlegen der VM dann sinnvoll die Interfaces nacheinander durchtippen.
Irgendwelchen BS mit earlyshellcmd zu machen halte ich mal für komplett Banane. Man spielt doch nicht an Interface Bezeichnern rum, sondern macht gleich die Config richtig. Zumal der dortige NAME (beschreibende Name) völlig unwichtig für CARP/HA ist, da es lediglich eine selbstgewählte Überschrift ist. Sowas wie "DMZ" gibt es intern nicht. Wichtig sind
- wan
- lan
- opt1-x
und die müssen auf beiden Systemen identisch und korrekt zugewiesen sein. Wie die heißen (WAN, DMZ, MeinWiFi o.ä.) ist dabei vollkommen irrelevant :)
Vergiß die komische Anleitung (frage mich eh, was der da zusammenbastelt) und schau nur, dass - wenn du das schon machen willst (unsupportet!) - dass zu jeder Zeit die entsprechend korrespondierenden Interfaces gleich benannt und zugewiesen sind.
Also bspw.
- WAN: intern: wan , Hardware: igb0 - vtnet0
- LAN: intern: lan, HW: igb1 - vtnet1
- DMZ: intern: opt1, HW: igb2 - vtnet2
etc.
Cheers
-
@beerman said in Umbenennen von Netzwerk Schnittstellen:
Wenn ich aber die Synchronisation der States aktiviere, funktioniert das leider nicht so wirklich. Hierfür müssen die Interface (auf OS Ebene) wirklich gleich heißen, inkl. vlan. Also z.B. vtnet0.100.
Ist das so? Ich habe gerade keinen 2.5er Cluster im Mix zur Hand - macht man eh eigentlich nicht. Aber zumindest inkl. 2.4.5 und Betas waren State Syncs nur über interne Namenskonvention - das lief auch unabhängig der realen HW Interfaces. Mir wäre da aktuell nicht bekannt, dass sich da was signifikant geändert hat?
Kann natürlich sein, weil das Verfahren nicht wirklich unterstützt wird, aber ich habe zumindest nichts davon gelesen.
-
@jegr said in Umbenennen von Netzwerk Schnittstellen:
@beerman said in Umbenennen von Netzwerk Schnittstellen:
Wenn ich aber die Synchronisation der States aktiviere, funktioniert das leider nicht so wirklich. Hierfür müssen die Interface (auf OS Ebene) wirklich gleich heißen, inkl. vlan. Also z.B. vtnet0.100.
Ist das so? Ich habe gerade keinen 2.5er Cluster im Mix zur Hand - macht man eh eigentlich nicht. Aber zumindest inkl. 2.4.5 und Betas waren State Syncs nur über interne Namenskonvention - das lief auch unabhängig der realen HW Interfaces. Mir wäre da aktuell nicht bekannt, dass sich da was signifikant geändert hat?
Kann natürlich sein, weil das Verfahren nicht wirklich unterstützt wird, aber ich habe zumindest nichts davon gelesen.
Danke für die ausführliche Antwort!
Ich denke, ja. Steht ja auch so in der offiziellen Doku: (Link)
States in pfSense are bound to specific operating system Interfaces. For example, if WAN is em0, then a state on WAN would be tied to em0. If the cluster nodes have identical hardware and interface assignments then this works as expected. In cases when different hardware is used, this can be a problem. If WAN on one node is em0 but on another node it is igb0, the states will not match and they will not be treated the same.
Wenn ich pfsync aktiviere, fehlen auf der Backup Box auch viele FW states. In der Doku wird empfohlen LAGG Interfaces anzulegen, falls man das Problem mit der unterschiedlichen HW hat. Ist nur die Frage, welches "LAGG Protocol" man dafür nehmen sollte?
Aber das wäre eine grössere OP an beiden Boxen... :) Einen wirklichen Nutzen, hätte ich ja auch eh nicht. Im Falle eines Schwenks, muss sich die Backup Box ja auch neu einwählen, und bekommt eine neue IP und die Verbuindungen in Richtung WAN wären "weg".;) Insofern lasse ich es jetzt so, und spare mir das... :) CARP und Konfig-Sync funktionieren ja sehr gut!
(Die Backup Box habe ich eh nur dafür, falls der Server mal down ist oder ähnliches...)
-
@beerman ah OK dann scheint sich das nur auf pfsync zu beziehen, die CARP von den Interfaces ist dann wohl durch die Interface Zuweisung safe, aber das hilft natürlich nicht gegen einen Brake wenn die States fehlen. Aber danke für den Verweis nochmals, den hatte ich wohl überflogen :)
Wir empfehlen eigentlich eher lagg Interfaces zu vermeiden wenn nicht benötigt. Klar an dieser Stelle können sie die HW Abstraktion sein, die man dafür braucht, dafür bringt das alleine mit den Zusatzfragen (welcher Modus, welcher funktioniert überhaupt, etc.) und der schlechteren Debugging-Sicht (wir hatten in der Vergangenheit schon HW IFs die mit laggs ihre Problemchen hatten und bspw. bei VLAN Anlage das IF hops genommen hatte) ihre eigenen Schwierigkeiten mit sich. Da es da eine Einwahl gibt macht Sync da eh wenig Sinn da wie du richtig sagst eh alle Verbindungen abreißen ;)
Darum am Besten einfach immer kompatible Backup-HW nehmen, macht alles leichter :)
-
Es sind dann aber auch alle States der internen VLAN Kommunikation mit weg.
Kommt hier scheinbar aber nicht zum tragen, da flache LAN Struktur.In dem Fall sehe ich eher eine Cold Standby als Zielführend an.
