Sys-Admin Forum

Маршрутизация 2-ух сетей на Linux + настройка Apache 2.2.15

Добрый день.

Коллеги, прошу помочь разобраться в настройках маршрутизации Linux.


Имею свеже установленный Centos 6.9 (образ с оф.сайта), а на борту: Apache 2.2.15 (из репозитория)
(Centos 6.9 выбран не случайно, есть для этого строгая просьба разработчиков проекта)

! IP адреса в этой схеме вымышленные, но логически аналогичны моей задаче.

eth0 - этот интерфейс смотрит в WAN, имеет внешний IP адрес, онпрописан статически, в iptables (фаерволл) все запрещено кроме 80 (HTTP) и 443 (HTTPS) порта.
eth1 - этот интерфейс смотрит в LAN, через этот интерфейс администраторы/разработчики будут подключаться по SSH, адреса получает по DHCP, в iptables (фаерволл) все запрещено кроме 80 (HTTP), 443 (HTTPS), 22(SSH), порта.

[table]
[tr]
[td]
eth0
[size=3pt]

  • для WAN
    [/size]
    Конфиг файл: /etc/sysconfig/network-scripts/ifcfg-eth0[/td]
    [td]
    eth1
    [size=3pt]
  • для LAN внутри NAT
    [/size]
    Конфиг файл: /etc/sysconfig/network-scripts/ifcfg-eth1[/td]
    [/tr]
    [tr]
    [td]
    DEVICE=eth0
    HWADDR=00:0C:29:F8:21:98
    TYPE=Ethernet
    UUID=5819a695-09bc-4155-8c22-30700e0bc12f
    ONBOOT=yes
    NM_CONTROLLED=no
    BOOTPROTO=none
    IPADDR=XX.XX.XX.52
    NETMASK=255.255.255.240
    GATEWAY=XX.XX.XX.49
    DNS1=8.8.8.8
    DNS2=8.8.4.4
    IPV6INIT=no
    USERCTL=no
    [/td]
    [td]
    DEVICE=eth1
    HWADDR=00:0C:29:F8:21:A2
    TYPE=Ethernet
    UUID=be7224a2-460e-45fd-8f0e-eb96594eaf8c
    ONBOOT=yes
    NM_CONTROLLED=yes
    BOOTPROTO=dhcp

    Полученный адрес: 10.1.1.5

    [/td]
    [/tr]
    [/table]

Задача!

  1. Нужно чтобы весь интернет 0.0.0.0/0 - этот сервер обслуживал только через eth0 по портам 80 и 443.
  2. Весь остальной трафик (обновления ОС, скачивание программ из интернета и т.п.), в том числе локальный трафик 10.1.1.0/24 и 10.2.2.0/24 обслуживался интерфейсом eth1.

Сейчас веб сервер Apache в дефолтной конфигурации отвечает в браузере только по локальному адресу (с интерфейса eth1): http://10.1.1.5
Адрес XX.XX.XX.52 на интерфейсе eth0 из интернета не пингуется и в браузере http://XX.XX.XX.52 не открывается. Если выключить интерфейс eth1 (локальной сети), адрес XX.XX.XX.52 из интернета начинает пинговаться, а также доступен по HTTP.

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

Route -n


[[email protected] network-scripts]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
XX.XX.XX.48     0.0.0.0         255.255.255.240 U     0      0        0 eth0
10.1.1.0        0.0.0.0         255.255.255.0   U     0        0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0         0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0         0 eth1
0.0.0.0        10.1.1.1         0.0.0.0         UG      0       0         0 eth1

ip a


1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:0c:29:62:84:54 brd ff:ff:ff:ff:ff:ff
    inet XX.XX.XX.52/28 brd XX.XX.XX.63 scope global eth0
    inet6 be89::20c:29ff:fe62:8254/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:0c:29:62:84:5e brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.5/24 brd 10.1.1.255 scope global eth1
    inet6 be89::20c:29ff:fe62:825e/64 scope link
       valid_lft forever preferred_lft forever

