Wie kann man den gesamten Verkehr eines alten Hosts an einen neuen Host umleiten?

Wir ziehen eine Reihe von Diensten um, beispielsweise von 1.2.3.4nach 5.6.7.8.

Um zu testen, ob die neuen Dienste richtig konfiguriert sind, möchten wir den gesamten Datenverkehr für den ursprünglichen Host, der von unseren Testarbeitsstationen stammt, (auf den neuen Host) umleiten.

Natürlich ist eine solche Umleitung könnte auf Router innerhalb des Netzwerks selbst aber aus Stabilitätsgründen implementiert werden haben wir beschlossen, es auf jedem Arbeitsplatz direkt zu implementieren (die alle OS X 10.10 Yosemite sind, so verwenden pre-v4.7 OpenBSD pf).

Ich habe hinzugefügt zu /etc/pf.anchors/com.apple:

rdr-anchor "910.TestServiceMove/*" anchor "910.TestServiceMove/*" load anchor "910.TestServiceMove" from "/etc/pf.anchors/910.TestServiceMove" 

Und erstellt /etc/pf.anchors/910.TestServiceMove:

rdr pass log on lo0 from any to 1.2.3.4 -> 5.6.7.8 pass out log route-to lo0 from any to 1.2.3.4 keep state 

Wenn die Regeln geladen sind, scheinen beide korrekt zu funktionieren:

$ sudo tcpdump -v -n -e -ttt -i pflog0 tcpdump: WARNUNG: pflog0: Keine IPv4-Adresse zugewiesen tcpdump: Abhören von pflog0, PFLOG (OpenBSD-pflog-Datei vom Link-Typ), Erfassungsgröße 65535 Bytes 00: 00: 00.000000 Regel 0.910.TestServiceMove.0 / 0 (Übereinstimmung): Überlassen Sie en1: (tos 0x0, ttl 64, ID 40691, Offset 0, Flags [DF], Proto-TCP (6), Länge 64) 9.9.9.9.58029> 1.2.3.4.22: Flags [S], cksum 0x291a (korrekt), seq 3399416413, win 65535, Optionen [mss 1460, nop, wscale 5, nop, nop, TS val 2063366865 ecr 0, sackOK, eol], Länge 0 00: 00: 00.000047 Regel 0/0 (Übereinstimmung): rdr in lo0: (tos 0x0, ttl 64, id 40691, Offset 0, Flags [DF], proto-TCP (6), Länge 64, bad cksum 896a (- > b4da)!) 9.9.9.9.58029> 5.6.7.8.22: Flags [S], cksum 0xb284 (richtig), seq 3399416413, win 65535, Optionen [mss 1460, nop, wscale 5, nop, nop, TS val 2063366865 ecr 0, sackOK, eol], Länge 0 

Der TCP-Handshake wird jedoch nicht abgeschlossen (SYN-ACKs werden ignoriert und SYN wird wiederholt gesendet, bis die Verbindung abläuft):

$ sudo tcpdump -v -n -e -ttt host 5.6.7.8 tcpdump: Datenverbindungstyp PKTAP tcpdump: Abhören von pktap, PKTAP vom Typ Verbindung (Packet Tap), Erfassungsgröße 65535 Byte 00: 00: 00.000000 e8: 80: 2e: e7: 67: bc> 84: 80: 2d: 35: e5: 43, Ethertyp IPv4 (0x0800), Länge 78: (tos 0x0, ttl 63, id 40691, Offset 0, Flaggen [DF], Proto-TCP (6), Länge 64) 9.9.9.9.58029> 5.6.7.8.22: Flags [S], cksum 0xb284 (richtig), seq 3399416413, win 65535, Optionen [mss 1460, nop, wscale 5, nop, nop, TS val 2063366865 ecr 0, sackOK, eol], Länge 0 00: 00: 00.015524 84: 80: 2d: 35: e5: 43> e8: 80: 2e: e7: 67: bc, Ethertyp IPv4 (0x0800), Länge 74: (tos 0x0, ttl 52, id 0, Offset 0, Flaggen [DF], Proto-TCP (6), Länge 60) 5.6.7.8.22> 9.9.9.9.58029: Flags [S.], cksum 0x7ce4 (korrekt), seq 1901846890, ack 3399416414, gewinnen 14480, Optionen [mss 1460, sackOK, TS val 523934721 oder 2063366865, nop, wscale 7 ], Länge 0 00: 00: 00.986946 e8: 80: 2e: e7: 67: bc> 84: 80: 2d: 35: e5: 43, Ethertyp IPv4 (0x0800), Länge 78: (tos 0x0, ttl 63, id 25319, Offset 0, Flaggen [DF], Proto-TCP (6), Länge 64) 9.9.9.9.58029> 5.6.7.8.22: Flags [S], cksum 0xae9c (korrekt), seq 3399416413, win 65535, Optionen [mss 1460, nop, wscale 5, nop, nop, TS val 2063367865 ecr 0, sackOK, eol], Länge 0 00: 00: 00.014938 84: 80: 2d: 35: e5: 43> e8: 80: 2e: e7: 67: bc, Ethertyp IPv4 (0x0800), Länge 74: (tos 0x0, ttl 52, id 0, Offset 0, Flaggen [DF], Proto-TCP (6), Länge 60) 5.6.7.8.22> 9.9.9.9.58029: Flags [S.], cksum 0x78fa (korrekt), seq 1901846890, ack 3399416414, gewinnen 14480, Optionen [mss 1460, sackOK, TS val 523935723 oder 2063366865, nop, wscale 7 ], Länge 0 00: 00: 00.397794 84: 80: 2d: 35: e5: 43> e8: 80: 2e: e7: 67: bc, Ethertyp IPv4 (0x0800), Länge 74: (tos 0x0, ttl 52, id 0, Offset 0, Flaggen [DF], Proto-TCP (6), Länge 60) 5.6.7.8.22> 9.9.9.9.58029: Flags [S.], cksum 0x776c (korrekt), seq 1901846890, ack 3399416414, gewinnen 14480, Optionen [mss 1460, sackOK, TS val 523936121 oder 2063366865, nop, wscale 7 ], Länge 0 00: 00: 00.588237 e8: 80: 2e: e7: 67: bc> 84: 80: 2d: 35: e5: 43, Ethertyp IPv4 (0x0800), Länge 78: (tos 0x0, ttl 63, id 50201, Offset 0, Flaggen [DF], Proto-TCP (6), Länge 64) 9.9.9.9.58029> 5.6.7.8.22: Flags [S], cksum 0xaab4 (richtig), seq 3399416413, win 65535, Optionen [mss 1460, nop, wscale 5, nop, nop, TS val 2063368865 ecr 0, sackOK, eol], Länge 0 

Ich vermute, dass der TCP-Stack SYN-ACKs verwirft, die von einem anderen Host als dem stammen, an den das SYN gesendet wurde. Aber sollten Umleitungsregeln den Verkehr nicht in beide Richtungen umschreiben - sollte nicht keep statesichergestellt werden, dass die Verbindung zu diesem Zweck verfolgt wird?