Estamos migrando vários serviços, digamos de 1.2.3.4para 5.6.7.8.
Para testar se os novos serviços estão configurados corretamente, gostaríamos de redirecionar (para o novo host) todo o tráfego destinado ao host original originado de nossas estações de trabalho de teste.
É claro que tal redirecionamentopoderiaser implementado em roteadores dentro da própria rede - mas por razões de estabilidade decidimos implementá-lo diretamente em cada estação de trabalho (que são todas OS X 10.10 Yosemite, então use OpenBSD pf pré-v4.7).
Eu adicionei a /etc/pf.anchors/com.apple:
rdr-anchor "910.TestServiceMove/*"
anchor "910.TestServiceMove/*"
load anchor "910.TestServiceMove" from "/etc/pf.anchors/910.TestServiceMove"
E criou /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
Quando as regras são carregadas, ambas parecem funcionar corretamente:
$ sudo tcpdump -v -n -e -ttt -i pflog0
tcpdump: AVISO: pflog0: nenhum endereço IPv4 atribuído
tcpdump: ouvindo pflog0, PFLOG tipo link (arquivo pflog OpenBSD), tamanho de captura 65535 bytes
00:00:00.000000 regra 0.910.TestServiceMove.0/0 (correspondência): desmaiar em en1: (tos 0x0, ttl 64, id 40691, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 64)
9.9.9.9.58029 > 1.2.3.4.22: Flags [S], cksum 0x291a (correto), seq 3399416413, win 65535, opções [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK ,eol], comprimento 0
00:00:00.000047 regra 0/0 (correspondência): rdr em lo0: (tos 0x0, ttl 64, id 40691, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 64, bad cksum 896a (- >b4da)!)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xb284 (correto), seq 3399416413, win 65535, opções [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK ,eol], comprimento 0
Mas o handshake TCP não é concluído (SYN-ACKs são ignorados e SYN é enviado repetidamente até que a conexão expire):
$ sudo tcpdump -v -n -e -ttt host 5.6.7.8
tcpdump: tipo de link de dados PKTAP
tcpdump: escutando em pktap, PKTAP tipo link (Packet Tap), tamanho de captura 65535 bytes
00:00:00.000000 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), comprimento 78: (tos 0x0, ttl 63, id 40691, deslocamento 0 , sinalizadores [DF], proto TCP (6), comprimento 64)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xb284 (correto), seq 3399416413, win 65535, opções [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK ,eol], comprimento 0
00:00:00.015524 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), comprimento 74: (tos 0x0, ttl 52, id 0, deslocamento 0 , sinalizadores [DF], proto TCP (6), comprimento 60)
5.6.7.8.22 > 9.9.9.9.58029: Flags [S.], cksum 0x7ce4 (correto), seq 1901846890, ack 3399416414, win 14480, opções [mss 1460,sackOK,TS val 523934721 ecr 2063366865, não, escala 7 ], comprimento 0
00:00:00.986946 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), comprimento 78: (tos 0x0, ttl 63, id 25319, deslocamento 0 , sinalizadores [DF], proto TCP (6), comprimento 64)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xae9c (correto), seq 3399416413, win 65535, opções [mss 1460,nop,wscale 5,nop,nop,TS val 2063367865 ecr 0,sackOK ,eol], comprimento 0
00:00:00.014938 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), comprimento 74: (tos 0x0, ttl 52, id 0, deslocamento 0 , sinalizadores [DF], proto TCP (6), comprimento 60)
5.6.7.8.22> 9.9.9.9.58029: Sinalizadores [S.], cksum 0x78fa (correto), seq 1901846890, ack 3399416414, win 14480, opções [mss 1460, sackOK, TS val 523935723 ecr 2063366865, não, escala 7 ], comprimento 0
00:00:00.397794 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), comprimento 74: (tos 0x0, ttl 52, id 0, deslocamento 0 , sinalizadores [DF], proto TCP (6), comprimento 60)
5.6.7.8.22 > 9.9.9.9.58029: Flags [S.], cksum 0x776c (correto), seq 1901846890, ack 3399416414, win 14480, opções [mss 1460,sackOK,TS val 523936121 ecr 2063366865 ,não,wescala 7 ], comprimento 0
00:00:00.588237 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), comprimento 78: (tos 0x0, ttl 63, id 50201, deslocamento 0 , sinalizadores [DF], proto TCP (6), comprimento 64)
9.9.9.9.58029> 5.6.7.8.22: Sinalizadores [S], cksum 0xaab4 (correto), seq 3399416413, win 65535, opções [mss 1460,nop,wscale 5,nop,nop,TS val 2063368865 ecr 0,sackOK ,eol], comprimento 0
Acho que a pilha TCP está descartando SYN-ACKs originados de um host diferente daquele para o qual o SYN foi enviado. Mas as regras de redirecionamento não deveriam reescrever o tráfego emambosinstruções - na verdade, não deveria keep stategarantir que a conexão seja rastreada para esse propósito?