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

Не понятна маршрутизация ip route


0

1

Имеется интерфейс с внешним IP и один интерфейс pppoe. Вдобавок две сетевые, смотрящими в две локальные сети: 

eth0      Link encap:Ethernet  HWaddr 00:44:55:66:ff:e1  
          inet addr:192.168.4.2  Bcast:192.168.4.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14120544 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8151690 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:20026916706 (20.0 GB)  TX bytes:1029229328 (1.0 GB)
          Interrupt:20 

eth1      Link encap:Ethernet  HWaddr 00:44:55:66:77:22  
          inet addr:192.168.1.242  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10801053 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15673177 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3214827795 (3.2 GB)  TX bytes:20107578428 (20.1 GB)
          Interrupt:44 Base address:0x8000 

eth1:1    Link encap:Ethernet  HWaddr 00:44:55:66:77:22  
          inet addr:10.1.1.2  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:44 Base address:0x8000 

eth2      Link encap:Ethernet  HWaddr 00:44:55:66:11:11  
          inet addr:11.22.33.44  Bcast:11.22.33.44  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1372  Metric:1
          RX packets:765444 errors:0 dropped:0 overruns:0 frame:0
          TX packets:936019 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:168304895 (168.3 MB)  TX bytes:673732402 (673.7 MB)
          Interrupt:19 Base address:0x2000 

lo        Link encap:Локальная петля (Loopback)  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:915 errors:0 dropped:0 overruns:0 frame:0
          TX packets:915 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:95395 (95.3 KB)  TX bytes:95395 (95.3 KB)

ppp0      Link encap:Протокол PPP (Point-to-Point Protocol)  
          inet addr:55.55.55.55  P-t-P:77.77.77.77  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:14118582 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8149724 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:19659702274 (19.6 GB)  TX bytes:817205129 (817.2 MB)

Суть маршрутизации сводится к тому, чтобы основной трафик ходил через ppp0. А внешний 11.22.33.44 обслуживает web-сервер и IPSec. То есть, пакеты, поступившие на него, должны с него же и уходить. Плюс ко всему, трафик на некоторые адреса, которые записываются в iptables должны ходить через 11.22.33.44. 

# ip route
default dev ppp0  scope link 
10.1.1.0/24 dev eth1  proto kernel  scope link  src 10.1.1.2 
77.77.77.77 dev ppp0  proto kernel  scope link  src 55.55.55.55 
11.22.33.0/24 dev eth2  proto kernel  scope link  src 11.22.33.44 
172.16.130.0/24 via 172.16.130.2 dev tun0 
172.16.130.2 dev tun0  proto kernel  scope link  src 172.16.130.1 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.242 
192.168.3.0/24 dev eth2  scope link  src 192.168.1.242 
192.168.4.0/24 dev eth0  proto kernel  scope link  src 192.168.4.2 

# ip rule
0:	from all lookup local 
32764:	from all fwmark 0xa lookup 100 
32765:	from 11.22.33.44 lookup 100 
32766:	from all lookup main 
32767:	from all lookup default 

# ip route show table 100
default via 11.22.33.44 dev eth2 
192.168.1.0/24 via 192.168.1.242 dev eth1

В iptables делается маскарадинг на всё, кроме подсети 192.168.3.0/24, которая подключена через IPSec. Плюс имеется список адресов, которые помечаются маркером 0xa, чтобы уйти через интерфейс 11.22.33.44. Плюс, входящие соединения на 11.22.33.44 при помощи CONNMARK помечаются тем же 0xa, чтобы ответ на них уходил правильно.

До недавнего времени всё работало идеально. Но в один момент отвалилась IPSec. И перестали ходить пинги на те адреса из iptables. Проверка показала, что перестал идти и такой пинг: 

# ping -I eth2 8.8.8.8
При общении с техподдержкой провайдера выяснилось, что нужно указывать в качестве default route адрес 11.22.33.1. Взял виндовый компьютер, проверил - действительно, если задать статические настройки, то всё работает сразу. На моём же серваке ситуация не улучшилась.

Попробовал заменить в 100 таблице маршрут по-умолчанию: 

# ip route show table 100
default via 11.22.33.1 dev eth2 
192.168.1.0/24 via 192.168.1.242 dev eth1

