Команда IT специалистов выполнит подготовку инфраструктуры для вашего бизнеса.
Внедрение самых передовых решений и технологий.
Поддержка и сопровождение ваших сервисов.
Выполнение работ под "ключ", от покупки сервера, до настройки автоматизации процессов.
8(977)608-78-62 adm@nixm.ru

Linux: Маршрутизация маркированных пакетов "Mangle"

Ответить
voker2005
Молчаливый гость
Молчаливый гость
Сообщения: 2
Зарегистрирован: 21 июл 2017, 12:33

Linux: Маршрутизация маркированных пакетов "Mangle"

Сообщение voker2005 »

Добрый день коллеги!

Хотелось поговорить на тему маршрутизации в Linux, с применением маркировки пакетов "Mangle"! Так как наткнулся на некоторые сложности. Вопрос! Раз в 1-2 дня интерфейс eth0 перестает работать в таком типе маршрутизации.

В качестве ОС: Centos 6.9 (выбрана по строгой просьбе разработчиков для их спец. софта)

eth0 - этот интерфейс смотрит в WAN, имеет внешний IP адрес, он настроен статически, должен отправлять ответы на входящие пакеты по какому пришли запросы т.е. через eth0 (на шлюз этого интерфейса XX.XX.XX.49/28).
eth1 - этот интерфейс смотрит в LAN, получает локальный адрес по DHCP, через этот интерфейс будет ходить специальный трафик веб-приложения и другой (обновления ОС, скачивание программ и т.п.).

Проще говоря: нам нужно избавиться от лишнего трафика на интерфейсе eth0 и разрешить только веб трафик.

Схема прилагается:


Изображение


Посмотрим конфигурацию сети: ifconfig

Код: Выделить всё

