LINUX.ORG.RU
решено Форум — Admin  

Не работает маршрутизация

 ,


0

2

Поднимаю новый шлюз на HP DL180 G5 + Intel Corporation 82580 Gigabit Network Connection (rev 01) (4хпортовая сетевая карточка). В качестве ОС Debian 8.4.

Включил и настроил маршрутизацию. 

#cat /proc/sys/net/ipv4/ip_forward
1
#ip r s
default via 192.168.7.3 dev eth2
10.0.10.0/24 via 192.169.210.1 dev eth3
172.21.102.144 via 192.169.210.1 dev eth3
192.168.7.0/24 dev eth2  proto kernel  scope link  src 192.168.7.7
192.168.200.0/24 via 192.169.210.1 dev eth3
192.169.210.0/24 dev eth3  proto kernel  scope link  src 192.169.210.6

  • eth2 - ЛВС
  • eth3 - смотрит на чужой шлюз
  • где 192.169.210.1 это чужой шлюз.
  • default via 192.168.7.3 dev eth2 - выход в интернет ч-з старый шлюз

Проблема: Сама машина может пропинговать чужой шлюз, но при этом машины из ЛВС не могут сделать того же. Трасинг прерывается на новом шлюзе. При этом старый шлюз с ~ такими же настройками работает норм.

Как продиагностировать? И исправить?

★★★★

Последнее исправление: leonidko (всего исправлений: 1)
← Не работает отправка IGMP report
Не работает двойной проброс портов →

Этот «чужой шлюз» знает про маршрут на ЛВС через 192.169.210.6 ? Что показывает tcpdump на eth3 ? Обратно icmp-ответы прилетают ?

AS ★★★★★
()
Ответ на: комментарий от AS 
$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:21:5a:e0:c1:13 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:1b:21:a6:61:38 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:1b:21:a6:61:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.7/24 brd 192.168.7.255 scope global eth2
       valid_lft forever preferred_lft forever
    inet6 fe80::21b:21ff:fea6:6139/64 scope link
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:1b:21:a6:61:3a brd ff:ff:ff:ff:ff:ff
    inet 192.169.210.6/24 brd 192.169.210.255 scope global eth3
       valid_lft forever preferred_lft forever
    inet6 fe80::21b:21ff:fea6:613a/64 scope link
       valid_lft forever preferred_lft forever
leonidko ★★★★
() автор топика
Ответ на: комментарий от AS

Чужой шлюз от слова совсем чужой. Нам даден только адрес его интерфейса смотрящего на нас и только.

leonidko ★★★★
() автор топика
Ответ на: комментарий от leonidko

Если пингануть чужой шлюз из ЛВС ?

да.

Чужой шлюз от слова совсем чужой. Нам даден только
адрес его интерфейса смотрящего на нас и только.

Если там про ЛВС не знают, то только NAT.

AS ★★★★★
()
Ответ на: комментарий от AS 
# tcpdump -i eth3 > /var/log/tcpdump.`date +%Y%m%d%H%M`.log
# grep 192.168.7.4 /var/log/tcpdump.201605301329.log
13:32:13.912794 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 3, length 40
13:32:18.882224 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 4, length 40
13:32:23.881797 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 5, length 40
13:32:28.881936 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 6, length 40
13:32:33.881921 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 7, length 40
13:32:38.881136 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 8, length 40
13:32:43.881555 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 9, length 40
13:32:48.881751 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 10, length 40
13:32:53.881986 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 11, length 40
13:32:58.882885 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 12, length 40
13:33:03.884089 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 13, length 40
13:33:08.884374 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 14, length 40
13:33:13.883537 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 15, length 40
leonidko ★★★★
() автор топика
Ответ на: комментарий от AS

Если там про ЛВС не знают, то только NAT.

# sudo iptables -L -t nat
....
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere

Если, конечно, я правильно разобрался с NAT.

leonidko ★★★★
() автор топика
Ответ на: комментарий от leonidko

13:32:53.881986 IP 192.168.7.4 > 192.169.210.1: ICMP echo request, id 1, seq 11, length 40

Ну вот. Обратных пакетов нет.

AS ★★★★★
() 
# iptables -F -t nat
# iptables -t nat -A POSTROUTING -o eth3 -j MASQUERADE

И заработало. Осталось понять какое правило перенесённое iptables-save указанное выше не давало проходу пакетам.

ИЧСХ всё на старом шлюзе работает.

leonidko ★★★★
() автор топика
Ответ на: комментарий от leonidko

ИЧСХ всё на старом шлюзе работает.

Значит на «старом» было не тоже самое. Смотрим diff настроек и названия интерфейсов.

anc ★★★★★
()
Ответ на: комментарий от leonidko

Осталось понять какое правило перенесённое iptables-save указанное выше не давало проходу пакетам.

Может, не было NAT для eth3 ? Стоило смотреть с -v, тогда ещё привязка к интерфейсам показывается и счётчики.

AS ★★★★★
()
Ответ на: комментарий от AS

Там и в самом деле был включён маскарадинг на конкретные интерфейсы.

Как обычно, знал бы где стукнуть, уже б починил.

leonidko ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Не работает отправка IGMP report
Admin
Не работает двойной проброс портов →