Адрес WAN и домен server.ru на схеме вымышленный :slight_smile:


g Linux multihomed =)

Конкретней - https://habrahabr.ru/post/100919/ и https://habrahabr.ru/sandbox/38722/

Большое спасибо за напутствие, но хочу предложить подискутировать на эту тему на этом форуме и конкретно на моей задаче (она в 5 раз проще), ибо в статьях примеры рассматриваются очень мудреные и написаны тяжелым языком, чтобы понять эти статьи нужно неделю, а то и две читать теорию обработки трафика ядром ОС, обязательно почитаю, но позже, на это мало времени сейчас (но вообще хорошо что так, за неимением лучшего и это подойдет :smile3:). Имхо: Начинать путь лучше с более простого, так информация усваивается лучше и качественнее, наличие каши в голове сведено к миниму, а практические навыки становятся последовательными и устойчивыми к стрессовым условиям.

Особенности простоты моей схемы:

  1. Данный хост не является шлюзом.
  2. Минимум интерфейсов (всего 2).
  3. Ничего балансировать ненужно.

Моя задача очень проста по сравнению с хаброй, а это:

  1. Отправка ответов на входящие пакеты по тому же интерфейсу, по какому пришли.
    Нюансы:
  • На интерфейсе eth0 мы будем только отвечать на трифик из интернета (http, https).
  • По дефолту шлюз хоста eth1.

Вот мое видение с чего стоит начать

Чтобы пакеты с адресов локалки 10.1.1.1/24 обрабатывались с помощью отдельных правил роутинга:
nano /etc/iproute2/rt_tables в конец добавить:

10.1.1.0/24 dev eth1 scope link 
default via 10.1.1.1 dev eth1

В этом правиле мы сказали что адреса 10.1.1.0/24 пришедшие с интерфейса eth1 пройдут через шлюз того же интерфейса, тоесть если наш хост с адресом 10.1.1.5 например захочет установить программу (nano) из репозитория, следовательно запросы на адреса неизвестные сети (например на dns: 8.8.8.8) пойдут через шлюз 10.1.1.1 интерфейса eth1 и так далее.

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

Кстати насчет интерфейса eth0 напрашивается тоже решение что и по eth1

0.0.0.0/0 dev eth0 scope link 
default via XX.XX.XX.49 dev eth0

Но это решение кажется очень сомнительным и простым чтобы быть правдой. И потом маркировка http и https кажется более интересным в освоении и гибкости конфигурации.

Я не говорил, что надо копипастить из этой статьи в свою консоль. Я просто задал направление поисков на интересующую тему.

  1. Какая разница?
  2. И что это меняет?
  3. Не балансируйте.

Не может быть ДВА дефолта.

В целом - отбросьте из статьи то, что Вам не нужно и просто промаркируйте пакеты с eth0, после чего запихните ответы на них обратно в eth0.
А дефолт поставьте в сторону 10.1.1.1

Настраиваю так:

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

echo 200 inet_zapros >> /etc/iproute2/rt_tables

Выглядит этот файл (/etc/iproute2/rt_tables) теперь так:

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
200     inet_zapros
Промаркируйте пакеты с eth0, после чего запихните ответы на них обратно в eth0.
[b]Чтобы ответы на пакеты уходили по тому же интерфейсу, по какому пришёл запрос, включаю маркировку пакетов:[/b]
iptables -t mangle -I INPUT -i eth0 -j CONNMARK --set-mark 0x1
iptables -t mangle -I OUTPUT -j CONNMARK --restore-mark

