LINUX.ORG.RU
ФорумAdmin

Маршрутизация, 2 корпуса

 , ,


0

2

Здравствуйте. Прошу помощи с объединением двух сетей. Подключили нового провайдера, он выдал диапазон внешних ip-адресов (адреса провайдера видят друг друга). Шлюзы корпусов на Debian.

Имеется:

Корпус №1

внутренняя сеть 192.168.1.0/24

шлюз внутренней сети 192.168.1.1 - eth1

40.40.40.40 - ip провайдера - eth0

Корпус №2

внутренняя сеть 192.168.2.0/24

шлюз внутренней сети 192.168.2.1 - eth1

40.40.40.41 - ip провайдера - eth0

Как православно объединить сети?

На первом:
ip r a 192.168.2.0/24 dev eth0 via 40.40.40.40
На втором:
ip r a 192.168.1.0/24 dev eth0 via 40.40.40.41
И на обоих включить форвардинг пакетов

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

спасибо! И вопрос с iptables скорее.. хост из корпуса №1 видит шлюз корпуса №2, но другие хосты не пингует. И наоборот. Какое правило нужно прописать?

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

А не наоборот? Вот так:

ip r a 192.168.2.0/24 dev eth0 via 40.40.40.41
ip r a 192.168.1.0/24 dev eth0 via 40.40.40.40

mathcrosp ★★
()

православно - имхо через vpn. в плане - как только сигнал выходит за пределы твоей инфраструктуры лучше юзать впн. а так - уже написали

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

На обоих шлюзах:

iptables -A INPUT -i eth0 -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Если надо будет как-то более тонко настраивать кому куда можно «пинговать», то и правил надо будет побольше и посложнее.

PS: с этими правилами у тебя из провайдерской сетки будет полный доступ в твои сетки. Поэтому они на 5 минут для проверки. Потом надо указать в каждом правиле для какой где подсетки разрешены INPUT и FORWARD, а остальное дропать. Или, что более правильно, как сказали выше — vpn. Без vpn у провайдера будут в любом случае транзитный траффик слышать. А с vpn хоть какое-то шифрование.

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

благодарю за информацию! буду шаманить :)

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

Смотрите, самое правильное написал upcFrost «как только сигнал выходит за пределы твоей инфраструктуры лучше юзать впн» и я с ним согласен.
Если вас это не волнует, то обычный роут который уже описали выше. Хотя я бы такого не делал, паранойя она такая зараза...

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

Тут даже без «веществ» достаточно вариантов, просто случайно накосячил, пришел новый не опытный «нажал не ту кнопку» и т.д. и т.п. Прям только что, полторы недели от мгтс ловили косяки с одного объекта.
ЗЫ А уж с веществами еще больше вариантов. :)

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

Полностью согласен с upcFrost... Пробуйте что-то типа OpenVPN. Неплохой вариант также PfSense как firewall в каждом корпусе и онже шлюз. В нем уже интегрированный OpenVPN + Radius.

merlin-shadow
()
Ответ на: комментарий от anc

В варианте ТС

Что вы имеете ввиду?

У меня такое работает SITE-SITE и SITE-clients... проблем никаких. Хотя считается что ipsec вроде более защищенный.

merlin-shadow
()
Ответ на: комментарий от Paskura

провайдер - свои люди

дружба эт святое. но общепринятых норм сетевого администрирования она не отменяет.

Если по сути - нужно будет прописать маршруты и забить правила input/forward на фаерволах. это нужно будет делать в любом случае, есть впн или нет (в случае впн маршрут пойдет в тоннель). imul уже дал выше два листинга как это делать, это базовая сеть и тут даже комментировать нечего.

по поводу впн - они решают не только проблему защиты, хотя ей пренебрегать нельзя ни по личным, ни по юридическим показателям. помимо защиты впн в первую очередь позволяет задействовать стандартные варианты подключения удаленных точек. это сейчас зданий всего два, а у меня был опыт когда компания за два года с 6 до 15 точек выросла. тут уже никакой ручной маршрутизацией не отделаться, да и site-to-site ipsec'ами тоже, только ospf/dvpn/dmvpn, ну и gre разумеется, а они все прекрасно и абсолютно стандартно интегрируются с впн-тоннелями.

собственно я это к чему - если уж взялся сеть переделывать, переделай так чтоб хватило даже если контору раздует как пачку кефира на июльском солнце. иначе в один прекрасный день будет 10 точек и 20 провайдеров, и дикий зоопарк из серых и белых адресов, ната и через колено сделанной маршрутизации. лучше пока можно - сделать хорошо и на века.

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

Пошустрее будет работать, и ресурсов меньше скушает.

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

Дополню. Из реалий жизни, есть около 25-ти объектов которые соединены с центральным офисом, пров один, на обьектах adsl, сети маршрутиризирует пров, т.е. vpn нэма, инета правда тоже, чисто объединение сетей без выхода в инет. Так вот не бывает хотя бы одного случая в год что бы пров где-то не накосячил в части маршрутов и т.п. А исправляют далеко не за один день. Последний случай был полмесяца назад, решали проблему полторы недели.
Когда эта «эпопея» только начиналась, подключали первые обьекты, я изначально строил на основе vpn, и описанным мной проблем в первые годы не было, потом пришли другие люди и сделали по другому (теперь это не в моей компетенции) результат на «лице».
ЗЫ 2 ТС Это сегодня пров «дружественный» а завтра его поглотит большой пров который будет совсем не такой уж и «дружественный»

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.