OPNsense Forum
International Forums => German - Deutsch => Topic started by: superwinni2 on May 14, 2019, 01:48:02 pm
-
Hallo zusammen
ich habe eine kleine Frage zwecks Hochverfügbarkeit.....
Ich habe hier 2 OPNsense im HA (mit CARP Interfaces)
Auf dem einen (Client) Netzwerk ein CARP mit der virtuellen IP 192.168.1.1 und auf der (Server) ebenso mit der virtuellen IP Adresse 192.168.2.1
Die OPNsense selbst haben die .2 oder .3 am Ende.
Routing, Connections, Verbindungen etc... Alles funktioniert.
Nun habe ich Programme bzw. Anwendungen die eine Telnet Verbindung von Client zu Server aufbauen. (Telnet, MSSQL etc)
Wenn mir nun eine OPNsense "wegfliegt" und das HA übernimmt fliegen all diese verbindungen "weg". Klar ich kann sie so gut wie sofort wieder erneut aufbauen. Was jedoch aufgrund der Anwendung nicht gerade sonderlich "toll" ist falls man beispielsweise gerade einen großen und langen SQL Befehl ausführt.
Ist dies normal? Kann man das irgendwie "verbessern"?
Danke schonmals
Grüße
superwinni2
-
> Wenn mir nun eine OPNsense "wegfliegt" und das HA übernimmt fliegen all diese verbindungen "weg".
Nö genau das sollte eigentlich nicht passieren, ansonsten ist das HA nicht sauber oder die entsprechende Anwendung extrem sensibel. Aber wir haben auch schon via RDP ein Video angeschaut und dabei ein Failover getriggert. Es waren 2-3 Frames nicht zu sehen, dann gings weiter. Verbindungen die wegfliegen sollte es durch State und Regelsync genau nicht geben, gerade bei TCP und Telnet und MSSQL _sind_ TCP.
Gruß Jens
-
Mhmm okay.. Dann ist da wohl irgendwas nicht ganz koscher....
Also das die Anwendungen sooo sensibel sind wären mir neu...
Dann nun die große Frage... Was wäre das beste vorgehen um den Fehler zu finden?
Hier mal die Settings der HauptFW:
Virtual IP address Interface Type Description
10.100.100.1/24 (vhid 100 , freq. 1 / 0) VLAN100 CARP VLAN100 VIP
10.100.200.1/24 (vhid 200 , freq. 1 / 0) VLAN200 CARP VLAN200 VIP
1.2.3.82/28 (vhid 1 , freq. 1 / 0) WAN CARP VIP .82
1.2.3.86/28 (vhid 5 , freq. 1 / 0) WAN CARP VIP .86
1.2.3.87/28 (vhid 6 , freq. 1 / 0) WAN CARP VIP .87
1.2.3.88/28 (vhid 7 , freq. 1 / 0) WAN CARP VIP .88
1.2.3.89/28 (vhid 8 , freq. 1 / 0) WAN CARP VIP .89
1.2.3.90/28 (vhid 9 , freq. 1 / 0) WAN CARP VIP .90
1.2.3.91/28 (vhid 10 , freq. 1 / 0) WAN CARP VIP .91
1.2.3.92/28 (vhid 11 , freq. 1 / 0) WAN CARP VIP .92
1.2.3.93/28 (vhid 12 , freq. 1 / 0) WAN CARP VIP .93
1.2.3.94/28 (vhid 13 , freq. 1 / 0) WAN CARP VIP .94
172.20.1.4/24 (vhid 21 , freq. 1 / 0) DMZ011 CARP DMZ11 VIP 172.20.1.4
172.20.20.4/24 (vhid 22 , freq. 1 / 0) DMZ012 CARP DMZ12 VIP 172.20.20.4
172.20.2.4/24 (vhid 23 , freq. 1 / 0) DMZ013 CARP DMZ013 VIP 172.20.2.4
10.0.100.1/24 (vhid 41 , freq. 1 / 0) VLAN001 CARP VLAN001 VIP 10.0.100.1
10.100.50.1/23 (vhid 50 , freq. 1 / 0) VLAN050 CARP VLAN050 VIP 10.100.50.1
10.100.60.1/24 (vhid 60 , freq. 1 / 0) VLAN060 CARP VLAN060 VIP 10.100.60.1
172.21.0.4/24 (vhid 110 , freq. 1 / 0) VLAN110 CARP VLAN110 VIP 172.21.0.4
172.29.29.1/24 (vhid 114 , freq. 1 / 0) VLAN114 CARP VLAN114 VIP 172.29.29.1
10.100.112.1/24 (vhid 112 , freq. 1 / 0) VLAN112 CARP VLAN112 VIP 10.100.112.1
10.100.120.1/24 (vhid 120 , freq. 1 / 0) VLAN120 CARP VLAN120 VIP 10.100.120.1
10.100.113.1/27 (vhid 113 , freq. 1 / 0) VLAN113 CARP VLAN113 VIP 10.100.113.1
5.6.7.33/29 (vhid 40 , freq. 1 / 0) VLAN400 CARP
Es ist ein VLAN Interface welches für den Sync zuständig ist. Auf beiden Seiten eine komplette ANY Regel eingerichtet. Wird allerdings innerhalb der nächsten Wochen ein eigenes Hardware Interface (da neue Hardware) bekommen.
Aktuell hat die FW 3 Interfaces... Eine jeweils für WAN, LAN und DMZ.
LAN dementsprechend mit 11 VLANs.
Der Regelsync funktioniert sauber und ohne Probleme.
Habe beim den "HA Einstellungen" alles ausgewählt. (Macht das vielleicht Probleme?)
Wie kontrolliere ich am besten den State Sync?
Der ganze Spaß hängt zudem an einem managebaren Switch... Muss man hier noch was einstellen damit der das richtig verarbeitet?
Danke schonmals
Grüße
superwinni2
-
der einzige Fall, wie bei korrekter implementierung was verloren gehen könnte ist, wenn ein TCP Segment gerade von einer FW verarbeitet wird und dann ausfällt und das Protokoll UDP ist, da TCP nach kurzer Zeit eine Retransmission wegen mangelndem ACK triggern würde.
-
Also was ich gerade mal rausgefunden habe ist, dass man die pfSync nodes anschauen kann unter "Firewall -> Virtual IPs -> Status"
Hier zeigt mir unsere Haupt OPNsense folgendes an:
71840a21
c8ac2071
223bdeb3
1be4cab2
1801b97c
6822034b
c0b578a5
969bba25
3605d97f
83c05f6e
und unsere Backup:
b1e11812
9671dbbd
bb7f1d94
e923e143
Laut Forum von Netgate sollten jedoch bei beiden das gleiche Angezeigt werden... Ist hier der Hund begraben?
-
Wie so oft sitzt der Fehler ca. 30 cm vorm Bildschirm...
Habe aufm Backup vergessen den Haken zu setzten dass er die States Synchronisiert...
Bzw. weniger vergessen sondern eher nicht getraut, da man bei der ConfigSync dies ja nicht machen soll.... Naja bei den States somit schon... Somit stimmen zumindest mal die Sync Einträge links run rechts.
Werde nun irgendwann nachts mal testen müssen ob es auch so funktioniert wie ich mir das dann nun denke :P
-
> Bzw. weniger vergessen sondern eher nicht getraut, da man bei der ConfigSync dies ja nicht machen soll....
Nicht ganz. Es gibt zwei paar Stiefel. Einmal pfsync, die Komponente die bei den Sensen dafür zuständig ist alle States synchron zu halten damit alle Nodes immer den gleichen Zustand haben und im Notfall füreinander einspringen können. DAS sollen natürlich alle Knoten tun, sonst hast du beim Failback ja Murks, weil der wiedererweckte Primary nichts von den States am Standby weiß.
Und dann die Sync Komponente mit RPC Calls, die die Konfiguration rübersichern. DAS darf wiederum nur der Primary auf den Standby Node machen, damit niemand durcheinander kommt bzw. es plötzlich ein endlos-sync gibt (Master -> Standby -> Master zurück -> Standby ...).
Steht auch in der HA Konfiguration hinter dem "i" versteckt:
"This setting should be enabled on all members of a failover group." (pfSync)
"For setting up the backup machine leave this field empty! ..." (XML RPC)
-
Wäre der Mensch doch nur nicht so lesefaul ;D
-
Also habe es eben gestestet... Schuld an allem war der eine Haken auf der Backup Firewall welchen ich nicht verstecht habe.
Danke nochmals für den Tipp ;)
-
Anmerkung der Redaktion: das [SOLVED] bzw. [GELÖST] funktioniert nur im Titel des ersten Beitrags im Thread.
Grüsse
Franco
-
> Danke nochmals für den Tipp ;)
Immer gerne