Не удается подключиться к многодомной Ubuntu из другой подсети
У меня есть многодомный сервер Ubuntu 12.04. У меня есть два сетевых интерфейса, подключенных к двум различным диапазонам IP.
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 190.113.X.X/29 brd 190.113.98.183 scope global eth1
(...)
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 10.100.100.21/24 brd 10.100.100.255 scope global eth0
(...)
Всякий раз, когда я пытаюсь получить доступ к серверу по ссылке eth0 из другой подсети, не относящейся к 10.100.100.X
сеть я не получаю ответа. я имею iptables
работает на сервере (если у него есть общедоступный IP-адрес в eth1), но я разрешаю весь трафик из частной сети по каналу eth0.
Если я сделаю tcpdump
на интерфейсе на сервере у меня есть это (мой компьютер 10.100.102.22
):
18:30:23.813889 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.100.102.22 tell 10.100.100.21, length 28
18:30:24.810691 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.100.102.22 tell 10.100.100.21, length 28
18:30:25.810718 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.100.102.22 tell 10.100.100.21, length 28
Я могу пинг с сервера на мой компьютер:
PING 10.100.102.22 (10.100.102.22) 56(84) bytes of data.
64 bytes from 10.100.102.22: icmp_req=1 ttl=63 time=0.273 ms
64 bytes from 10.100.102.22: icmp_req=2 ttl=63 time=0.324 ms
Таблица маршрутизации выглядит следующим образом: Таблица 1:
default via 10.100.100.1 dev eth0
10.0.0.0/8 dev eth0 scope link src 10.100.100.21
Таблица 2:
default via 190.113.X.X dev eth1
190.113.X.X/29 dev eth1 scope link src 190.113.X.X
По умолчанию:
default via 10.100.100.1 dev eth0 metric 100
10.100.100.0/24 dev eth0 proto kernel scope link src 10.100.100.21
190.113.X.X/29 dev eth1 proto kernel scope link src 190.113.X.X
1 ответ
Клиент также должен знать маршрут к сети 10.100.100.0/24.
поэтому вам нужно либо добавить маршрут на клиенте
ip r a 10.100.100.0/24 via 10.100.100.1 dev eth0
или вам нужно добавить маршрут на шлюз по умолчанию, который использует клиент.
Вы можете думать об этом так: клиент должен знать, как достичь 10.100.100.21, если он этого не делает, он попробует шлюз по умолчанию, если шлюз не знает, вам не повезло.