Трафик маршрута через частный IP только для определенных хостов - CentOS 6.6

У меня есть странная проблема, которую я не могу выяснить - таким образом, я надеялся, что кто-то здесь мог дать мне руку.

Прежде всего конечная цель - то, что определенный сервер в моей сети выполняет соединение IPsec в другую компанию, и я хочу, чтобы все другие серверы направили трафик для IP в той сети через этот единственный сервер.

Сервер 1 в этом примере является сервером, который выполняет соединение IPsec. (CentOS 6.6)

Сервер 2 в этом примере является сервером приложений, который направил бы трафик для только что определенный IP через сервер 1. (CentOS 6.5)

Некоторый IP, который будет использоваться ниже:

Сервер 1

Server 1 Public IP: x.x.x.x
Server 1 Public Broadcast: x.x.x.y
Server 1 Public Gateway: x.x.x.z
Server 1 Internal IP: 10.0.64.10/24

Сервер 2

Server 2 Public IP: y.y.y.y
Server 2 Public Broadcast: y.y.y.z
Server 2 Public Gateway: y.y.y.a
Server 2 Internal IP: 10.0.64.150/24

Те серверы имеют полную возможность соединения между ними внутренне (т.е. Я могу проверить с помощью ping-запросов, ssh и т.д. от одного до другого без проблемы). Они также оба имеют полный доступ к Интернету и могут быть достигнуты тот путь

Сервер 1

Вот IP для этого

# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:99:12:85 brd ff:ff:ff:ff:ff:ff
    inet x.x.x.x/28 brd x.x.x.y scope global eth0
    inet6 xxxx:xxxx:xxxx:xxxx/64 scope link
       valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:99:12:8f brd ff:ff:ff:ff:ff:ff
    inet 10.0.64.10/24 brd 10.0.64.255 scope global eth1
    inet6 fe80::20c:29ff:fe99:128f/64 scope link
       valid_lft forever preferred_lft forever

Вот IP маршрут

# ip route
x.x.x.y/28 dev eth0  proto kernel  scope link  src x.x.x.x
10.0.64.0/24 dev eth1  proto kernel  scope link  src 10.0.64.10
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
default via x.x.x.z dev eth0

Вот sysctl-p

# sysctl -p
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.default.proxy_arp = 1
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 1

Сервер 2

Я добавил единственный тестовый IP (8.8.8.8) к серверу два, чтобы протестировать, если он работает прежде, чем принести IPSEC в уравнение

Вот IP a

# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:0c:29:15:8b:01 brd ff:ff:ff:ff:ff:ff
    inet y.y.y.y/29 brd y.y.y.z scope global eth0
    inet6 fe80::20c:29ff:fe15:8b01/64 scope link
       valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:0c:29:15:8b:0b brd ff:ff:ff:ff:ff:ff
    inet 10.0.64.150/24 brd 10.0.64.255 scope global eth1
    inet6 fe80::20c:29ff:fe15:8b0b/64 scope link
       valid_lft forever preferred_lft forever

Вот IP маршрут

# ip route
8.8.8.8 via 10.0.64.10 dev eth1
y.y.y.z/29 dev eth0  proto kernel  scope link  src y.y.y.y
10.0.64.0/24 dev eth1  proto kernel  scope link  src 10.0.64.150
default via y.y.y.a dev eth0

Теперь, когда я пробую, делают ping с Сервера 2-> 8.8.8.8 вот является tcpdumps с каждого сервера:

Сервер 2

Если я tcpdump на eth0, я не получаю соответствий (таким образом, маршрут кажется правильным!). eth1 получает соответствия:

# tcpdump -vvv -i eth1 -n host 8.8.8.8
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
11:25:55.609902 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.64.150 > 8.8.8.8: ICMP echo request, id 17999, seq 1, length 64
11:25:56.609262 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.64.150 > 8.8.8.8: ICMP echo request, id 17999, seq 2, length 64

Сервер 1 (Обнадеживающий шлюз для 8.8.8.8)

На (Частном) eth1

# tcpdump -vv -i eth1 -n host 8.8.8.8
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

11:27:20.608766 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.64.150 > 8.8.8.8: ICMP echo request, id 17999, seq 86, length 64
11:27:21.608738 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.64.150 > 8.8.8.8: ICMP echo request, id 17999, seq 87, length 64

На eth0 (общественность)

# tcpdump -vv -i eth0 -n host 8.8.8.8
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:29:04.608773 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.64.150 > 8.8.8.8: ICMP echo request, id 17999, seq 190, length 64
11:29:05.608800 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.64.150 > 8.8.8.8: ICMP echo request, id 17999, seq 191, length 64

Я отключил FW на обоих (как тест), удостоверился, что не имел любые правила блокирования о, ПЕРЕДАЮТ трафик (как отдельный тест), и я просто никогда не передаю свой трафик с Сервера 2 к 8.8.8.8. Я также попытался заменить 8.8.8.8 другой сервер, который достижим с обоих серверов, и то же самое происходит.

Я открыт для любых предложений - я супер смущен :)

Заранее спасибо, Ian