Мы перемещаем кучу сервисов, скажем, из 1.2.3.4 к 5.6.7.8.
Чтобы проверить правильность настройки новых служб, мы хотели бы перенаправить (на новый хост) весь трафик, предназначенный для исходного хоста, который исходит от наших тестовых рабочих станций.
Конечно, такое перенаправление мог быть реализованным на маршрутизаторах в самой сети, но по соображениям стабильности мы решили реализовать его на каждой рабочей станции напрямую (все они являются OS X 10.10 Yosemite, поэтому используйте OpenBSD pf до v4.7).
Я добавил к /etc/pf.anchors/com.apple:
rdr-anchor "910.TestServiceMove/*"
anchor "910.TestServiceMove/*"
load anchor "910.TestServiceMove" from "/etc/pf.anchors/910.TestServiceMove"
И создал /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
Когда правила загружены, оба работают правильно:
$ sudo tcpdump -v -n -e -ttt -i pflog0
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes
00:00:00.000000 rule 0.910.TestServiceMove.0/0(match): pass out on en1: (tos 0x0, ttl 64, id 40691, offset 0, flags [DF], proto TCP (6), length 64)
9.9.9.9.58029 > 1.2.3.4.22: Flags [S], cksum 0x291a (correct), seq 3399416413, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK,eol], length 0
00:00:00.000047 rule 0/0(match): rdr in on lo0: (tos 0x0, ttl 64, id 40691, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 896a (->b4da)!)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xb284 (correct), seq 3399416413, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK,eol], length 0
Но рукопожатие TCP не завершается (SYN-ACK игнорируются, и SYN повторно отправляется, пока не истечет время ожидания соединения):
$ sudo tcpdump -v -n -e -ttt host 5.6.7.8
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Packet Tap), capture size 65535 bytes
00:00:00.000000 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 63, id 40691, offset 0, flags [DF], proto TCP (6), length 64)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xb284 (correct), seq 3399416413, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 2063366865 ecr 0,sackOK,eol], length 0
00:00:00.015524 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 60)
5.6.7.8.22 > 9.9.9.9.58029: Flags [S.], cksum 0x7ce4 (correct), seq 1901846890, ack 3399416414, win 14480, options [mss 1460,sackOK,TS val 523934721 ecr 2063366865,nop,wscale 7], length 0
00:00:00.986946 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 63, id 25319, offset 0, flags [DF], proto TCP (6), length 64)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xae9c (correct), seq 3399416413, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 2063367865 ecr 0,sackOK,eol], length 0
00:00:00.014938 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 60)
5.6.7.8.22 > 9.9.9.9.58029: Flags [S.], cksum 0x78fa (correct), seq 1901846890, ack 3399416414, win 14480, options [mss 1460,sackOK,TS val 523935723 ecr 2063366865,nop,wscale 7], length 0
00:00:00.397794 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 60)
5.6.7.8.22 > 9.9.9.9.58029: Flags [S.], cksum 0x776c (correct), seq 1901846890, ack 3399416414, win 14480, options [mss 1460,sackOK,TS val 523936121 ecr 2063366865,nop,wscale 7], length 0
00:00:00.588237 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 63, id 50201, offset 0, flags [DF], proto TCP (6), length 64)
9.9.9.9.58029 > 5.6.7.8.22: Flags [S], cksum 0xaab4 (correct), seq 3399416413, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 2063368865 ecr 0,sackOK,eol], length 0
Я предполагаю, что стек TCP отбрасывает SYN-ACK, которые исходят от хоста, отличного от того, на который был отправлен SYN. Но правила перенаправления не должны переписывать трафик в обе направления - действительно, не должно keep state быть уверенным, что соединение отслеживается для этой цели?
Разве не было бы проще поместить машины за простой балансировщик нагрузки или NAT? Во всяком случае, это, как правило, более стандартная практика, которая позволит вам со временем масштабировать приложение.
Если все службы, к которым вы получаете доступ, доступны по имени, я бы просто создал запись хоста в файле hosts на ваших машинах разработчика.
Например, если ваш компьютер назывался myserver и получил разрешение 1.2.3.4, то теперь вы можете создать запись файла хоста / etc / hosts с помощью
мойсервер 5.6.7.8
Все, что сейчас пытается достичь моего сервера, в конечном итоге попадет на новую машину.
В качестве альтернативы просто создайте новую изолированную сеть с новым сервером по старому адресу и подключите к ней свою машину разработчика для тестирования.
Проблема с прямым перенаправлением или правилом маршрутизации заключается в том, что новый сервер не отвечает под именем старого адреса. Так что вам придется использовать NAT.
Можете ли вы просто предложить "старый" адрес из "нового" субинтерфейса аля сервера, или новый адрес находится в совершенно другой подсети?
Если вы не можете прикрепить новый IP-адрес к новому серверу, значит, вы действительно не переместили адрес. Чтобы направить трафик через старый адрес на новый сервер, вам необходимо преобразовать адрес в старой подсети через NAT. Трафик будет попадать на «старый» адрес, а затем переадресовываться через NAT источника на новый адрес на том же сервере / устройстве и отправляться на «новый» IP. Затем обратный трафик будет передаваться обратно на адрес SNAT, который отключит NAT от трафика и вернет его исходной запрашивающей стороне. Это действительно не очень хорошее долгосрочное решение, особенно если «новый» адрес находится через канал WAN. Вы предотвратили неизбежный сбой и добавили задержку в микс.
Лучшим долгосрочным решением было бы рассмотреть: 1. использовать DNS вместо IP. 2. виртуализировать либо IP-адрес (устройство NAT, например брандмауэр или ipmasq), 3. или сам сервер (балансировщик нагрузки).