[solved] Zwei Cluster über VIP verbinden

[l.gremme]

Hallo zusammen,

ich habe an dem ersten HA-Cluster ein Multi-WAN. Leitung A ist eine Glasfaserleitung (wird auf dem Switch gewandelt) und Leitung B eine VDSL-Leitung (Router vorgeschaltet, arbeitet im Privaten Adressbereich).

Bei der Leitung A liegen ca. 16 public IPs, die jetzt über das erste Firewall-Cluster ins DMZ-Netz geroutet werden sollen (ausgehendes NAT für div. Server). Dafür habe ich eine virtuelle IP (CARP) angelegt und die OPNSense im ersten Cluster kann nach draußen ohne Probleme kommunizieren.

Beim zweiten Firewall-Cluster (in der DMZ zu den internen Netzen) kann das ausgehende NAT nicht auf die 192.168.0.160/24 festgelegt werden. Wird dort die Schnittstellenadresse verwendet, ist das Lauffähig, kommt dem HA-Gedanken nicht wirklich nach, außer ich definiere eine Gateway-Gruppe.
Gerade im Hinblick auf die verschiedenen Netze, die in der DMZ stehen werden, z.B. über CARP weitere VIPs definiert, kommt es zu Problemen.

Ich möchte in dem zweiten Cluster die VIP vom ersten Cluster als Gateway definieren. Dabei geht trotz Any nach draußen kein Ping zu 1.1.1.1 oder 8.8.8.8

Version: 19.7.6

Code: [Select]

        WAN                   WAN
         :                     :
         : Ethernet            : VDSL
         :                     :
:               -----------
         :               |  Router  |
         :               ------------
         :                     |
         -----------------------
         |  Switch (redundant) |
         -----------------------
           |                 |
           |                 |
           |                 |       Multi-WAN mit Ausfallleitung
      -----------      -----------
      | OPNsense |-----| OPNSense|
      ----------- HA-1 -----------
           |     CARP        |
  x.x.x.151|  VIP x.x.x.150  | 192.168.0.152/24
           ---------------------
           |       DMZ         |
           ---------------------
           |    CARP         |
  x.x.x.161|  VIP x.x.x.160  | 192.168.0.162
     -----------          -----------
     | OPNsense |---------| OPNSense |
     -----------  HA-2    ------------
         |                   |
         |                   |
         ---------------------
         |  Interne Netze VIP |
         ----------------------


[JeGr]

> Beim zweiten Firewall-Cluster (in der DMZ zu den internen Netzen) kann das ausgehende NAT nicht auf die 192.168.0.160/24 festgelegt werden.

Hier fehlt das "WARUM". Es kann natürlich darauf festgelegt werden, sollte es auch. Wenn das nicht geht, fehlt hier wie gesagt, das Warum.

> Ich möchte in dem zweiten Cluster die VIP vom ersten Cluster als Gateway definieren. Dabei geht trotz Any nach draußen kein Ping zu 1.1.1.1 oder 8.8.8.8

Du möchtest was genau? Die beiden Nodes von Cluster 2 (also dem internen), sollen als GW die .150 haben? Oder? Das wäre der korrekte Weg, dass beide Nodes als WAN GW die .150 bekommen, die ja redundant auf dem Border Gateway Cluster liegt. Auch hier wieder "WARUM" und was geht nicht?

> Bei der Leitung A liegen ca. 16 public IPs, die jetzt über das erste Firewall-Cluster ins DMZ-Netz geroutet werden sollen (ausgehendes NAT für div. Server).

Wenn die IPs aufliegen (also gleiches Netz wie die Firewalls haben und nicht per Routing auf die Firewall Adresse kommen) dann wird da nichts weitergeroutet, sondern du kannst die Adressen nur als VIP Alias definieren und diese dann per 1:1 NAT o.ä. weiterdefinieren.

Ansonsten hast du zwar gut beschrieben aber überhaupt keine Infos hier reingepackt, was nicht geht und wo deine Probleme sind, sondern nur beschrieben, dass du welche hast.

[l.gremme]

>> Beim zweiten Firewall-Cluster (in der DMZ zu den internen Netzen) kann das ausgehende NAT nicht auf die 192.168.0.160/24 festgelegt werden.

