Routes & iptables in linux

Discussion in 'Hardware and Software' started by Estel, Oct 10, 2019.

  1. Estel

    Estel Well-Known Member

    Joined:
    Feb 16, 2000
    Messages:
    7,291
    Обозначьте мне куда копать.

    Вот есть роутинг таблица, которая ip ro li ta all. Есть набор каких-то правил в iptables. В какой момент времени пакет обрабатывается именно в роутинг таблицах при входе на интерфейс и выходе с интерфейса? Т.е. мы вот взяли и приняли пакет. Он прошел к примеру через FORWARD и POSTROUTING. Дальше что? Он только после этого попадёт на таблицы route или при входе тоже?
     
  2. mcgru-

    mcgru- Well-Known Member

    Joined:
    Sep 21, 2000
    Messages:
    61,276
    Location:
    Tomsk, Russia
    на память на словах уже не помню точно


    [​IMG]
     
  3. Estel

    Estel Well-Known Member

    Joined:
    Feb 16, 2000
    Messages:
    7,291
    Это я уже видел.

    И вот собственно вопрос.

    Допустим, пришёл пакет. Вот он проверен на таблице PREROUTING. И ясно что менять ничего не надо. По плану действий, его должно отфорвардить на другой интерфейс и отправить дальше. Начинается route table. В таблице роутинга есть описание выходного интерфейса. И, допустим, даже есть дополнительное описание маршрута на выход по from/to. Пакет звездует куда? По правилам роутинговой таблицы? Как он попадает и в какой момент в правила FORWARD? После FORWARD он снова падает в routing table? А в чей? Выходного интерфейса? А из какого места роутинг таблицы он выходит в FORWARD?

    У меня сложилась слишком сложная система интерфейсов. Переделывать её - нежелательно. А вот настроить нормально роутинг хочется и требуется.
     
  4. mcgru-

    mcgru- Well-Known Member

    Joined:
    Sep 21, 2000
    Messages:
    61,276
    Location:
    Tomsk, Russia
    На картинке выше - блоки, обзываемые "маршрутизация", как раз и занимаются роутингом - определением на какой интерфейс закинуть пакет.
    т.е. их ДВА - после всех блоков DNAT , а DNAT может быть только в PREROUTING и OUTPUT: как только делается DNAT, так после этого сразу снова решается куда пойтить пакету.

    в POSTROUTING NAT используется SNAT, на роутинг может повлиять только если используется advanced routing.

    Пакет звездует туда, куда ему говорит ip ro - или по table default, или по именному/нумерованному (в /etc/iproute2/rt_tables) table.

    в FORWARD попадает "иностранный" пакет, если ему не нужно на какой либо из локальных (местных) интерфейсов или айпи-адресов.

    ты б привёл пример с парой-тройкой своих интерфейсов... что тебя мучает там?
     
    Last edited: Oct 17, 2019
  5. Estel

    Estel Well-Known Member

    Joined:
    Feb 16, 2000
    Messages:
    7,291
    Вот схема. Она в принципе отражает, но указаны другие адреса.


    порты.jpeg
     
  6. mcgru-

    mcgru- Well-Known Member

    Joined:
    Sep 21, 2000
    Messages:
    61,276
    Location:
    Tomsk, Russia
    на картинке понял, что есть 4 порта (eth{0-3}) и 5 вланов.
    про остальное - лишь догадки.

    не понятно зачем роутить пакеты для 80.80.80.0/26 через 80.80.80.194 ?
    вроде через 80.80.80.1 должно хотя бы.

    что куда хочется роутить и как рулить траффиком?
     
  7. Estel

    Estel Well-Known Member

    Joined:
    Feb 16, 2000
    Messages:
    7,291
    Дефолтовый гейт - gate - I

    Gate - II идёт как запасный и как дефолтовый гейт для VLAN 400.

    Юзверя из VLAN 200 и 300 должны натиться как 80.80.80.1 и звездовать в гейт.

    Из 400, соответственно натиться как 90.90.90.38 и в gate - II.

    На eth0 и eth3.666 живёт dns. К нему должен быть доступ у всех.

    По VLAN 100 выведены несколько серверов, которые живут отдельно с указанными адресами. К ним должен быть доступ у всех юзверей и из сети.


    Вот теперь собственно вопросы.

    Теоретически мы считаем, что доступа к gate-I нет и ничего изменить мы не можем.

    Очень желательно, чтобы ФИЗИЧЕСКИ, пакеты на gate-I шли именно с интерфейса eth1.

    ВЛАНы можно сделать любые.

    RP_FILTER отключен.

    Далее.

    Вот допустим, у нас есть пакет идущий из Инета в сеть 100 по адресу 80.80.80.2

    Согласно роутингу шлюза gate-I, он сначала приходит на eth0.
    Тут он должен быть отфорваржен на eth1 и далее в сеть 100 на сервер. Тут как бы всё понятно и вопросов нет. Но. Пакет идёт обратно от сервера.
    Вот мы его приняли на eth1. Как организовывать дальше маршрут? Говорить, что напрямую сразу идти на gate-I и прописать его? Или придётся обязательно прописывать
    ещё и eth0 как промежуточную точку из-за записи на гейте?

    Дальше.

    Допустим из инета пришёл пинг на 80.80.80.1

    Соответственно, приходится писать такое правило:

    -A INPUT -i eth0 -s 0/0 -d 80.80.80.1 -p icmp --icmp-type 8 -j ACCEPT

    А как сделать так, чтобы можно было таки написать, что не eth0, а eth1?

    Если допустим сделать так:

    ip ru a 80.80.80.0/26 table in1
    ip ru a 80.80.80.192/27 table in1
    ip ro a 80.80.80.0/26 dev eth1 scope global table in1
    ip ro a 80.80.80.192/27 dev eth0 scope global table in1

    То при наличии таких записей, маршрут всё равно всегда выбирается через eth0. Хотя, по идее он должен упасть на объявленный интерфейс eth1. Ровно тоже самое и с адресатами в сети /26.
    Или их надо сразу делить по целевому интерфейсу? Но. Таблицы-то общие для всех интерфейсов и выбор идёт только по адресам источника/цели.
     
  8. mcgru-

    mcgru- Well-Known Member

    Joined:
    Sep 21, 2000
    Messages:
    61,276
    Location:
    Tomsk, Russia
    "Нет" откуда? из сети vlan100?
    т.е. есть запрещающий фильтр на шлюзе? (ты, кстати, обзови как-нибудь этот сервер в рассуждениях, у которого eth0,1,2,3)

    если у тебя в ip ro прописано default via 80.80.80.193 dev eth1, то ничего делать не нужно - ядро само разберётся куда девать пакет (оно и есть "маршрут по-умолчанию").

    нет

    * не надо захламлять этим: -s 0/0 -- убери, и так понятно.
    * это правило - для INPUT, т.е. для тех пакетов, которые ДОЛЖНЫ ПРИНИМАТЬСЯ самим ядром.
    если есть в сервере адрес 80.80.80.1, то будет аксептиться.
    но у тебя 80.80.80.1 принадлежит другому хосту, следовательно это правило бессмысленно.
    если хочешь разрешить прохождение пакетов, приходящих на eth0, до 80.80.80.1 - напиши чтото типа:
    -A FORWARD -i eth0 -d 80.80.80.1 -p icmp --icmp-type 8 -j ACCEPT

    если хочешь, чтобы правило было непременно по eth1 прописано (непонятно зачем), то тогда
    -A FORWARD -o eth1 -d 80.80.80.1 -p icmp --icmp-type 8 -j ACCEPT

    тут не хватает указания FROM. эти правила в основном годятся тогда, когда нужно по src-ip роутить.
    по dst-ip обычно роутится с помощью ip ro.
    это полиси-роутинг, почитай ip ru help:
    SELECTOR := [ not ] [ from PREFIX ] [ to PREFIX ]


    Предположим, что ты имел в виду ip ru a from 80.80.80.0/26 table in1
    Тогда запись ip ro a 80.80.80.0/26 dev eth1 scope global table in1 -- будет несколько бессмысленна, ибо конфликт: с одной стороны, ядро знает, что все пакеты, имеющие DST-ip 80.80.80.0/26 должны шуровать в eth1, а пакеты, имеющие SRC-ip как 80.80.80.0/26 - должны быть или идущие ИЗ eth1, или вообще хз что это за пакеты и должны быть, по-идее, отброшены по rp_filter.
    Т.е. такая запись - роутить (все) пакеты, имеющие И src-ip, И dst-ip из одной сети, только в интерфейс eth1 - бессмысленна - отключи тогда вообще интерфейс ;)

    (и вообще - не стесняйся заводить таблицы в /etc/iproute2/rt_tables - их там 32000 может быть. зачем одинм именем таблицу назвал?)

    А вот ежели src=80.80.80.192/27 а dst=80.80.80.0/26, то это уже другое дело - по-идее, это должно отрабатываться. Но оно совпадает с твоим дефолтным поведением, так что тоже лишнее.

    Там ещё есть параметр priority у ip ru, и параметр metric у ip ro - они вроде как приоритет определяют. Может ты этого хочешь?

    Но сдаётся мне - какие-то излишние у тебя навороты.
    Запиши словами лучше чего ты хочешь - возможно, ты сам (рассказывая другим) поймёшь что тебе НЕ нужно.
     
  9. Estel

    Estel Well-Known Member

    Joined:
    Feb 16, 2000
    Messages:
    7,291
    "Нет" это имеется в виду наличие физического доступа к гейту, куда я могу зайти и прописать всю маршрутизацию как хочу.

    Нужно. В именных таблицах должны быть прописаны все интерфейсы, куда предполагается роутить пакеты или возвращать.

    Ну вот оно и не работает.

    Я перестаю понимать логику происходящего.

    По идее, должно работать так:

    1. Пакет пришёл на интерфейс.
    2. Проверка через PREROUTING
    3. роутинг таблица
    4. решение INPUT/FORWARD
    5. применение фильтра FORWARD
    6. проверка в POSTROUTING
    7. выход с интерфейса

    При переадресации, пакет уходит куда? На вход другого интерфейса через выход интерфейса получившего пакет? Вряд ли ведь. Скорее всего, он через ядро выбрасывает его где-то на уровне 4. Вот этого я и не понимаю.