[root@XX-XX-XX-52 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:32:35:0A
inet addr:XX.XX.XX.52 Bcast:176.112.66.63 Mask:255.255.255.240
inet6 addr: fe80::20c:29ff:fe32:350a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:23971 errors:0 dropped:0 overruns:0 frame:0
TX packets:1123 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2348758 (2.2 MiB) TX bytes:47470 (46.3 KiB)

eth1 Link encap:Ethernet HWaddr 00:0C:29:32:35:14
inet addr:192.168.1.23 Bcast:10.100.100.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe32:3514/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:82819 errors:0 dropped:0 overruns:0 frame:0
TX packets:37082 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:26540606 (25.3 MiB) TX bytes:13099073 (12.4 MiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:51 errors:0 dropped:0 overruns:0 frame:0
TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4488 (4.3 KiB) TX bytes:4488 (4.3 KiB)
Ближе к делу

Для решения этой задачи я решил воспользоваться фунцией маркировки пакетов "mangle", т.е. маркировать все что приходит с eth0 и запихивать обратно в eth0, а по умолчанию шлюз сделать eth1 с локальным адресом 192.168.1.1

Шаг 1

Добавляю новую таблицу для запросов из интернета (для интерфейса eth0) в конец документа: /etc/iproute2/rt_tables

Выполняю в командной строке Linux:

Код: Выделить всё

 echo 200 inet_zapros >> /etc/iproute2/rt_tables
Посмотрим что получилось: cat /etc/iproute2/rt_tables

Код: Выделить всё

cat /etc/iproute2/rt_tables

# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
200     inet_zapros

Шаг 2

Чтобы ответы на пакеты уходили по тому же интерфейсу по какому пришёл запрос! Для начала нам нужно выполнить маркировку, т.е. пометить входящий трафик на eth0. Включаю маркировку пакетов INPUT:

Код: Выделить всё

iptables -t mangle -I INPUT -i eth0 -j CONNMARK --set-mark 0x1
А на исходящий трафик восстановить метку пакету, из метки всего соединения, заданного CONNMARK (но я честно немного сомневаюсь в правильности этого хода).

Код: Выделить всё

iptables -t mangle -I OUTPUT -j CONNMARK --restore-mark

Шаг 3

Запихиваю ответы обратно в eth0 -> т.е. назначаю таблицу маршрутизации (с именем inet_zapros упомянутая в Шаге 1 /etc/iproute2/rt_tables) с меткой 0x1:

Код: Выделить всё

ip route add default dev eth0 table inet_zapros
ip rule add fwmark 0x1 lookup inet_zapros
Как упоминают в некоторых статьях, о возможной необходимости сбросить кеш, сбросим:

Код: Выделить всё

ip route flush cache
И ребутнем сеть:

Код: Выделить всё

service network restart

Шаг 4

Отключаю Forwarding и rp_filter в sysctl.conf

Код: Выделить всё

# Controls IP packet forwarding
net.ipv4.ip_forward = 0
 
# Controls source route verification
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.all.rp_filter=0
Чтобы изменения вступили в силу, выполняю:

Код: Выделить всё

sysctl -p
Видим нолики, все Ок!

Код: Выделить всё

[root@ХХ-ХХ-ХХ-52 ~]# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
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
Проверка на корректное отключение Forwarding и rp_filter:

Код: Выделить всё

[root@ХХ-ХХ-ХХ-52 ~]# cat /proc/sys/net/ipv4/conf/default/forwarding
0
[root@ХХ-ХХ-ХХ-52 ~]# cat /proc/sys/net/ipv4/conf/eth0/rp_filter
0

Шаг 5

Добавим правило FireWall:

Код: Выделить всё

iptables -t mangle -A OUTPUT -m mark ! --mark 0x1 -j ACCEPT
service iptables save
service iptables restart

Шаг 6

Посмотрим на нашу маршуртизацию:

Код: Выделить всё

[root@ХХ-ХХ-ХХ-52~]# ip ro
ХХ.ХХ.ХХ.48/28 dev eth0 proto kernel scope link src ХХ.ХХ.ХХ.52
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.23
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
default via 192.168.1.1 dev eth1
Гип-гип, Ура!

И во истину, кажется все работает так как нужно! eth0 отвечает на пакеты из интернета! По дефолту весь трафик с виртуальной машины идет через локальный шлюз интерфейса eth1

Рано радуемся! Ибо неведомые грабли Внимание вопрос :)

На интерфейсе eth0 раз в 1-2 дня отваливается сеть, проблема решается ребутом виртуальной машинки (программная перезагрузка сетевых интерфейсов service network restart проблему не решает):
Вложения
shema.jpg
shema.jpg (230.84 КБ) 3420 просмотров
Последний раз редактировалось voker2005 21 июл 2017, 12:52, всего редактировалось 7 раз.
voker2005
Молчаливый гость
Молчаливый гость
Сообщения: 2
Зарегистрирован: 21 июл 2017, 12:33

Re: Linux: Маршрутизация маркированных пакетов, настраиваем

Сообщение voker2005 »

Диагностика!

Выполняю traceroute из интернета до интерфейса eth0 с адресом ХХ-ХХ-ХХ-52

Код: Выделить всё

[I]traceroute to ХХ-ХХ-ХХ-52 (ХХ-ХХ-ХХ-52), 15 hops max, 60 byte packets
 1  ovzhost88.vps.reg.ru (37.140.193.75)  0.074 ms
 2  31.31.195.2 (31.31.195.2)  0.561 ms
 3  101-194-212-88.host.exepto.ru (88.212.194.101)  72.583 ms
 4  ae9-343.RT1.M9.MSK.RU.retn.net (87.245.253.89)  0.882 ms
 5  ae9-343.RT1.M9.MSK.RU.retn.net (87.245.253.89)  0.839 ms
 6  GW-TransTeleCom.retn.net (87.245.249.47)  23.070 ms
 7  nnd02.transtelecom.net (217.150.50.254)  29.888 ms
 8  TTK-NN-gw.transtelecom.net (217.150.50.253)  32.045 ms
 9  212.XXX.16.200 (212.XXX.16.200)  29.172 ms
10  10.10.0.104 (10.10.0.104)  29.282 ms
11  10.10.0.104 (10.10.0.104)  29.243 ms
12  *
13  *
14  *
15  * [/I]

Выполняю traceroute через интерфейс eth0 с линуксовой машинки с которой проблемы: traceroute --interface=eth0 8.8.8.8

Код: Выделить всё

[root@ХХ-ХХ-ХХ-52 ~]# traceroute --interface=eth0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * *^C
[root@ХХ-ХХ-ХХ-52 ~]#

Смотрю TCP Dump eth0: tcpdump -v -i eth0

Код: Выделить всё

[root@ХХ-ХХ-ХХ-52 ~]# tcpdump -v -i eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:46:29.757200 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:30.757007 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:31.757123 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:34.762194 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:35.762151 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:36.762063 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:39.768220 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:40.768138 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:41.768140 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:44.772197 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:45.772135 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
15:46:46.772055 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has google-public-dns-a.google.com tell ХХ-ХХ-ХХ-52, length 28
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
Выполняю пинг с роутера (шлюза) XX.XX.XX.49 до eth0 XX.XX.XX.52

Код: Выделить всё

[admin@MikroTik] > ping XX.XX.XX.52
SEQ HOST SIZE TTL TIME STATUS 
0 XX.XX.XX.52 56 64 0ms 
1 XX.XX.XX.52 56 64 0ms 
2 XX.XX.XX.52 56 64 0ms 
3 XX.XX.XX.52 56 64 0ms 
4 XX.XX.XX.52 56 64 0ms 
5 XX.XX.XX.52 56 64 0ms 
sent=6 received=6 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms
Пакеты ходят, это еще одно подтверждение что интерфейс не завис.

Посмотрим TCPDump на eth0: tcpdump -v -i eth0

Код: Выделить всё

[root@ХХ-ХХ-ХХ-52 ~]# tcpdump -v -i eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:05:22.032210 IP (tos 0x0, ttl 255, id 45464, offset 0, flags [none], proto ICMP (1), length 56)
ХХ-ХХ-ХХ-49.mygateway.com > XX.XX.XX.52: ICMP echo request, id 33827, seq 15360, length 36
16:05:22.032240 IP (tos 0x0, ttl 64, id 23693, offset 0, flags [none], proto ICMP (1), length 56)
XX.XX.XX.52 > ХХ-ХХ-ХХ-49.mygateway.com: ICMP echo reply, id 33827, seq 15360, length 36
16:05:23.034475 IP (tos 0x0, ttl 255, id 45465, offset 0, flags [none], proto ICMP (1), length 56)
^C

К итогу!


Исходя из вывода TCPDump при выполнении tracerote через eth0 мы видим:
Xост ХХ-ХХ-ХХ-52 запрашивает по протоколу ARP, где находится хост 8.8.8.8. Ввиду того, что ARP предназначен несколько для других целей, естественно ответа не получает и не знает, куда слать трафик.

В какой то точке зрения решение!

Делаю так, меняю шлюз по умолчанию на адрес XX.XX.XX.49 (это шлюз для eth0) и все моментально начинает работать:

Код: Выделить всё

ip ro del default
ip ro add default via XX.XX.XX.49
Но в таком случае вся наша пляска с бубнами выше не имела никакого смысла, мне нужно чтобы весь трафик с Linux машинки по умолчанию ходил через eth1, а eth0 отвечал на запросы из интернета, в настоящей схеме\конфигурации, работает 1-2 дня, потом пакеты из интернета до eth0 перестают доходить


FYI - For Your Information

Общался с ведущим инженером провайдера, проблему на их стороне исключают и рекомендуют отказаться от маршрутизации с функцией меток пакетов "mangle", посоветовав мне, что при необходимости изменить топологию и пользоваться лишь стандартным типом маршрутизации. Но я считаю что отказываться ненужно, нужно просто разобраться и правильно настроить! Легкие пути не для нас, легкость может измеряться тысячами долларов :)
Аватара пользователя
Oleg65
Местный говорун
Местный говорун
Сообщения: 859
Зарегистрирован: 18 янв 2015, 10:56
Откуда: г.Коломна Моск.обл.

Re: Linux: Маршрутизация маркированных пакетов "Mangle"

Сообщение Oleg65 »

Проблема м.б. в не нормально работающей виртуалке? И... что используется - Network Manager? На серваке на работе NM снесен, ifconfig работает (сервер на Debian)...
Ответить

Вернуться в «Сети. Настройка и администрирование»