Магия с отправкой пакетов с нужного IP

Случаи бывают разные, но это вы все и так знаете. Отвечая на письма наших читателей, расскажу как сотворить магию, которая позволит отправлять пакеты с нужного IP-адреса, если их прописано несколько на роутере.

Возможных вариантов два – либо это разные интерфейсы, со своими шлюзами, адресами, DNS’ами и прочей радостью. Либо это провайдер выдал пачку адресов и мы их радостно прописали как дополнительные на интерфейсе. В теории, можно растащить несколько адресов провайдера по разным интерфейсам, но нужно чтобы у этих интерфейсов были разные MAC-адреса, иначе свитч сойдет с ума и ничего внятного из этого не выйдет.

Вариант нумер раз. Тут все просто до безобразия – пишем как обычно таблицу маршрутизации, в смысле по вкусу. А траффиком управляем через правила для траффика – не забываем указать протокол (или группу) и говорим, что интерфейс назначения ни разу не Any, а вовсе даже Wan1, Wan2 или вообще любой, какой нам нужен. На основании этого правила траффик пойдет только по тому интерфейсу, для которого оно разрешено, по всем остальным указанный протокол не пойдет, потому что не разрешено.

Вариант второй чуток более хлопотный и лично я его использовать не рекомендую. Если в роутере есть лишний физический дырка, проще поставить в середину свитч и развести сетки по нескольким интерфейсам. Тем более, что купить управляемый свитч нынче не проблема, а выделять порты для “разветвления” внешнего кабеля удобнее именно на уже имеющемся свитче. Но это ИМХО, и не является непререкаемым фактом.

Итак, вариант второй – мы прописали несколько адресов на одном интерфейсе и хотим отправлять пакеты не с IP1, а с IP2 (например). Тут нам помогут дополнительные таблицы маршрутизации. Первым делом, создаем новую таблицу маршрутизации. Тип есть смысл указывать как “Only”, поскольку дело исключительное. В таблице будет одна строчка, в которой обязательно нужно указать IP2 в качестве адреса отправителя (локальный IP-адрес). После чего создаем правило, в котором указываем нашу новую таблицу маршрутизации в качестве “прямой”. Если сервер стоит у нас и есть нужда отвечать на запросы, в качестве “обратной” таблицы маршрутизации тоже стоит указать свежесозданную таблицу. Разумеется, указываем протокол, к которому будет применяться таблица. По вкусу, можно указать расписание, источник и получатель можно заполнять как “любое”. Все!

Чтобы использовать дополнительные таблицы маршрутизации и правила к ним в полный рост, нужно много планировать и иметь большую умную голову 🙂 Мое решение – очень примитивное, технология может куда больше.

UPDATE

Пример из комментариев. Есть 4 внешних адреса (ext_1, ext_2, ext_3 и ext_4), которые получены от одного провайдера и заведены в один WAN-порт на роутере. Есть внутренние сервисы, которым назначены некие внутренние адреса из локалки (DNS, Web, Mail, Some_srv). Задача раз – выпустить всех через один адрес, впускать запросы извне каждый сервис по своему внешнему адресу. Задача два – выпустить каждый сервис через свой же адрес, впускать тоже по своему адресу.

Общая часть. В интерфейсах создаем нужное количество arp-записей. В правилах для пакетов создаем нужное количество SAT-правил вида “если пакет прилетает извне на адрес ext_1 и на порт 53, маппим его на внутренний адрес DNS и порт не меняем” и “если пакет прилетает извне на адрес ext_2 и на порт 80, маппим его на внутренний адрес Web и порт не меняем”. Повторить по количеству сервисов 🙂

Решение номер раз. Больше ничего не требуется. С какого адреса выходить мы будем? С того, который основной на интерфейсе. Или можно в основной таблице маршрутизации явно указать какой адрес используется. Но это по вкусу.

Перед решением номер два, немного теории. Таблицы маршрутизации сами не решают ничего ровным счетом. Они лишь указывают в какую сеть можно попасть, если использовать такой-то шлюз и такой-то интерфейс. Все. Опционально, можно указать IP, которым будет представляться роутер. Все решают правила маршрутизации. Для решения второй задачи придется, по большому счету, палить из пушки по воробьям – эффективно, но винтовки все равно никто не выдаст.

Решение номер два. Создадим дополнительные таблицы маршрутизации на одну меньше, чем количество наших внешних адресов и пропишем в них один маршрут – тот, который обычный в All-net, но подставим очередной внешний IP в графе “локальный IP”. Один адрес (по умолчанию который) у нас уже есть в стандартной таблице, поэтому дополнительных на одну меньше. В принципе, создавать их можно в режиме “default” и не заморачиваться – должно работать. Далее, начинаем писать правила маршрутизации. Минимум – одно правило на одну доп.таблицу. Можно колдовать с бОльшим количеством правил на доп.таблицу – готовить по вкусу, бывает нужно для нескольких сервисов, например.

Итак, создаем правило. Адресный фильтр… Логика такова: сервера внутри, стало быть прямое направление пакета – извне вовнутрь, обратное – изнутри наружу. Фром интернет с любовью Так и пишем в адресном фильтре. Источник – интернет, назначение “core” и соответствующий внешний адрес. Разбираемся с таблицами. Прямая – можно оставить стандартную, а можно поставить нашу дополнительную. Это пофиг, в данном случае. Обратная – обязательно соответствующая таблица маршрутизации. Все. Расписание и сервисы заполняем по вкусу.

Проверять логику можно нужно. Сделать это можно развернув в правиле маршрутизации направления пакетов (работать с исходящими пакетами) и поменяв местами прямую и обратную таблицы. А в качестве протокола в правиле указать HTTP. Благо, сейчас сервисов “угадай мой IP” в интернете ведро. Даже если где-то косяк в настройке (я наврал ненароком, например), такая проверка выявит как оно реально работает.

В путь, жду отзывов