solarfly 12 апр 2011 в 12:40

Объединение двух локальных сетей с одинаковым номерами сетей на Linux-шлюзе

5 мин

45K

Системное администрирование *

Из песочницы

+61

Комментарии 61

xReaper 12 апр 2011 в 17:34

Как же нужно жопу рвать без динамический адресов. А то что на серверах надо ручками поменять это не резон.

curlydevil 12 апр 2011 в 17:43

Ну, например я столкнулся с ситуацией когда статические айпишники достались мне, как наследие предыдущего сисадмина, вбитыми конкретно на машинах пользователей а не на сервере… Т.к. помещение большое — где часть из этого железа — я даже не догадываюсь, да и поменять вручную со статического IP на получение динамического на овер 100 машинах — это не всегда бывает весело, тем более есть нюансы в планировке зданий…

xReaper 12 апр 2011 в 18:00

Да нет вы не обижайтесь, я сам добра хлебнул такого, хотите байку?
В общем есть у нас клиент, у них офисы по всей стране, очень много, так у них всех внутри компании адреса класса А но не стандартные, у них все офисы связаны сейчас а раньше был кавардак, так какой то админ идиот всех перевёл на адреса на 5.0.0.0 причем на статике, не спрашивайте почему, в общем сейчас уже не поменять там 3к машин. Вот так и живут прописывая все дороги ручками.

НЛО прилетело и опубликовало эту надпись здесь

dcvetkov 13 апр 2011 в 01:34

Свои 5 копеек :)
Крупное промышленное предприятие с парком машин около 500. Когда пришёл админить, был удивлён адресации 132.147.0.0/16. По whois узнал, что диапазон принадлежит The SCO Group, Inc. Через какое-то время в серверной обратил внимание на старый-престарый сервер Sun. Он был первым.

MakeInstall 13 апр 2011 в 03:50

На предыдущей, работе решилось все через рассылку, ноги и Radmin.

2500 Машин за два дня.

1.Настроили DHCP
2. Разослали инструкцию…
3. 70% переключили сами… Остальным пришлось помогать.

4. Завершающая инструкция, все кто не выполнил инструкцию не смогут работать в сети с 1 Апреля. Все позвонили…

Tibr 13 апр 2011 в 08:23

С 1 апреля? Вовремя Вы :-)

Akint 13 апр 2011 в 06:10

Мы (провайдер) как-то разделяли клиентские сети… Несмотря на наличие DHCP сервера, у части клиентов настройки всё равно прописаны статикой. Составили список тех, у кого остались старые настройки, и передали его call-центру, в течение пары недель были обзвонены практически все. После этого завершили разделение. У оставшихся людей со старыми настройками перестало работать, но им достаточно было позвонить в техническую поддержку, чтобы получить инструкции, как вернуть себе работающую сеть.

zlyoha 17 апр 2011 в 16:43

Самому так недавно позвонили от провайдера, спасибо, что заботитесь о клиентах.

smartly 12 апр 2011 в 18:02

Ну, сначала настроить dhcp-сервер. Потом парочку ближайших переключить на dhcp. Потом парочку следующих. А потом видно будет.

navion 12 апр 2011 в 18:17

Если к машинам есть админский доступ — поменять скриптом, в противном случае надо вначале его получить :)

Obramko 12 апр 2011 в 22:24

Все намного проще, товарищи!
Вешаем на прокси, которая пускает всех в Интернет (нет? не верю!) заглушку а-ля «Хотите Интернет? Нажмите Пуск — Выполнить, скопируйте в поля ввода следующее (пишем команду, которая переключает на DHCP — не помню, как в винде) и нажмите ОК». Половина ручных переключится сама, остальные уже можно пройтись :).

solarfly 12 апр 2011 в 22:29

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

Obramko 12 апр 2011 в 22:35

Лично я? Не держу.
Но когда-то я был пользователем, и помню, что такой метод подействовал. ;)
Такое поможет, если нет возможности пробежаться всюду самому.
Ну и, конечно, никто не отменяет объявления накануне.

dcvetkov 13 апр 2011 в 01:38

Учитывая, что его пользователи сидят с админскими правами — то нифига он не держит.

Obramko 13 апр 2011 в 10:08

У меня всего три пользователя, которых я контролирую. Все сидят в Ubuntu без админских прав.
Остальные — толпы хомячков клиентов.

Obramko 13 апр 2011 в 10:15

Арр, парсер сожрал HTML. «Хомячков» должно быть перечеркнуто.

NickyX3 13 апр 2011 в 04:13

так их можно заставить выполнить netsh с DHCP-установками.

solarfly 13 апр 2011 в 11:36

Тоже вариант, расшарить батник с подобным содержимым.
netsh interface ip set address name="Подключение по локальной сети" source=dhcp
Жаль, что в виндовых клиентах по умолчанию нет никакого шелла, можно было бы все автоматизировать и не париться.

divanikus 12 апр 2011 в 17:40

Не очень понятно что произойдет если в обеих подсетях будут сервисы с одинаковым айпи.

solarfly 12 апр 2011 в 18:01

Почему что-то должно произойти? И в этом как раз и прелесть NETMAP'а.
Без него можно просто указать в роутах нужные машины, типа:
ip route add 192.168.0.x/32 via <адрес шлюза>
И вот тут как раз Ваш вопрос будет актуален, если будут совпадающие ip.

divanikus 12 апр 2011 в 18:05

Это на каждой машине прописать, да?

divanikus 12 апр 2011 в 18:06

А, все понял, они же замапяться в другую подсеть.

Foggy4 13 апр 2011 в 15:08

Обьясните неразумному, куда все же полетит ICMP пакет, если я с любой машины в LAN1 пропингую адрес 192.168.0.111 при условии, что в обеих сетях есть машины с таким адресом?

solarfly 13 апр 2011 в 15:23

Не называйте себя так.
Вы ping'анете LAN1, если такой машины нет, то пакет никуда не уйдет. Если Вы ping'анете 10.8.1.111, то он из LAN1 уйдет в LAN2 и pong'анется обратно, если там есть машина 192.168.0.111. Для каждой сети существует только своя сеть с адресом 192.168.0.0/24.

click0 13 апр 2011 в 16:40

Будет видна машина только из первой сети.

insekt 6 дек 2013 в 12:16

А как отрабатывается тот момент, что внутри хэдэра ICPM передаются оригинальные IP source и dest? Собственно аналогичный вопрос для SIP?

solarfly 11 дек 2013 в 11:02

Уже минуло много времени и вопрос такой не стоял, поэтому скорее всего никак.

НЛО прилетело и опубликовало эту надпись здесь

solarfly 12 апр 2011 в 18:13

Не забыл. Туннель OpenVPN L3. Это вроде видно по названию интерфейса. Если не ошибаюсь, то Level 2 выдает tap#, Level 3 tun#.

НЛО прилетело и опубликовало эту надпись здесь

vanxant 13 апр 2011 в 00:46

Тоже почему-то подумалось, что здесь спасет проброс моста.

vmandgiev 12 апр 2011 в 19:45

а как бы еще dns заставить работать через это?

комп из LAN2 обратится к dns-серверу из LAN1, что бы узнать ip компа из LAN1 и получит в ответ 192.168.0.18, например, а должен получить 10.8.2.18

у меня есть идея — iptables-ом ловить dns пакеты и отправлять их в userland с помощью queue target, а там править пакеты заменяя в dns-ответах 192.168.0.x на 10.8.2.x. Покритикуйте идею.

solarfly 12 апр 2011 в 19:53

Идея хорошая, что-то вроде DNS-proxy, но подобных решений не встречал. Вы можете быть первым.
Простейший вариант — запустить DNS-сервер на VPN-сервере с измененными копиями зонных файлов с главного DNS-сервера подсети.

solarfly 12 апр 2011 в 21:21

Сорри за глупый вариант. Mykhailo Predeus дал совет по почте использовать view в DNS. Спасибо ему, про такую вещь совсем забыл.

vmandgiev 13 апр 2011 в 05:57

view я так понял на dns сервере в LAN1, но это если в LAN1 днс сервер bind.

А если в LAN1 Win сервер с AD и интегрированным днс? Можно конечно поднять bind на VPN-сервере в качетсве вторичного DNS-сервера и отдавать ему зону с Win-сервера, но здесь view будет уже не преминим.

solarfly 13 апр 2011 в 06:52

DNS в LAN1 можно попробовать настроить как подчиненный для зоны мастер-серевера из LAN2 c view, хотя я не знаю, предоставляет ли такие возможности администратору DNS Windows Server'а. Но наличие AD предполагает возможность централизованной смены IP-адресов через DHCP, и описанной проблемы не возникнет. А там деревья, леса и прочие особенности.

Namelles_One 23 окт 2014 в 10:13

Идея рабочая. Настроил подобное с помощью scapy (http://www.secdev.org/projects/scapy/) и nfqueue-bindings (https://www.wzdftpd.net/redmine/projects/nfqueue-bindings/wiki/)

Пример скрипта:

#! /usr/bin/env python

import os, sys

fpid = os.fork()
if fpid!=0:
    sys.exit(0)

import nfqueue
import scapy.all
from scapy.all import *
r = re.compile('^169\.254\.1\.')
def callback(payload):
    data = payload.get_data()
    pkt = IP(data)
    if pkt.haslayer(DNSRR):
      if pkt[DNS].ancount > 0:
        for rr in range(pkt[DNS].ancount):
            pkt[DNS][DNSRR][rr].rdata = r.sub('192.168.89.',pkt[DNS][DNSRR][rr].rdata)
        pkt[IP].len = len(str(pkt))
        pkt[UDP].len = len(str(pkt[UDP]))
        del pkt[UDP].chksum
        del pkt[IP].chksum
        payload.set_verdict_modified(nfqueue.NF_ACCEPT, str(pkt), len(pkt))

def main():
    q = nfqueue.queue()
    q.open()
    q.bind(socket.AF_INET)
    q.set_callback(callback)
    q.create_queue(0)
    try:
      q.try_run() # Main loop
    except:
      q.unbind(socket.AF_INET)
      q.close()

main()

vmandgiev 23 окт 2014 в 11:31

Насколько стабильно работает?

И спасибо за своевременный пример реализации! :-) Попробую на досуге.

Namelles_One 23 окт 2014 в 11:49

Не за что)))

Работает пока один день, поэтому о стабильности говорить преждевременно)

Obramko 12 апр 2011 в 22:29

Кстати, чем-то похожая на эту схему описана в LARTC. Там оно называется, кажется, Double NAT.

click0 13 апр 2011 в 01:25

Неправильный подход.
На обоих шлюзах сооружайте NAT, DHCP сервера и туннель между шлюзами.
Находите пересекающиеся IP и меняйте им адреса, подключив DHCP.
На шлюзах поднимается arp-proxy.
А то, что вы соорудили — двойной NAT со своим протоколом маршрутизации.

solarfly 13 апр 2011 в 06:36

Я давно не претендую на адекватность своих действий. Но все же хотелось бы узнать, почему подход неправильный? Как применять DHCP, если в условиях задачи явно указано, что нет возможности менять адреса? Вы ведь тоже предлагаете NAT с обеих сторон с кучей манипуляций, когда это решение в несколько команд без установки дополнительного ПО.

click0 13 апр 2011 в 13:31

>Я давно не претендую на адекватность своих действий.
Это плохо.
>Но все же хотелось бы узнать, почему подход неправильный?
Вы не поняли проблему, не нашли работающие решения и решили городить свои костыли.

> Как применять DHCP, если в условиях задачи явно указано, что нет возможности менять адреса?
Всегда есть возможность на части машин перебить dhcp
В обоих сетях машин меньше, чем 255, и пересечения одинаковых ip не больше 10-20. Так что перебить ip не так уж сложно.
>Вы ведь тоже предлагаете NAT с обеих сторон с кучей манипуляций, когда это решение в несколько команд без установки дополнительного ПО.
Важно не сколько единиц ПО было установлено, а сколько времени нужно разобраться в написанных конфигурациях.
Разбив задачу на подзадачи и установив ПО для решения каждой подзадачи вы упростили в разы задачу при дальнейшего администрировании этих сетей.

P.S. Вы не умеете лениться! (с)

solarfly 13 апр 2011 в 15:44

Может и не умею лениться, но люблю. :)

Еще раз повторюсь, задача стоит соединить сеть, не трогая пользовательские машины, которые на статике. Если Вам угодно — это приказ начальства. Он не обсуждается, как и само начальство.

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

Ваш вариант предполагает усложнить маршрутизацию и значительно повысить нагрузку на оборудование (коммутаторы L2 неуправляемые), это либо передавать весь сетевой трафик через шлюз. Либо прописать пути до каждой машины на каждой машине.

Давайте без предплоложений, как поступить если условия были бы другие.

