Wir verschieben eine Reihe von Diensten, sagen wir von 1.2.3.4nach 5.6.7.8.
Um zu testen, ob die neuen Dienste richtig konfiguriert sind, möchten wir den gesamten für den ursprünglichen Host bestimmten Datenverkehr, der von unseren Testarbeitsstationen stammt, (auf den neuen Host) umleiten.
Natürlich, eine solche Umleitungkönnteauf Routern innerhalb des Netzwerks selbst implementiert werden – aber aus Stabilitätsgründen haben wir uns entschieden, es direkt auf jeder Arbeitsstation zu implementieren (die alle OS X 10.10 Yosemite sind, also OpenBSD pf vor v4.7 verwenden).
Ich habe hinzugefügt /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 ordnungsgemäß zu funktionieren:
$ sudo tcpdump -v -n -e -ttt -i pflog0
tcpdump: WARNUNG: pflog0: keine IPv4-Adresse zugewiesen
tcpdump: lauscht auf pflog0, Link-Typ PFLOG (OpenBSD-Pflog-Datei), Erfassungsgröße 65535 Bytes
00:00:00.000000 Regel 0.910.TestServiceMove.0/0 (Übereinstimmung): Ausgeben am 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 auf lo0: (tos 0x0, TTL 64, ID 40691, Offset 0, Flags [DF], Proto TCP (6), Länge 64, ungültige CK-Summe 896a (->b4da)!)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xb284 (korrekt), 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: lauscht auf pktap, Link-Typ PKTAP (Packet Tap), Erfassungsgröße 65535 Bytes
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, Flags [DF], Proto TCP (6), Länge 64)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xb284 (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.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, Flags [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, win 14480, Optionen [mss 1460,sackOK,TS val 523934721 ecr 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, Flags [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, Flags [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, win 14480, Optionen [mss 1460,sackOK,TS val 523935723 ecr 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, Flags [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, win 14480, Optionen [mss 1460,sackOK,TS val 523936121 ecr 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, Flags [DF], Proto TCP (6), Länge 64)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xaab4 (korrekt), 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 stammen als dem, an den die SYN gesendet wurde. Aber sollten Umleitungsregeln den Verkehr nicht umschreiben inbeideAnweisungen – sollte man nicht tatsächlich keep statedafür sorgen, dass die Verbindung zu diesem Zweck verfolgt wird?