и далее назначать таблицу маршрутизации (с именем inet_zapros в файле /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

И как бы Эврика, да вот не совсем, результат есть, но не тот который требовался. Неправильный мёд пчелы сделали :6azapily:

[size=3pt]
Результат:

[/size]
Внешний адрес XX.XX.XX.52 на eth0 запинговался с ПК администратора, подключённый по VPN к корпоративной сети, до этого этот внешний адрес c ПК администратора не пинговался + стал доступен Apache в браузере по этому адресу на 80 порту.
Но как только отключаюсь от VPN, адрес перестал пинговаться и открываться в браузере тоже, пробовал открыть с другого устройства подключенный к другим провайдерам (пинга нет, в браузере не открывается).

Получается что IP адрес XX.XX.XX.52 на eth0 стал доступен через eth1 ( для наглядности, можно посмотреть схему на рис. в первом сообщении темы).

Хоть я и настраивал отключение пересылка пакетов между интерфейсами

cat /proc/sys/net/ipv4/ip_forward
0

ip route list

[[email protected] eth0]# ip route list
XX.XX.XX.48/28 dev eth0  proto kernel  scope link  src XX.XX.XX.52
10.1.1.0/24 dev eth1  proto kernel  scope link  src 10.1.1.5
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
XX.XX.XX.48     0.0.0.0         255.255.255.240 U     0      0        0 eth0
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
0.0.0.0         10.1.1.1        0.0.0.0         UG    0      0        0 eth1

=))) Вторую ссылку читал? :wink:

Так вот, многочасовое разбирательство, включая попытку влезть в исходники iptables и iproute, привели к поразительно простому открытию, которое почему-то почти нигде не упоминается: надо на входящих интерфейсах выключить rp_filter: [code] # prevent incoming packets on masqueraded connections from being dropped # as "martians" due to the destination address being translated before the # rp_filter check is performed

echo 0 > /proc/sys/net/ipv4/conf/ppp0/rp_filter
[/code]

Да, сделал, я это писал уже в пред.сообщении + сейчас перепроверил

отключение пересылка пакетов между интерфейсами

cat /proc/sys/net/ipv4/conf/eth0/rp_filter
0
  • тоже самое сделал на eth1, поэкспериментировал, на обоих интерфейсах и 0 (нолик) и 1 (единичку) ставил.

когда ставлю 1 (единицу) пинги сразу же пропадают, из вне (без VPN) не восстанавливаются.
когда ставлю 0 (ноль) пинги сразу появляются, но при отключении VPN не восстанавливаются.

Результат тот-же

Ну это не отключение форвардинга. Это отключение rp_filter. А в пред.сообщении как раз написано про форвардинг =)

Счётчики растут?
Чую, надо лезть в tcpdump и курить там.

ЗЫ: Вывод ip rule list в студию :wink:
ЗЫ2: А правило в файрволе [font=Menlo]
iptables -t mangle -A OUTPUT -m mark ! --mark 0x0 -j ACCEPT
есть?

Отключаю Forwarding и rp_filter в sysctl.conf
Выдержка из nano /etc/sysctl.conf, По умолчанию было так:

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

Сделал так: :6azapily:

# 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
или можно так (без разницы):
/sbin/sysctl -p

Видим все ОК:

[[email protected]ХХ-ХХ-ХХ-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:

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


А как посмотреть растут ли счетчики?
И счетчики чего? :smile3:
Может тут команды на тему PREROUTING какой не хватает?



Правила

фаервол
небыло, теперь есть, сделал:

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

Не помогло.


В студию: ip rule list

[[email protected]ХХ-ХХ-ХХ-52 ~]# ip rule list
0:      from all lookup local
32763:  from all fwmark 0x7 lookup inet_zapros
32764:  from all fwmark 0x1 lookup inet_zapros
32765:  from all fwmark 0x1 lookup inet_zapros
32766:  from all lookup main
32767:  from all lookup default


Поставил TCPDUMP


Смотрю на ICMP: tcpdump icmp

Трафик с админского ПК - подключенный через VPN идет (это 10.101.1.14), а вот ICMP трафика с другого интернет подключения нет.

15:12:48.813117 IP 10.101.1.14 > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 27883, seq 4797, length 64
15:12:49.816251 IP 10.101.1.14 > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 27883, seq 4798, length 64
15:12:50.819930 IP 10.101.1.14 > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 27883, seq 4799, length 64
^C
107 packets captured
107 packets received by filter
0 packets dropped by kernel

Посмотри на eth0 ICMP, при этом пингая с компа в интернете. Вообще туда что-то приходит?

А это и есть eth0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:12:48.813117 IP 10.101.1.14 > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 27883, seq 4797, length 64
15:12:49.816251 IP 10.101.1.14 > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 27883, seq 4798, length 64
15:12:50.819930 IP 10.101.1.14 > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 27883, seq 4799, length 64

посмотрел еще раз, все тоже самое, он по умолчанию почему то смотрит только его (eth0), пробовал пинговать локальный IP 10.1.1.5 (пингуется) тот что на eth1, но он в дампе не отображается, конкретно по eth1 посмотреть не получается, попробую файл для WireShark сделать.

И что, если набрать sudo tcpdump -i eth1 - он продолжает смотреть пакеты на eth0?

[/size]Забейте болт пока на eth1. Там всё работать будет безо всяких маркировок. Надо разобраться, доходят ли пакеты с eth0 до маркировки, маркируются ли и возвращаются ли обратно.

И что, если набрать sudo tcpdump -i eth1 - он продолжает смотреть пакеты на eth0?

Забейте болт пока на eth1. Там всё работать будет безо всяких маркировок. Надо разобраться, доходят ли пакеты с eth0 до маркировки, маркируются ли и возвращаются ли обратно.

Начала меня эта пляска с бубнами расстраивать! :killall2:

Написал:
shutdown -r now

Ииии, тадам! Смотрю запинговался родной, но говорят же, это Linux, на нем проблемы reboot’om не решаются :ggg: какие службы только не ребутал, network, iptables, сбрасывал роут кеш, грешу что sysctl как то по другому может перезапустить нужно было. Итог: Работает, в штатном режиме! :smile3:


Конечно это может быть проблема была даже и не в LINUX, а что-то на маршрутизаторе (в который подключен сервер), при перезагрузке ребутнулся порт, обновились таблицы и т.п. на физическом, канальном (какойнить logic link control) или сетевом уровне.


[[email protected] ~]# tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:25:48.682526 IP 83.2X.XX.XX > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 24455, seq 30840, length 64
16:25:48.773519 IP 10.101.1.14 > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 62187, seq 7, length 64
16:25:49.680925 IP 83.2X.XX.XX > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 24455, seq 30840, length 64
16:25:49.778807 IP 10.101.1.14 > ХХ-ХХ-ХХ-52.server.ru: ICMP echo request, id 62187, seq 8, length 64


around
, спасибо большое за участие, подсказки и поддержку! :hlop-x: :good:

Семь бед - один ребут =D
У меня некоторые проблемы даже с Cisco ASR1k/9k решаются только ребутом =(

Не во что! Рад, что смог помочь =)


Грабли:


Отваливается сеть на интерфейсе eth0 раз в 1-2 дня, проблема решается ребутом виртуальной машинки (программная перезагрузка сетевых интерфейсов проблему не решает):

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

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  * 

Посмотрим еще разок на маршруты:

[[email protected]ХХ-ХХ-ХХ-52~]# ip ro
ХХ.ХХ.ХХ.48/28 dev eth0 proto kernel scope link src ХХ.ХХ.ХХ.52
ХХ.ХХ.ХХ.0/24 dev eth1 proto kernel scope link src ХХ.ХХ.ХХ.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 ХХ.ХХ.ХХ.1 dev eth1

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


[[email protected]ХХ-ХХ-ХХ-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
[[email protected]ХХ-ХХ-ХХ-52 ~]#

Смотрю TCP Dump eth0


[[email protected]ХХ-ХХ-ХХ-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


[[email protected]] > 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:
[code]

[[email protected]ХХ-ХХ-ХХ-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

[/code]


ИТОГ:


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

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

ip ro del default
ip ro add default via XX.XX.XX.49

[/code]

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

Общался с ведущим инженером провайдера, проблему на их стороне исключают и рекомендуют отказаться от маршрутизации с метками пакетов “mangle”. Но я считаю что отказываться ненужно, нужно просто разобраться и правильно настроить!

:6azapily: