[erledigt]CARB aufsetzen mit 2 mal pfsense und 3 WAN über VLAN-Switch…
-
So, nach dem ich ne Weile kämpfen musste um das Zeug vom Chef zu bekommen…
Ich jetzt habe folgende Umgebung:
3*WAN
- KABEL Internet als normale Leitung (feste IP)
- DSL Internet als Ersatzleitung bei Kabel-Ausfall(feste IP)
- Mobilfunk als letztes Mittel emails senden zu können ;) (keine feste IP, Provider-NAT)
1*Pfsense - PC
1* Switch (unmanaged)
daran hängen die Rechner und der Server
Es gibt einen neuen pfsense-Router 19" mit 2 APU1D4 (pfsense 2.2 64bit)
Und ich habe zwei managed switches (8port Netgear V3)ich schreib mal hin was ich verstanden habe und bitte um Korrektur oder Hilfestellung wo ich etwas nicht richtig kapiert habe.
Jetzt gehts ans vorbereiten:
- die beiden APUs sollen als Carb-Cluster arbeiten
- alle drei WAN sollen jeweils über einen Switch und VLAN auf den ersten Port jeder APU laufen (sonst reichen die Ports ja nicht)
- der jeweils zweite Port der APUs soll dann zu dem Switch für das Interne netz gehen
- der jeweils dritte APU-Port ist über einen kleinen Switch oder ein Xover-Kabel verbunden für die CARB-Messages
alle IP-Adressen sind jetzt mal erfunden, aber das Prinzip sollte stimmen.
WAN1 - KABEL
Zuerst mal hab ich noch einen kleinen Router besorgt, weil das Kabelmodem nur eine IP bereit stellt und kein Netz.- IP vom Kabelnetz : 80.81.82.83 und Gateway 80.81.82.85
- Netz für das WAN-Netz: 192.168.1.0/24
- Echte IP für 1.te APU 192.168.1.2
- Echte IP für 2.te APU 192.168.1.3
- Virtuelle IP für WAN-Interface 192.168.1.1
WAN2 - DSL
- IP vom DSL-Netz : 90.81.82.83 und Gateway 90.81.82.85
- Netz für das WAN-Netz: 192.168.2.0/24
- Echte IP für 1.te APU 192.168.2.2
- Echte IP für 2.te APU 192.168.2.3
- Virtuelle IP für WAN-Interface 192.168.2.1
WAN3- GSM
- IP vom GSM Netz : 100.81.82.83 und Gateway 100.81.82.85
- Netz für das WAN-Netz: 192.168.3.0/24
- Echte IP für 1.te APU 192.168.3.2
- Echte IP für 2.te APU 192.168.3.3
- Virtuelle IP für WAN-Interface 192.168.1.1
in allen drei Netzen ist jeweils eine DMZ-Adresse auf die Virtuelle IP des jeweiligen WAN-Interfaces angelegt.
http://blog.antiblau.de/2014/05/31/port-based-vlan-mit-netgear-gs108tv2/
So will ich dann die VLAN anlegen und ich brauche dann aber ZWEI Ports als Ausgang .. jeweils zu einem der WAN-Ports von den APUs. Kann man das so machen?Auf jeder PVsense muss ich ebenfalls VLAN anlegen für jedes WAN-Netz und als Interface eintragen damit trenne ich die Daten wieder auf, die ich vorher mit dem Switch da zusammen auf einen Port gebracht habe.
Dann https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_%28CARP%29
Ich habe also:- ein Internes Netz 10.10.10.0/24
- IP für APU1 10.10.10.1
- IP für APU2 10.10.10.2
- Virtuelle IP für CARB 10.10.10.3 (das ist die IP, die die Clients benutzen als gateway)
die beiden Ports können direkt an den unmanaged Switch. Wer von den beiden die virtuelle IP benutzt legen die selber fest. Über die echte IP erreiche ich die Kisten fürs Managment
Der dritte Port der APUs:
- IP der ersten APU 10.10.99.1
- IP der ersten APU 10.10.99.2
Die beiden Ports werden einfach über einen simplen Switch verbunden, oder Xover.
Ist es das zumindest mal grob, oder hab ich noch etwas GAR NICHT verstanden?
Danke schon mal für jede Hilfe ;)
-
Im Groben stimmt das schon. Ich habe nur ein paar kleine Anmerkungen:
- Echte IP für 1.te APU 192.168.1.2
- Echte IP für 2.te APU 192.168.1.3
- Virtuelle IP für WAN-Interface 192.168.1.1
Kann man so machen (dito für andere Interfaces), aber welche IP denkst du dem Router zu, der einwählt? .254?
Wir machen es der Logik halber meist so, dass das Default GW der Netze immer die 1 bekommt. Das hieße in deinem Szenario, dass von den 3 WANs jedes Mal der Router, der die Verbindung aufbaut, die .1 bekommt. Wir legen dann auch die pfSensen auf 251 und 252 und als VIP die 254 an. (Wegen #1, #2 -> einfach zu identifizieren).Das ist aber nur ein Gedanke.
WAN3- GSM
…- Virtuelle IP für WAN-Interface 192.168.1.1
Schreibfehler, sollte wohl die 3.1 sein ;)
- ein Internes Netz 10.10.10.0/24
- IP für APU1 10.10.10.1
- IP für APU2 10.10.10.2
- Virtuelle IP für CARB 10.10.10.3 (das ist die IP, die die Clients benutzen als gateway)
Würde ich nicht machen. Momentan ist ja auch die .1 das Gateway oder nicht? Dann lasse die .1 als Gateway und lege die beiden APUs entweder auf .2 und .3 oder auf was logisches freies (201/202, 251/252, 11/12 fallen mir da ein).
Bei .3 denkt man nicht intuitiv an ein Default Gateway.Der dritte Port der APUs:
- IP der ersten APU 10.10.99.1
- IP der ersten APU 10.10.99.2
Kannst du halten wie du möchtest. :) Daher ja.
Die beiden Ports werden einfach über einen simplen Switch verbunden, oder Xover.
Crossover. Ist besser, da du keine unnötige Hardware dazwischen hast. Plus bei einem Power Fail von einer Einheit, bekommt es die andere instant mit, da das Interface down geht.So will ich dann die VLAN anlegen und ich brauche dann aber ZWEI Ports als Ausgang .. jeweils zu einem der WAN-Ports von den APUs. Kann man das so machen?
Die Grafik auf dem Blog hab ich auf die schnelle nicht verstanden aber im Prinzip ist es einfach:Du braucht 3 VLANs (bspw.):
- VLAN 10/20/30
- diese auf Switch einrichten
- Port 1 -> VLAN 10
- Port 2 -> VLAN 20
- Port 3 -> VLAN 30
- dann am Besten frei lassen und die pfSensen auf die letzten beiden Ports stecken:
- Port 7/8 -> VLAN10+20+30
Ports 1-3 bekommen jeweils NUR ihr VLAN UNtagged. Da deine kleinen Front-Router, die die Verbindungen ins Netz halten kein VLAN sprechen, kommen deren Pakete untagged an, und werden im Switch dann getagged (man stellt ein, was man auf dem Port erwartet -> deshalb untagged). => Port 1 -> VLAN 10 untagged , Port 2 -> VLAN 20 untagged etc.
Ports 7+8 bekommen alle 3 VLANs (10/20/30) TAGGED. Da du die VLANs auf den APUs direkt einrichtest, sprechen die APUs mit dem Switch auch via tagged packages, deshalb soll der Switch auf den Ports getaggten Verkehr erwarten und nicht selbst Tags auf die Pakete kleben.
Dann auf dem WAN Interface der pfSensen einfach die 3 VLANs anlegen, diese als Interfaces zuweisen und dann benennen & konfigurieren wie ein normales physikalisches Interface.Sobald die Interfaces alle korrekt definiert sind und laufen (und VOR dem Anlegen irgendwelcher VIPs bzw. CARP IPs!!) dann den Sync einrichten, checken dass das geht (bspw. eine Filterregel aufs Lan kleben und auf der zweiten Box schauen ob sie repliziert wurde) und DANN erst die VIPs definieren (die werden dann nämlich von #1 auf #2 gesynct und du musst #2 eigentlich nicht mehr anfassen).
Go for it :)
Grüße
Jens -
Im Groben stimmt das schon. Ich habe nur ein paar kleine Anmerkungen:
…
Sobald die Interfaces alle korrekt definiert sind und laufen (und VOR dem Anlegen irgendwelcher VIPs bzw. CARP IPs!!) dann den Sync einrichten, checken dass das geht (bspw. eine Filterregel aufs Lan kleben und auf der zweiten Box schauen ob sie repliziert wurde) und DANN erst die VIPs definieren (die werden dann nämlich von #1 auf #2 gesynct und du musst #2 eigentlich nicht mehr anfassen).
Go for it :)
Grüße
JensJa, deine Anmerkungen machen teilweise sinn … aber ein paar Dinge sind nicht so einfach zu ändern weil das historisch hier so ist .. zum Beispiel ist unser Server auf der x.x.x.1 ...
Jetzt hab ich aber ein Problem mit dem CARB .. nachdem ich die Interfaces schon mal grob angelegt habe wollte ich nun CARB anwerfen.
ich bekomme auf beiden Kisten ständig Meldungen:An error code was received while attempting XMLRPC sync with username admin http://10.10.99.1:443 - Code 6: The requested method didnt return an XML_RPC_Response Object
Natürlich synct er dann auch nicht ... Ideen dazu?genau DEN Fehler hab ich mit Google nicht gefunden
Also ich hab die dritte Schnittstelle jeweils CARB-Interface genannt, die Firewallregeln angelegt und eben so wie im DOC beschrieben ..
https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_%28CARP%29Braucht man für diese Interfaces ein gateway?
Also
- kiste 1 hat 10.10.99.1
- kiste 2 hat 10.10.99.2
Bei Sync ist bei Kiste 1 die 2 eingetragen und bei kiste 2 die 1
Passwort und benutzername vom Admin natürlich -
Ok .. die Anleitung ist da nicht genau genug … TCP & UDP und PFSYNC ... TCP alleine reicht nicht in der Firewall
Jetzt synct das! :D -
Hi!
Nur in 1 Richtung syncen! Also von Master, vermutlich die 1, auf Backup (2).
Gateway ist nicht nötig, ist ja im eigenen Netz.
-
Ja, also wie gesagt: Jetzt geht es. Die Regeln waren das Problem. Und der Hinweis, dass man nur in eine Richtung syncen darf, ist natürlich auch richtig!
Heute bereite ich den Switch vor und richte den Rest ein. Heute Abend werde ich versuchen das umzustellen… zur Not ist die alte Kiste ja noch da und ich kann jederzeit zurück, wenn noch was nicht will.gruß
PS: Ich hab alles hinbekommen. Also danke für die Tips und coole Sache jetzt! ;)
-
Nicht vergessen das ganze auch mal zu testen (also Fehlerfälle durchspielen und sehe ob wie gewünscht funktioniert). Sonst steht man im Fall des Falles wieder dumm da. ;)
-
Ja, hab ich gemacht … es waren noch ein paar Fallen:
Die ganzen Rules, das NAT usw. müssen jeweils auf die vIP's und Gateway-Groups geleitet werden und nicht auf die feste IP einer Sense. Da muss man erst mal alles finden... als ungeübter ist das nicht alles logisch und sofort zu erkennen.
DHCP hab ich jetzt laufen auf der Sense, aber da muss man, unabhängig von CARP noch mal die jeweilige IP des Failovers angeben. Im Gegensatz zu CARP muss man auf dem Slave auch die IP des Masters angeben.
Damit der DNS der Sense die Anfragen für einen AD-Server richtig an diesen weiter gibt muss man die die lokale Domain in "Domain-Override" eintragen und dort den AD-Server als DNS-Server angeben.und noch ein paar mehr so Kleinigkeiten... Also ne Menge gelernt!
ABER ES GEHT! Ich kann jetzt beliebig irgendwelche Stecker ziehen von WAN oder LAN (natürlich jeweils an einer Stelle wo es dann eine Möglichkeit für Failover gibt) und alles läuft weiter!
Nur VPN ist bei Auswall des grade benutzen WAN erst mal weg ... ist ja aber auch logisch. Dann muss man die IP des anderen WAN ansprechen.gruß
-
Nur VPN ist bei Auswall des grade benutzen WAN erst mal weg … ist ja aber auch logisch. Dann muss man die IP des anderen WAN ansprechen.
Lässt sich aber auch einfach lösen, indem du einfach VPN Client Configs erzeugst, in denen beide Server IPs nacheinander drinstehen. Erreicht er dann die erste nicht, wählt er automatisch die zweite. Auch bei einer Zwangstrennung durch Verbindungsverlust. Kann man - wenn man Last verteilen möchte - auch RoundRobin eintragen, so dass mal die eine mal die andere gewählt wird, aber in deinem Fall ist nacheinander wahrscheinlich der gewünschte Zustand ;)