Возникла проблема при настройке IP туннеля между двумя машинами под solaris 8. Что мы имеем: 2 машины под солярис, между которыми будет туннель, машина под linux slackware с двумя сетевыми картами (она играет роль интернета в нашей тестовой системе), и 2 машинки, которые нужно связать через тоннель.
Конфигурация такая:
linux:
eth0 inet addr:192.168.40.2 Bcast:192.168.40.255 Mask:255.255.255.0
eth1 inet addr:192.168.41.2 Bcast:192.168.41.255 Mask:255.255.255.0
solaris1:
ge0: inet 192.168.10.1 netmask ffffff00 broadcast 192.168.10.255
hme0: inet 192.168.9.1 netmask ffffff00 broadcast 192.168.9.255
hme1: inet 192.168.40.1 netmask ffffff00 broadcast 192.168.40.255solaris2:
ge0: inet 192.168.10.6 netmask ffffff00 broadcast 192.168.10.255
eri0: inet 192.168.41.1 netmask ffffff00 broadcast 192.168.41.255
lpfn0:inet 192.168.8.6 netmask ffffff00 broadcast 192.168.8.255Машинки, которые хотим связать через туннель имеют адреса 192.168.8.2 и 192.168.9.102.
Все делалось по Sun'овской доке из SysAdmin guide, т.е. выполнялись следующие команды:
на solaris1:
ifconfig ip.tun0 192.168.9.1 192.168.8.6 tsrc 192.168.40.1 tdst 192.168.41.1
ndd -set /dev/ip hme1:ip_forwarding 0
на solaris 2:
ifconfig ip.tun0 192.168.8.6 192.168.9.1 tsrc 192.168.41.1 tdst 192.168.40.1
ndd -set /dev/ip eri0:ip_forwarding 0Что получили в результате:
если на solaris1 выполняем ping 192.168.8.6, то на linux'e наблюдаем следующую картину:
192.168.40.1 > 192.168.41.1: 192.168.9.1 > 192.168.8.6: icmp: echo request (DF) (ipip-proto-4)
192.168.41.1 > 192.168.40.1: 192.168.8.6 > 192.168.9.1: icmp: echo reply (DF) (ipip-proto-4)
сделав же ping 192.168.8.2 наблюдаем следующее:
192.168.40.1 > 192.168.8.2: icmp: echo request (DF)
192.168.40.1 > 192.168.8.2: icmp: echo request (DF)
то есть пакеты пошли мимо туннеля, соответственно интерфейс eri0 на solaris2 не стал их форвардить.
Если пинговать 192.168.8.2 с 192.168.9.102, то tcpdump на linux молчит, что неудивительно - пакеты дропаются еще на интерфейсе hme1 solaris1.Вопрос банальный - что делать? ;) Поиск по sun'у да и в гугле результатов не дал. Я бы по аналогии с линуксом отправил весь трафик в нужные мне подсети через интерфейс ip.tun0, но то-ли солярис это не умеет, то-ли я просто не нашел как.
На всякий случай привожу таблицы маршрутизации:linux:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.9.0 192.168.40.1 255.255.255.0 UG 0 0 0 eth0
192.168.40.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.41.1 255.255.255.0 UG 0 0 0 eth1
192.168.41.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 losolaris1:
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.8.6 192.168.9.1 UH 1 5 ip.tun0
192.168.8.0 192.168.40.2 UG 1 9
192.168.40.0 192.168.40.1 U 1 8 hme1
192.168.41.0 192.168.40.2 UG 1 18
192.168.9.0 192.168.9.1 U 1 6 hme0
192.168.10.0 192.168.10.1 U 1 20340 ge0
192.168.20.0 192.168.10.23 UG 1 0
172.20.192.0 192.168.10.23 UG 1 2
224.0.0.0 192.168.10.1 U 1 0 ge0
default 192.168.40.2 UG 1 0
127.0.0.1 127.0.0.1 UH 43 50986 lo0solaris2:
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.9.1 192.168.8.6 UH 1 9 ip.tun0
192.168.8.0 192.168.8.6 U 1 3 lpfn0
192.168.40.0 192.168.41.2 UG 1 100
192.168.41.0 192.168.41.1 U 1 25 eri0
192.168.9.0 192.168.41.2 UG 1 2
192.168.10.0 192.168.10.6 U 1 699 ge0
224.0.0.0 192.168.10.6 U 1 0 ge0
default 192.168.10.23 UG 1 17
127.0.0.1 127.0.0.1 UH 4 10079 lo0
Разобрался, дело таки оказалось в маршрутизации. Если кому интересно, решилось следующим образом:
на solaris1:
route delete 192.168.8.0 192.168.40.2
route add -net 192.168.8.0 192.168.8.6
Ну и на solaris2 соответственно:
route delete 192.168.9.0 192.168.41.2
route add -net 192.168.9.0 192.168.9.1