>Hier fehlt das "WARUM". Es kann natürlich darauf festgelegt werden, sollte es auch. Wenn das nicht geht, fehlt hier wie gesagt, das Warum.

Das NAT kann darauf festgelegt werden. Es kommt beim Ping von 192.168.0.160 auf die 192.168.0.150 (ICMP erlaubt) zu einem großen Paketverlust (60-80%). Testweise habe ich eine größere Webseite einer Zeitung aufgerufen und dort nur halbe Bilder dargestellt bekommen.

>> Ich möchte in dem zweiten Cluster die VIP vom ersten Cluster als Gateway definieren. Dabei geht trotz Any nach draußen kein Ping zu 1.1.1.1 oder 8.8.8.8

>Du möchtest was genau? Die beiden Nodes von Cluster 2 (also dem internen), sollen als GW die .150 haben? Oder? Das wäre der korrekte Weg, dass beide Nodes als WAN GW die .150 bekommen, die ja redundant auf dem Border Gateway Cluster liegt. Auch hier wieder "WARUM" und was geht nicht?

Beim ersten Cluster gibt es zeitweise bereits Aussetzer beim Schwenk der virtuellen IPs (keine Antwort vom ersten Cluster). Diese Aussetzer in der Zuständigkeit auf das zweite Cluster scheinen zuzunehmen, da von 10 Pings unterschiedlich viel zurück kommt. Auf beiden Synchronisationsschnittstellen (HA) gibt es eine ANY-allow-Regel.

Auszug des Ping-Verlustes über das erste Cluster (VM hat die 192.168.0.100 und geht über die 192.168.0.150 ins Internet). Das NAT ausgehende NAT steht auf der öffentlichen VIP. Die Firewall selbst macht ein Loadbalancing bei Paketverlust oder hoher Latenz auf die zweite Leitung. Das Loadbalancing funktioniert, da die Gateway-Gruppe in den Regeln mit angegeben ist.

Code: [Select]

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=36 ttl=58 time=8.22 ms
64 bytes from 1.1.1.1: icmp_seq=37 ttl=58 time=8.14 ms
64 bytes from 1.1.1.1: icmp_seq=38 ttl=58 time=8.14 ms
64 bytes from 1.1.1.1: icmp_seq=40 ttl=58 time=8.11 ms
64 bytes from 1.1.1.1: icmp_seq=44 ttl=58 time=8.71 ms
64 bytes from 1.1.1.1: icmp_seq=46 ttl=58 time=8.20 ms
64 bytes from 1.1.1.1: icmp_seq=48 ttl=58 time=8.17 ms
64 bytes from 1.1.1.1: icmp_seq=50 ttl=58 time=8.27 ms
64 bytes from 1.1.1.1: icmp_seq=52 ttl=58 time=8.24 ms
64 bytes from 1.1.1.1: icmp_seq=53 ttl=58 time=8.37 ms
64 bytes from 1.1.1.1: icmp_seq=54 ttl=58 time=8.08 ms
64 bytes from 1.1.1.1: icmp_seq=55 ttl=58 time=8.15 ms
64 bytes from 1.1.1.1: icmp_seq=56 ttl=58 time=8.02 ms
64 bytes from 1.1.1.1: icmp_seq=57 ttl=58 time=8.39 ms
64 bytes from 1.1.1.1: icmp_seq=58 ttl=58 time=8.19 ms
64 bytes from 1.1.1.1: icmp_seq=59 ttl=58 time=8.23 ms
64 bytes from 1.1.1.1: icmp_seq=60 ttl=58 time=8.12 ms
64 bytes from 1.1.1.1: icmp_seq=61 ttl=58 time=8.13 ms
64 bytes from 1.1.1.1: icmp_seq=62 ttl=58 time=8.16 ms
64 bytes from 1.1.1.1: icmp_seq=63 ttl=58 time=7.99 ms
64 bytes from 1.1.1.1: icmp_seq=96 ttl=58 time=8.41 ms
64 bytes from 1.1.1.1: icmp_seq=97 ttl=58 time=8.16 ms
64 bytes from 1.1.1.1: icmp_seq=98 ttl=58 time=8.17 ms
64 bytes from 1.1.1.1: icmp_seq=99 ttl=58 time=8.10 ms
64 bytes from 1.1.1.1: icmp_seq=100 ttl=58 time=8.14 ms
64 bytes from 1.1.1.1: icmp_seq=110 ttl=58 time=8.19 ms
64 bytes from 1.1.1.1: icmp_seq=112 ttl=58 time=8.14 ms
64 bytes from 1.1.1.1: icmp_seq=114 ttl=58 time=8.20 ms
64 bytes from 1.1.1.1: icmp_seq=116 ttl=58 time=8.22 ms
64 bytes from 1.1.1.1: icmp_seq=118 ttl=58 time=8.31 ms
64 bytes from 1.1.1.1: icmp_seq=119 ttl=58 time=8.27 ms
64 bytes from 1.1.1.1: icmp_seq=120 ttl=58 time=8.05 ms
64 bytes from 1.1.1.1: icmp_seq=121 ttl=58 time=8.17 ms
64 bytes from 1.1.1.1: icmp_seq=122 ttl=58 time=8.39 ms
64 bytes from 1.1.1.1: icmp_seq=123 ttl=58 time=8.22 ms
64 bytes from 1.1.1.1: icmp_seq=124 ttl=58 time=8.16 ms
64 bytes from 1.1.1.1: icmp_seq=125 ttl=58 time=8.44 ms
64 bytes from 1.1.1.1: icmp_seq=126 ttl=58 time=8.61 ms
64 bytes from 1.1.1.1: icmp_seq=127 ttl=58 time=8.21 ms
64 bytes from 1.1.1.1: icmp_seq=128 ttl=58 time=8.19 ms
^C
--- 1.1.1.1 ping statistics ---
151 packets transmitted, 40 received, 73% packet loss, time 152554ms
rtt min/avg/max/mdev = 7.992/8.223/8.712/0.167 ms