IPSec стала работать. Пинги на список адресов стали ходить. Но только на них. Если же сделать 

# ping -I eth2 8.8.8.8
то опять же, никто никуда не уходит. В tcpdump сообщения такие: 
10:20:32.592759 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 8.8.8.8 tell 11.22.33.44, length 28
10:20:33.589528 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 8.8.8.8 tell 11.22.33.44, length 28
10:20:34.589527 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 8.8.8.8 tell 11.22.33.44, length 28
10:20:35.606686 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 8.8.8.8 tell 11.22.33.44, length 28
Вместо 8.8.8.8 может быть любой адрес, которого нет в списке iptables.

Сообщение бы и не публиковал, если бы IPSec не отваливалась каждый час. Грешу на маршрутизацию.

Как задать дефолтный маршрут при пинге с конкретного интерфейса, если default route итак уже имеется в системе, но через другой интерфейс (в данном случае ppp0)?

Вот iptables: 

#!/sbin/iptables-restore

# Generated by iptables-save v1.4.12 on Sat Sep 14 18:44:55 2013
*mangle
:PREROUTING ACCEPT [3536:933906]
:INPUT ACCEPT [534:653649]
:FORWARD ACCEPT [3002:280257]
:OUTPUT ACCEPT [508:170349]
:POSTROUTING ACCEPT [3510:450606]
:LIST_IP - [0:0]
-A PREROUTING -s 192.168.1.0/24 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A PREROUTING -s 10.1.1.0/24 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A PREROUTING -d 11.22.33.44/32 -m state --state NEW -j CONNMARK --set-xmark 0xa/0xffffffff
-A PREROUTING -s 192.168.1.0/24 -d 213.180.204.11/32 -j LIST_IP
-A PREROUTING -s 192.168.1.0/24 -d 93.158.134.11/32 -j LIST_IP
-A PREROUTING -s 192.168.1.0/24 -d 213.180.193.11/32 -j LIST_IP
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu
-A OUTPUT -d 178.159.255.97/32 -j LIST_IP
-A OUTPUT -d 93.158.134.11/32 -j LIST_IP
-A OUTPUT -d 213.180.193.11/32 -j LIST_IP
-A LIST_IP -s 192.168.1.210/32 -j RETURN
-A LIST_IP -s 192.168.1.211/32 -j RETURN
-A LIST_IP -j MARK --set-xmark 0xa/0xffffffff
COMMIT
# Completed on Sat Sep 14 18:44:55 2013
# Generated by iptables-save v1.4.12 on Sat Sep 14 18:44:55 2013
*nat
:PREROUTING ACCEPT [309:22196]
:INPUT ACCEPT [277:20360]
:OUTPUT ACCEPT [205:12448]
:POSTROUTING ACCEPT [0:0]
:ROUTING - [0:0]
-A PREROUTING -d 11.22.33.44/32 -p tcp -m tcp --dport 111 -j DNAT --to-destination 10.1.1.1:443
-A PREROUTING -d 11.22.33.44/32 -p tcp -m tcp --dport 222 -j DNAT --to-destination 10.1.1.1:80
-A PREROUTING -d 11.22.33.44/32 -p tcp -m tcp --dport 333 -j DNAT --to-destination 192.168.1.111:902
-A POSTROUTING -j ROUTING
-A ROUTING -d 192.168.3.0/24 -j RETURN
-A ROUTING -j MASQUERADE
COMMIT
# Completed on Sat Sep 14 18:44:55 2013
# Generated by iptables-save v1.4.12 on Sat Sep 14 18:44:55 2013
*filter
:INPUT ACCEPT [3625:3767322]
:FORWARD ACCEPT [6001:470080]
:OUTPUT ACCEPT [3392:998412]
COMMIT
# Completed on Sat Sep 14 18:44:55 2013

← CentOS 6.4 & Squid- ошибки при запуске.
IPTV за шлюзом Centos 6.4 →

[qoute]Как задать дефолтный маршрут при пинге с конкретного интерфейса, если default route итак уже имеется в системе, но через другой интерфейс (в данном случае ppp0)? 

route add -host 8.8.8.8 gw 11.22.33.1 eth2

