Estamos moviendo un montón de servicios, digamos de 1.2.3.4a 5.6.7.8.
Para probar que los nuevos servicios estén configurados correctamente, nos gustaría redirigir (al nuevo host) todo el tráfico destinado al host original que se origina en nuestras estaciones de trabajo de prueba.
Por supuesto, tal redirecciónpodríase implementará en enrutadores dentro de la propia red, pero por razones de estabilidad hemos decidido implementarlo directamente en cada estación de trabajo (que son todas OS X 10.10 Yosemite, así que use OpenBSD pf anterior a v4.7).
He añadido a /etc/pf.anchors/com.apple:
rdr-anchor "910.TestServiceMove/*"
anchor "910.TestServiceMove/*"
load anchor "910.TestServiceMove" from "/etc/pf.anchors/910.TestServiceMove"
Y creó /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
Cuando se cargan las reglas, ambas parecen funcionar correctamente:
$ sudo tcpdump -v -n -e -ttt -i pflog0
tcpdump: ADVERTENCIA: pflog0: no hay dirección IPv4 asignada
tcpdump: escuchando en pflog0, PFLOG de tipo enlace (archivo pflog de OpenBSD), tamaño de captura 65535 bytes
00:00:00.000000 regla 0.910.TestServiceMove.0/0 (coincidencia): pasar en en1: (tos 0x0, ttl 64, id 40691, desplazamiento 0, banderas [DF], proto TCP (6), longitud 64)
9.9.9.9.58029 > 1.2.3.4.22: Banderas [S], cksum 0x291a (correcto), seq 3399416413, win 65535, opciones [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK ,eol], longitud 0
00:00:00.000047 regla 0/0 (coincidencia): rdr en lo0: (tos 0x0, ttl 64, id 40691, desplazamiento 0, banderas [DF], protocolo TCP (6), longitud 64, suma de cksum incorrecta 896a (- >b4da)!)
9.9.9.9.58029 > 5.6.7.8.22: Banderas [S], cksum 0xb284 (correcto), seq 3399416413, win 65535, opciones [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK ,eol], longitud 0
Pero el protocolo de enlace TCP no se completa (los SYN-ACK se ignoran y SYN se envía repetidamente hasta que se agota el tiempo de conexión):
$ sudo tcpdump -v -n -e -ttt host 5.6.7.8
tcpdump: tipo de enlace de datos PKTAP
tcpdump: escucha en pktap, PKTAP (Packet Tap) de tipo enlace, tamaño de captura 65535 bytes
00:00:00.000000 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), longitud 78: (tos 0x0, ttl 63, id 40691, desplazamiento 0 , banderas [DF], protocolo TCP (6), longitud 64)
9.9.9.9.58029 > 5.6.7.8.22: Banderas [S], cksum 0xb284 (correcto), seq 3399416413, win 65535, opciones [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK ,eol], longitud 0
00:00:00.015524 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), longitud 74: (tos 0x0, ttl 52, id 0, desplazamiento 0 , banderas [DF], proto TCP (6), longitud 60)
5.6.7.8.22 > 9.9.9.9.58029: Banderas [S.], cksum 0x7ce4 (correcto), seq 1901846890, ack 3399416414, win 14480, opciones [mss 1460,sackOK,TS val 523934721 ecr ,nop,escala 7 ], longitud 0
00:00:00.986946 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), longitud 78: (tos 0x0, ttl 63, id 25319, desplazamiento 0 , banderas [DF], protocolo TCP (6), longitud 64)
9.9.9.9.58029 > 5.6.7.8.22: Banderas [S], cksum 0xae9c (correcto), seq 3399416413, win 65535, opciones [mss 1460,nop,wscale 5,nop,nop,TS val 2063367865 ecr 0,sackOK ,eol], longitud 0
00:00:00.014938 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), longitud 74: (tos 0x0, ttl 52, id 0, desplazamiento 0 , banderas [DF], proto TCP (6), longitud 60)
5.6.7.8.22 > 9.9.9.9.58029: Banderas [S.], cksum 0x78fa (correcto), seq 1901846890, ack 3399416414, win 14480, opciones [mss 1460,sackOK,TS val 523935723 ecr ,nop,escala 7 ], longitud 0
00:00:00.397794 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), longitud 74: (tos 0x0, ttl 52, id 0, desplazamiento 0 , banderas [DF], proto TCP (6), longitud 60)
5.6.7.8.22 > 9.9.9.9.58029: Banderas [S.], cksum 0x776c (correcto), secuencia 1901846890, ack 3399416414, win 14480, opciones [mss 1460,sackOK,TS val 523936121 ecr 5,nop,escala 7 ], longitud 0
00:00:00.588237 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), longitud 78: (tos 0x0, ttl 63, id 50201, desplazamiento 0 , banderas [DF], protocolo TCP (6), longitud 64)
9.9.9.9.58029 > 5.6.7.8.22: Banderas [S], cksum 0xaab4 (correcto), seq 3399416413, win 65535, opciones [mss 1460,nop,wscale 5,nop,nop,TS val 2063368865 ecr 0,sackOK ,eol], longitud 0
Supongo que la pila TCP está descartando los SYN-ACK que se originaron en un host distinto de aquel al que se envió el SYN. ¿Pero las reglas de redireccionamiento no deberían reescribir el tráfico enambosdirecciones; de hecho, ¿no debería keep stategarantizarse que se rastree la conexión para este propósito?