Die Kundenumgebung hat in der kleinen Darstellung zwei 10GB-Switche, die jweils direkt am Core-Switch hängen. Vom Core-Switch gehen weitere Switche in unterschiedliche Räume ab. Ich beschränke die Netzwerkkomponenten auf die genutzten Komponenten. Als Switch-Hersteller ist D-Link im Einsatz.

Die gesamten Firewalls sind in einem Proxmox VE-Cluster von 5 physikalsichen Maschinen verteilt. Die Netzwerkkarten stehen auf virtio. In der Zwischenzeit habe ich das Phänomen versucht in einem kleinen Nachbau nachzustellen. Dafür habe ich zwei Desktop-Rechner genutzt, die zwei Netzwerkkarten haben und eine Linkbündelung auf den Switch verwendet.

In der Kurzform habe ich das so aufgebaut:
PVE - Switch - Switch - PVE
   |
Uplink zum Internet (mit VIP); Anschluss an die restliche Umgebung!

Das PVE-Management VLAN ist untagged und die restlichen VLANs sind als tagged konfiguriert. Die Switche und die PVEs sind in einem abgetrennten Netzwerkbereich und der einzige Übergabepunkt ist die VIP ins Internet.

>> Bei der Leitung A liegen ca. 16 public IPs, die jetzt über das erste Firewall-Cluster ins DMZ-Netz geroutet werden sollen (ausgehendes NAT für div. Server).

> Wenn die IPs aufliegen (also gleiches Netz wie die Firewalls haben und nicht per Routing auf die Firewall Adresse kommen) dann wird da nichts weitergeroutet, sondern du kannst die Adressen nur als VIP Alias definieren und diese dann per 1:1 NAT o.ä. weiterdefinieren.

Das ist mir klar und ist der gleiche Weg, den ich mir überlegt habe. Alternativ geht dort anstelle eines 1:1-NATs die Portweiterleitung und ein entsprechendes ausgehendes NAT.

[l.gremme]

Hallo zusammen,

der Fehler wurde heute gelöst. Ursache ist das die VHID der virtuellen IPs in dem gleichen VLAN mehrfach vergeben waren. Dadurch gab es massive Probleme.

VG Lars