И тогда уже

ping -I eth2 8.8.8.8
adxfighter
()

Или попробуй 

iptables -A PREROUTING -d 8.8.8.8 -m state --state NEW -j CONNMARK --set-xmark 0xa

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

В таком случае абсолютно все пакеты на 8.8.8.8 будут ходить через 11.22.33.1 eth2. У меня же по условию все пакеты должны ходить через ppp0, кроме тех случаев когда я посылаю пинги с eth2

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

так не получится. твой пинг из таблицы main уходит. и ему без разницы -I eth2. Он смотрит маршрут в таблице main. Сам ты не сможешь выбрать интерфейс, с которого пинг посылать, ИМХО.

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

Так вот меня и терзают смутные сомнения. Дело в том, что в правилах есть строка: 

32765:	from 11.22.33.44 lookup 100

Когда я делаю пинг, то в первой строке явно написано: 

# ping -I eth2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 11.22.33.44 eth2: 56(84) bytes of data.
то есть, если пакет уходит с адреса 11.22.33.44, он по-идее должен завернуть в таблицу 100. Но то ли не делает етого, то ли что-то я не учёл.

Причём, щё вчера утром первоначальная конфигурация работала. И ей без малого полтора года. Я пробовал перезагружать шлюз, чистить cache. Не помогает.

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

Если делать пинг на адреса из iptables, которые должны идти через eth2, то там всё нормально: 

# ping -I eth2 213.180.204.11
PING 213.180.204.11 (213.180.204.11) from 11.22.33.44 eth2: 56(84) bytes of data.
64 bytes from 213.180.204.11 (213.180.204.11): icmp_req=1 ttl=57 time=30.2 ms

Но тут срабатывает правило 

32764:	from all fwmark 0xa lookup 100
поскольку в iptables етот адрес отмечается маркером 0xa

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

Проблема в том, что связь рвется? Ты говоришь, что конфигурация давно работала.

При общении с техподдержкой провайдера выяснилось, что нужно указывать в качестве default route адрес 11.22.33.1. Попробовал заменить в 100 таблице маршрут по-умолчанию

А как же работало без: 

default via 11.22.33.1 dev eth2
???

В качестве танца с бубном попробуй добавить: 

ip route add 11.22.33.0/24 dev eth2 src 11.22.33.44 table 100

rp_filter отключен на ВСЕХ интерфейсах?

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

А как же работало без

Хороший вопрос. Со вчерашнего пытаюсь на него ответить. Вот так и работало без default route

rp_filter отключен на ВСЕХ интерфейсах?

Стоял только net.ipv4.conf.all.rp_filter=2

Счас выключил остальные. Пока без изменений. Но подожду, вырубится ли IPSec или нет. Пинги с eth2 пока что также не идут

abr_linux ★
() автор топика
Последнее исправление: abr_linux (всего исправлений: 1)
Ответ на: комментарий от abr_linux

[qoute] Хороший вопрос. Со вчерашнего пытаюсь на него ответить. Вот так и работало без default route

И у тебя было вот что:

default via 11.22.33.44 dev eth2

С этим работало?

А как при перезагрузке поднимаются маршруты? Скрипт есть какой-нибудь?

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

С этим работало?

Вот именно с етим и работало.

Потом, когда канал отвалился я поставил 11.22.33.1. Канал заработал, а пинги с eth2 не идут.

Счас щё заметил broadcast неправильный. Но пока всё работает експериментировать не хочу. Если только поздно вечером

abr_linux ★
() автор топика

Для альтернативных таблиц маршрутизации надо указывать link-local маршруты. В твоем случае: 

ip route add 11.22.33.0/24 dev eth2 src 11.22.33.44 table 100
Заодно добавь еще это: 
ip rule add to 11.22.33.44 table 100
иначе rp_filter может начать дропать пакеты

anonymous
()
26 декабря 2013 г.

В общем, долго даже и не пытался разобратся. А сегодня на глаза попала статья в инете по параметрам ip rule.

Стоило добавить 

# ip rule add oif eth2 lookup 100
как всё заработало.

abr_linux ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← CentOS 6.4 & Squid- ошибки при запуске.
Admin
IPTV за шлюзом Centos 6.4 →