[gelöst] firewall mark routing - falsche MAC auf Gateway

[McAldo]

Hallo,

ich habe ein kleines Problem mit Firewall Mark Routing und SNAT und komme nicht mehr weiter.

Folgende Situation:

Code: Alles auswählen

      LDAP-Server1                                 LDAP-Server2
     (192.168.100.2)                               (192.168.100.3)
     (AA:00:00:AA:00:02)                       (AA:00:00:AA:00:03)
                |                                     |
                |                                     |
                -------  Loadbalancer  ----------------
                |      (iptables, keepalived)         |
                |          (192.168.100.1)            |
                |       (AA:00:00:AA:00:01)           |
                |                      |              |
                |                      |              |
                |                      |              |
                 ------- S w i t c h   ----------------
                            |                         |
                      Client1                Client2
                 (192.168.100.10)      (192.168.100.11)
               (AA:00:00:AA:00:10)  (AA:00:00:AA:00:11)

Ich hoffe, das ist einigermaßen gut zu erkennen.

Zur Erklärung:
Es sind 2 LDAP.-Server vorhanden (könnten aber auch andere Server sein ). Das Gateway mit IPtables (auch Router) wurde mit keepalived nachgerüstet, welches Pakete zu den LDAP-Servern loadbalancen soll und bei Ausfall eines Server noch den anderen verfügbar halten.
Clients und Server sind im selben Subnetz (geht derzeit leider nicht anders).

Auf den Servern ist firewall mark routing aktiv für Pakete, die von der MAC des Loadbalancers kommen, um diese über den Router (Loadbalancer) und nicht direkt an den Client zu schicken. Der Client erwartet ja als Antwort Paket vom keepalived und nicht direkt vom Server.

Mittels tcpdump kann man den Netzverkehr auch super beobachten und sieht, Client sendet an LB, LB leitet an Server, Server sendet an LB und LB verschluckt das Paket. :/
Auf dem Rückweg ist zwar die Ziel-IP (also Client) im Paket enthalten, aber als MAC steht die des Loadbalancers.

Hier noch die entsprechenden Ausschnitte von tcpdump.

auf Client2

Code: Alles auswählen

> tcpdump -n -e -i any 'port 389'
Out AA:00:00:AA:00:11 ethertype IPv4 (0x0800), length 68: 192.168.100.11.46664 > 192.168.100.1.389: Flags [S], seq 4149157070, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
Out AA:00:00:AA:00:11 ethertype IPv4 (0x0800), length 68: 192.168.100.11.46664 > 192.168.100.1.389: Flags [S], seq 4149157070, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

auf Loadbalancer
Hier sollte in der dritten Zeile als Empfänger-MAC die von Client2 (also AA:00:00:AA:00:11) stehen.

Code: Alles auswählen

> tcpdump -n -e -i any 'port 389'
AA:00:00:AA:00:11  > AA:00:00:AA:00:01, ethertype IPv4 (0x0800), length 66: 192.168.100.11.46664 > 192.168.100.1.389: Flags [S], seq 4149157070, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
AA:00:00:AA:00:01 > AA:00:00:AA:00:02, ethertype IPv4 (0x0800), length 66: 192.168.100.11.46664 > 192.168.100.2.389: Flags [S], seq 4149157070, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
AA:00:00:AA:00:02 > AA:00:00:AA:00:01, ethertype IPv4 (0x0800), length 66: 192.168.100.2.389 > 192.168.100.11.46664: Flags [S.], seq 629711993, ack 4149157071, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0

auf LDAP-Server1

Code: Alles auswählen

> tcpdump -n -e -i any 'port 389'
In AA:00:00:AA:00:01 ethertype IPv4 (0x0800), length 68: 192.168.100.11.46664 > 192.168.100.2.389: Flags [S], seq 4149157070, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
Out AA:00:00:AA:00:02 ethertype IPv4 (0x0800), length 68: 192.168.100.2.389 > 192.168.100.11.46664: Flags [S.], seq 629711993, ack 4149157071, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0

Hat jemand eine Idee, wo ich suchen kann, warum die MAC-Adresse beim zurücksenden des Paketes nicht getauscht wird? Ich kann leider die IPtables-Regeln nicht direkt anschauen, da der Firewall mit Shorewall konfiguriert wird und im Output von iptables -vnL werde ich nicht so richtig fündig, da ich derzeit keine Idee mehr habe wo und was ich suche.

McAldo

[unitra]

Das Problem entsteht genau hier:

Code: Alles auswählen

    AA:00:00:AA:00:01 > AA:00:00:AA:00:02, ethertype IPv4 (0x0800), length 66: 192.168.100.11.46664 > 192.168.100.2.389: Flags [S], seq 4149157070, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    AA:00:00:AA:00:02 > AA:00:00:AA:00:01, ethertype IPv4 (0x0800), length 66: 192.168.100.2.389 > 192.168.100.11.46664: Flags [S.], seq 629711993, ack 4149157071, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0

1 Source MAC LB, Dest MAC LDAP1, source IP Client, Dest IP Server
2 Source MAC LDAP1, Dest MAC LB, source IP Server, Dest IP Client

Der Server versucht die Anfrage vermutlich an die Destination IP des Clients zu schicken mit der Dest MAC des Loadbalancers. Was an sich richtig ist. Aber da im ARP Cache des LDAP Servers die MAC Addresse für die IP 192.168.100.11 eine andere ist als die für die als die im Ethernet Frame steht, ergibt sich hier ein logisches Problem für den LDAP Server.

Trenne das Client und das Server Netz physikalisch sowie logisch (Client kommen in ein separates IP Netz), der Keepalived und die LDAP Server auch. Trenne die Ethernet Verkabelung auch entsprechend so dass du keinen Broadcast vom Client in das Servernetz senden kannst, und vice versa.

Sobald die Broadcast Domänen der Server und der Clients getrennt sind, und dazwischen ein Router steht hier dein (LB) , sollte es klappen.

[McAldo]

Das mit der Trennung ist angedacht, derzeit aber nicht umsetzbar. Mir ist klar, dass dabei dieses Gefrickel unnötig wäre, aber wie gesagt, derzeit muss es irgendwie so laufen. Es gibt andere Server, da funktioniert es. Irgendwas am Firewall auf dem Loadbalancer ist seltsam, bzw. am keepalived. Dieser übernimmt ja die Pakete und schiebt sie, solange die Ports offen sind zu den Kommunikationspartnern (Server, Client, ...).

McAldo

[McAldo]

So, gelöst. Das fehlte eine shorewall-Regel:

/etc/shorewall/interfaces

Code: Alles auswählen

#ZONE   INTERFACE       BROADCAST       OPTIONS
zone     ethX            -          tcpflags,nosmurfs,routeback

Wichtig ist die Option routeback

[unitra]

So, gelöst. Das fehlte eine shorewall-Regel:

/etc/shorewall/interfaces

Code: Alles auswählen

#ZONE   INTERFACE       BROADCAST       OPTIONS
zone     ethX            -          tcpflags,nosmurfs,routeback

Wichtig ist die Option routeback

Die Rückroute hat gefehlt, auch wenn das eine Layer2 Domäne ist, IP Packete werde weiterverarbeitet durch den LoadBalancer/Firewall, und es werden MAC Adressen ausgetauscht. So macht es auch ein Router, Quell MAC Adresse wird durch die eigene MAC Adresse ersetzt, und dann auf das Broadcast Segment gesendet.

Wieder für mich eine Brücke Richtung Routing mit linux geschlagen, funktioniert also im Prinzip genauso wie mit anderen Routern die IP Packete verarbeiten, so eine shorewall.