Я довольно смутно могу представить реализацию того, что Вы предложили. Тем более она не для данного конкретного случая. Но мне интересно увидеть статью по этому поводу или хотя бы ссылки.

click0 13 апр 2011 в 16:35

>Еще раз повторюсь, задача стоит соединить сеть, не трогая пользовательские машины, которые на статике.
>Если Вам угодно — это приказ начальства. Он не обсуждается, как и само начальство.
Начальство часто дает невыполнимые приказы. Я вам указал, что пересечения адресов будет минимальное и можно объединить две сети с одним бродкастом и отказаться от NAT'a!

>Если доступны машины для изменения типа адресации, то можно добраться до каждой машины сети, если конечно они не замурованы с бункере и на них не стоит экзотическая ОС.
>Но в таком случае сабжевой проблемы не возникнет.
Нам не надо добираться до каждой! нам надо только убрать пересечения, а если не удасться, то натить только их!!!

>Ваш вариант предполагает усложнить маршрутизацию и значительно повысить нагрузку на оборудование (коммутаторы L2 неуправляемые), это либо передавать весь сетевой трафик через шлюз.
>Либо прописать пути до каждой машины на каждой машине.
Это вы в статье соорудили свой демон и протокол маршрутизации.
Коммутаторы тут не причем, хотя если у вас много бродкаста, могут лечь при любом дизайне :)

>Давайте без предплоложений, как поступить если условия были бы другие.
В мире не может быть единственного выхода. В вашем случае, я указываю на не самый лучший способ реализации. Кроме того, у двойного (несимметричного) NAT'a есть побочные нюансы.

>Я довольно смутно могу представить реализацию того, что Вы предложили.
>Тем более она не для данного конкретного случая. Но мне интересно увидеть статью по этому поводу или хотя бы ссылки.
Я думаю, Вам стоит для начала прочитать литературу про маршрутизацию и про модель OSI, а не бросаться с шашками наголо на iptables.

solarfly 13 апр 2011 в 16:40

Доверюсь Вашему опыту и последую рекомендациям. ;)

0Lexx0 13 апр 2011 в 11:52

Автор как то сложновато решил задачу(достаточно простого динамического ната)
Да и не совсем адекватно нарисовал картинку со схемой(как то странно смотриться VPN туннель с 24 маской).

solarfly 13 апр 2011 в 12:09

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

Честно скажу, что схему рисовал в первый раз в жизни, для чего пришлось осваивать Dia. С ГОСТовскими стандартами не знаком. Но вроде все наглядно.

Согласен по поводу маски, для класса сети типа А маска должна быть 8. Но тут бесклассовая адресация (CIDR). Не вижу смысла использовать весь диапазон, когда он может пригодиться для иных целей, например для других конфигураций VPN-сервера.
Да и по сути, я сильно конфиг OpenVPN не менял, такую маску поставили разработчики по умолчанию. Можете у них узнать.

click0 13 апр 2011 в 13:34

Для туннеля надо маску не /24, а /30. Соединение Point-to-Point, как-никак.

solarfly 13 апр 2011 в 15:13

Маска выдается OpenVPN-cервером из конфигурационного файла. Маска /30 в данном случае не подойдет, клиентов у VPN-сервера может быть больше, чем позволяет маска /30. Надо или не надо — зависит от обстоятельств.

click0 13 апр 2011 в 15:20

В данном случае туннель между двумя устройствами, а так как на канале больше нет устройств, которым надо ip и маска поэтому — /32.
И так OpenVPN должен сделать с каждым туннелем.
Если OpenVPN экономит выделенные IP, тогда клиентам IP c маской /32.
Из какого блока IP OpenVPN берет адреса для туннелей непринципиально.

solarfly 13 апр 2011 в 15:58

Не понимаю, чем вам так мешает маска /30. И почему Вы поэтому поводу готовы на спор тратить столько времени. Это не принципиально для сабжа.
В вашем случае OpenVPN будет брать адреса из диапазона 10.8.1.1-2, к серверу могут быть еще подключения. Как поведет себя OpenVPN при исчерпании это пула адресов я не знаю.

solarfly 13 апр 2011 в 15:59

Возможно разработчики OpenVPN Вам дадут больше пояснений, чем я. Обратитесь к ним.

click0 13 апр 2011 в 16:23

Когда у вас будет дифцит реальных адресов и вы поймете, что такое правильный дизайн сети.
При исчерпании пула адресов OpenVPN не будет создавать туннели.