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

При создании локальной сети не каждый администратор подходит с ответственностью к выбору диапазона адресов. А может и не каждый догадывается о наличии частных диапазонов кроме 192.168.0.0/24. И со временем такая бомба замедленного действия может дать о себе знать. Локальные сети объединяются, возникает потребность в коммуникации между хостами разных сетей. И тут выясняется, что номера сетей совпадают. И менять их по каким либо причинам проблематично или невозможно.

В таком случае, серверу, маршрутизирующему пакеты между сетями, остается сделать вид, что номера сетей различны и выдавать желаемое за действительное. В богатом арсенале Linux есть средства для таких манипуляций: iptables с NETMAP и утилита ip.

Цель


Из сети LAN1 мы хотим послать пакет в сеть LAN2. Но мы не можем послать его в сеть, номер которой одинаков с нашим. В самом частом случае 192.168.0.0/24. Если такой пакет появится в LAN1, он не будет знать, что есть LAN2, он будет искать такую машину в LAN1. Таковы правила маршрутизации по умолчанию.
Значит, надо посылать пакеты с другими адресами, которые уйдут в роутер.

Как это должно вглядеть для наблюдателя из LAN1
Например, пользователь сети LAN1 будет видеть сеть LAN2 как 10.8.1.0/24. Тут уже никакого пересечения адресов. LAN1 доволен.

Как это выглядит с обеих сторон
Из LAN1 приходит пакет с адресом отправителя 192.168.0.100 и адресом назначения 10.8.1.200. Из роутера с интерфейса LAN2 выходит тот же пакет с адресом отправителя 10.8.1.100 и с адресом назначения 192.168.0.200. Пакет проходит до адреса назначения и тот шлет в ответ на адрес отправителя со своим адресом. Пакет уходит в роутер. В нем происходит обратное преобразование и пользователь LAN1 получает ответ с того адреса, на который отправил пакет.
image

Теория. Путь пакета в ядре роутера: netfilter


Здесь я попытаюсь рассказать о путешествии транзитного трафика через наш Linux-роутер. Для полного понимания процесса путешествия пакета лучше видеть схему его прохождения из Википедии по цепочкам netfilter.
image
Наш пакет с [источником|назначением] [192.168.0.100|10.8.1.200] попадает на сетевой интерфейс роутера и первой его цепочкой будет PREROUTING.

PREROUTING

Проходя по цепочке он попадает в таблицу PREROUTING mangle. В которой посредством iptables мы определяем интерфейс, с которого он пришел, и адрес источника. Если это наш пациент, мы его помечаем действием MARK.
После чего пакет [192.168.0.100|10.8.1.200|(marked)] попадает в таблицу nat. Эта таблица предназначена для трансляции адресов. Поскольку не существует реального адреса 10.8.1.200, то на последующем этапе маршрутизации пакет будет отброшен или уйдет в неизвестном направлении. Поэтому заменяем ему адрес назначения на тот, на который он действительно должен пойти именно тут: [192.168.0.100|192.168.0.200|(marked)]. Делается это действием NETMAP, которое заменяет номер сети по маске.

ROUTING

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

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

POSTROUTING

Без изменений доходя до таблицы nat. Мы должны изменить адрес источника. Ведь ответ на пакет [192.168.0.100|192.168.0.200] будет отправлен в локальную сеть, а не в роутер. Чтоб он попал обратно в роутер, меняем адрес источника на несуществующий [10.8.1.100|192.168.0.200]. Опять же NETMAP. После этого пакет выходит в LAN2.
С ответным пакетом проделываем обратную процедуру, чтоб он дошел до изначального источника.

Реализация


iptables -t mangle -A PREROUTING -i tun0 -d 10.8.1.0/24 -j MARK --set-mark 8

Метим входящие пакеты на нашу несуществующую сеть для дальнейшего их опознавания в netfilter. Можно обойтись и без меток, использовать в качестве критериев адрес источника, входной интерфейс и адрес назначения, но в случае сложной маршрутизации с отдельными таблицами маршрутизации решить куда отправить пакет будет проще всего по метке.
iptables -t nat -A PREROUTING -m mark --mark 8 -j NETMAP --to 192.168.0.0/24

Узнаем пакет по метке и действием NETMAP в таблице PREROUTING подменяет номер сети.
iptables -t nat -A POSTROUTING -m mark --mark 8  -j NETMAP --to 10.8.2.0/24

В POSTROUTING NETMAP подменяет адрес источника.
После этого все обращения на подсеть 10.8.1.0/24 будут выглядеть внутри LAN2, как обращения из подсети 10.8.2.0/24.

ROUTING

Чтобы маршрутизировать пакеты по метке необходимо создать свою таблицу маршрутизации.Редактируем /etc/iproute2/rt_tables, добавляя уникальное число и название новой таблицы.
256 netmap
Далее надо добавить правило, по которому в эту таблицу будут направляться пакеты на маршрутизацию.
ip ru add fwmark 8 lookup netmap

Теперь помеченные пакеты будут уходить на маршрутизацию в таблицу netmap.

И последним шагом нужно определить маршруты в таблице netmap.
ip route add default dev eth1 table netmap

Или можно указать в особом случае отдельный шлюз, если в эту сеть трафик от роутера идет через него. Что-то в духе:
ip route add default via 192.168.1.254 dev eth1 table netmap

Пока рано радоваться, к нам придет ответ из LAN2 [192.168.0.100|10.8.2.200].
Надо сделать все тоже самое, но только преобразовать обратно. Увы, netfilter сам этого не делает. Все действия уже описаны, приведу только последовательность команд для преобразования адресов в одну и в обратную сторону. (В первой таблице маршрутизации необходимости в данном случае нет, но при иных обстоятельствах может понадобиться.)
ip rule add fwmark 8 lookup netmap
ip route add 192.168.0.0/24 dev eth1 table netmap
iptables -t mangle -A PREROUTING -i tun0 -d 10.8.1.0/24 -j MARK --set-mark 8
iptables -t nat -A PREROUTING -m mark --mark 8 -j NETMAP --to 192.168.0.0/24
iptables -t nat -A POSTROUTING -m mark --mark 8 -j NETMAP --to 10.8.2.0/24

# в обратную сторону
ip rule add fwmark 9 lookup netmap2
ip route add 192.168.0.0/24 dev tun0 table netmap2
iptables -t mangle -A PREROUTING -i eth1 -d 10.8.2.0/24 -j MARK --set-mark 9
iptables -t nat -A PREROUTING -m mark --mark 9 -j NETMAP --to 192.168.0.0/24
iptables -t nat -A POSTROUTING -m mark --mark 9 -j NETMAP --to 10.8.1.0/24


Результаты


Вот что пишет tcpdump (первый пример с vnc, второй с пингом):
tcpdump -i any port 5900

12:46:46.358969 IP 192.168.0.100.41930 > 10.8.1.200.5900: Flags [P.], seq 647:657, ack 261127, win 1213, options [nop,nop,TS val 460624 ecr 171318], length 10
12:46:46.358978 IP 10.8.2.100.41930 > 192.168.0.200.5900: Flags [P.], seq 647:657, ack 261127, win 1213, options [nop,nop,TS val 460624 ecr 171318], length 10
12:46:46.505847 IP 192.168.0.200.5900 > 10.8.2.100.41930: Flags [.], ack 657, win 64879, options [nop,nop,TS val 171320 ecr 460624], length 0
12:46:46.505861 IP 10.8.1.200.5900 > 192.168.0.100.41930: Flags [.], ack 657, win 64879, options [nop,nop,TS val 171320 ecr 460624], length 0


tcpdump -i any icmp

12:47:46.363905 IP 192.168.0.100 > 10.8.1.200: ICMP echo request, id 2111, seq 1, length 64
12:47:46.363922 IP 10.8.2.100 > 192.168.0.200: ICMP echo request, id 2111, seq 1, length 64
12:47:46.364049 IP 192.168.0.200 > 10.8.2.100: ICMP echo reply, id 2111, seq 1, length 64
12:47:46.364054 IP 10.8.1.200 > 192.168.0.100: ICMP echo reply, id 2111, seq 1, length 64


Tcpdump отлично демонстрирует, как происходит преобразование адресов на входе в один интерфейс и на выходе в другой и в обратную сторону.

Так же отлично работают остальные сервисы, типа Samba и ее аналог на Windows.

Note

Если соединение между сетями организовано посредством туннеля OpenVPN, то для правильной маршрутизации со стороны клиента в конфиг сервера необходимо добавить дополнительный маршрут через туннель.
push "route 10.8.1.0 255.255.255.0"

Warning!

При отладке конфигурации не пытайтесь законнектиться к серверу, на котором шлюз. Соединяйтесь с машинами за ним в LAN2.
И вот почему. Правила расчитаны, что пакет будет проходить через шлюз, i. e.
PREROUTING -> Маршрутизация -> FORWARD -> Маршрутизация -> POSTROUTING
Если пакеты будут адресованы 10.8.2.1 (серверу), то они в результате маршрутизации пойдут в цепочку INPUT и преобразование адреса источника в POSTROUTING не будет выполнено.
PREROUTING -> Маршрутизация -> INPUT -> Приложение
Соответственно, адрес источника не будет измненен и ответ будет послан не на 10.8.2.xy, а на 192.168.0.xy — на маршрут по умолчанию для этого диапазона, т. е. в LAN2, а не в LAN1.
Поделиться публикацией

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    –1
    Как же нужно жопу рвать без динамический адресов. А то что на серверах надо ручками поменять это не резон.
      0
      Ну, например я столкнулся с ситуацией когда статические айпишники достались мне, как наследие предыдущего сисадмина, вбитыми конкретно на машинах пользователей а не на сервере… Т.к. помещение большое — где часть из этого железа — я даже не догадываюсь, да и поменять вручную со статического IP на получение динамического на овер 100 машинах — это не всегда бывает весело, тем более есть нюансы в планировке зданий…
        +1
        Да нет вы не обижайтесь, я сам добра хлебнул такого, хотите байку?
        В общем есть у нас клиент, у них офисы по всей стране, очень много, так у них всех внутри компании адреса класса А но не стандартные, у них все офисы связаны сейчас а раньше был кавардак, так какой то админ идиот всех перевёл на адреса на 5.0.0.0 причем на статике, не спрашивайте почему, в общем сейчас уже не поменять там 3к машин. Вот так и живут прописывая все дороги ручками.
          0
          У меня была сеть 172.168.x.x — тоже до меня выставили в древние времена, когда не было выхода в интернет даже. Видимо скрестили 172.16.x.x и 192.168.x.x.
          Пришлось перебивать. Ненавижу :(
            +1
            Свои 5 копеек :)
            Крупное промышленное предприятие с парком машин около 500. Когда пришёл админить, был удивлён адресации 132.147.0.0/16. По whois узнал, что диапазон принадлежит The SCO Group, Inc. Через какое-то время в серверной обратил внимание на старый-престарый сервер Sun. Он был первым.
              +1
              На предыдущей, работе решилось все через рассылку, ноги и Radmin.

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

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

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

                0
                С 1 апреля? Вовремя Вы :-)
                0
                Мы (провайдер) как-то разделяли клиентские сети… Несмотря на наличие DHCP сервера, у части клиентов настройки всё равно прописаны статикой. Составили список тех, у кого остались старые настройки, и передали его call-центру, в течение пары недель были обзвонены практически все. После этого завершили разделение. У оставшихся людей со старыми настройками перестало работать, но им достаточно было позвонить в техническую поддержку, чтобы получить инструкции, как вернуть себе работающую сеть.
                  0
                  Самому так недавно позвонили от провайдера, спасибо, что заботитесь о клиентах.
                +3
                Ну, сначала настроить dhcp-сервер. Потом парочку ближайших переключить на dhcp. Потом парочку следующих. А потом видно будет.
                  0
                  Если к машинам есть админский доступ — поменять скриптом, в противном случае надо вначале его получить :)
                    +2
                    Все намного проще, товарищи!
                    Вешаем на прокси, которая пускает всех в Интернет (нет? не верю!) заглушку а-ля «Хотите Интернет? Нажмите Пуск — Выполнить, скопируйте в поля ввода следующее (пишем команду, которая переключает на DHCP — не помню, как в винде) и нажмите ОК». Половина ручных переключится сама, остальные уже можно пройтись :).
                      0
                      Вы держите в ежовых рукавицах своих пользователей. Но все же оригинальный и интересный способ переложить работу админа на самих пользователей.
                        0
                        Лично я? Не держу.
                        Но когда-то я был пользователем, и помню, что такой метод подействовал. ;)
                        Такое поможет, если нет возможности пробежаться всюду самому.
                        Ну и, конечно, никто не отменяет объявления накануне.
                          0
                          Учитывая, что его пользователи сидят с админскими правами — то нифига он не держит.
                            0
                            У меня всего три пользователя, которых я контролирую. Все сидят в Ubuntu без админских прав.
                            Остальные — толпы хомячков клиентов.
                              0
                              Арр, парсер сожрал HTML. «Хомячков» должно быть перечеркнуто.
                          0
                          так их можно заставить выполнить netsh с DHCP-установками.
                            +2
                            Тоже вариант, расшарить батник с подобным содержимым.
                            netsh interface ip set address name="Подключение по локальной сети" source=dhcp
                            Жаль, что в виндовых клиентах по умолчанию нет никакого шелла, можно было бы все автоматизировать и не париться.
                      0
                      Не очень понятно что произойдет если в обеих подсетях будут сервисы с одинаковым айпи.
                        0
                        Почему что-то должно произойти? И в этом как раз и прелесть NETMAP'а.
                        Без него можно просто указать в роутах нужные машины, типа:
                        ip route add 192.168.0.x/32 via <адрес шлюза>
                        И вот тут как раз Ваш вопрос будет актуален, если будут совпадающие ip.
                          0
                          Это на каждой машине прописать, да?
                            0
                            А, все понял, они же замапяться в другую подсеть.
                            0
                            Обьясните неразумному, куда все же полетит ICMP пакет, если я с любой машины в LAN1 пропингую адрес 192.168.0.111 при условии, что в обеих сетях есть машины с таким адресом?
                              0
                              Не называйте себя так.
                              Вы ping'анете LAN1, если такой машины нет, то пакет никуда не уйдет. Если Вы ping'анете 10.8.1.111, то он из LAN1 уйдет в LAN2 и pong'анется обратно, если там есть машина 192.168.0.111. Для каждой сети существует только своя сеть с адресом 192.168.0.0/24.
                                0
                                Будет видна машина только из первой сети.
                                  0
                                  А как отрабатывается тот момент, что внутри хэдэра ICPM передаются оригинальные IP source и dest? Собственно аналогичный вопрос для SIP?
                                    0
                                    Уже минуло много времени и вопрос такой не стоял, поэтому скорее всего никак.
                              +1
                              Какой ужас.
                              Неужто забыли про proxy-arp?
                                0
                                Не забыл. Туннель OpenVPN L3. Это вроде видно по названию интерфейса. Если не ошибаюсь, то Level 2 выдает tap#, Level 3 tun#.
                                  0
                                  Точно, пропустил название туннельных интерфейсов.
                                  Мои извинения!
                                  0
                                  Тоже почему-то подумалось, что здесь спасет проброс моста.
                                  0
                                  а как бы еще 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. Покритикуйте идею.
                                    0
                                    Идея хорошая, что-то вроде DNS-proxy, но подобных решений не встречал. Вы можете быть первым.
                                    Простейший вариант — запустить DNS-сервер на VPN-сервере с измененными копиями зонных файлов с главного DNS-сервера подсети.
                                      0
                                      Сорри за глупый вариант. Mykhailo Predeus дал совет по почте использовать view в DNS. Спасибо ему, про такую вещь совсем забыл.
                                        0
                                        view я так понял на dns сервере в LAN1, но это если в LAN1 днс сервер bind.

                                        А если в LAN1 Win сервер с AD и интегрированным днс? Можно конечно поднять bind на VPN-сервере в качетсве вторичного DNS-сервера и отдавать ему зону с Win-сервера, но здесь view будет уже не преминим.
                                          0
                                          DNS в LAN1 можно попробовать настроить как подчиненный для зоны мастер-серевера из LAN2 c view, хотя я не знаю, предоставляет ли такие возможности администратору DNS Windows Server'а. Но наличие AD предполагает возможность централизованной смены IP-адресов через DHCP, и описанной проблемы не возникнет. А там деревья, леса и прочие особенности.
                                      0
                                      Идея рабочая. Настроил подобное с помощью 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()
                                      
                                        0
                                        Насколько стабильно работает?

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

                                          Работает пока один день, поэтому о стабильности говорить преждевременно)
                                      +1
                                      Кстати, чем-то похожая на эту схему описана в LARTC. Там оно называется, кажется, Double NAT.
                                        0
                                        Неправильный подход.
                                        На обоих шлюзах сооружайте NAT, DHCP сервера и туннель между шлюзами.
                                        Находите пересекающиеся IP и меняйте им адреса, подключив DHCP.
                                        На шлюзах поднимается arp-proxy.
                                        А то, что вы соорудили — двойной NAT со своим протоколом маршрутизации.
                                          0
                                          Я давно не претендую на адекватность своих действий. Но все же хотелось бы узнать, почему подход неправильный? Как применять DHCP, если в условиях задачи явно указано, что нет возможности менять адреса? Вы ведь тоже предлагаете NAT с обеих сторон с кучей манипуляций, когда это решение в несколько команд без установки дополнительного ПО.
                                            –1
                                            >Я давно не претендую на адекватность своих действий.
                                            Это плохо.
                                            >Но все же хотелось бы узнать, почему подход неправильный?
                                            Вы не поняли проблему, не нашли работающие решения и решили городить свои костыли.

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

                                            P.S. Вы не умеете лениться! (с)
                                              +1
                                              Может и не умею лениться, но люблю. :)

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

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

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

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

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

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

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

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

                                                >Я довольно смутно могу представить реализацию того, что Вы предложили.
                                                >Тем более она не для данного конкретного случая. Но мне интересно увидеть статью по этому поводу или хотя бы ссылки.
                                                Я думаю, Вам стоит для начала прочитать литературу про маршрутизацию и про модель OSI, а не бросаться с шашками наголо на iptables.
                                                  0
                                                  Доверюсь Вашему опыту и последую рекомендациям. ;)
                                          0
                                          Автор как то сложновато решил задачу(достаточно простого динамического ната)
                                          Да и не совсем адекватно нарисовал картинку со схемой(как то странно смотриться VPN туннель с 24 маской).
                                            0
                                            Если можете продемонстрировать что-то более простое с тем же результатом, то очень хотелось бы увидеть. (Без сарказма, мне интересны и другие пути решения задачи.)

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

                                            Согласен по поводу маски, для класса сети типа А маска должна быть 8. Но тут бесклассовая адресация (CIDR). Не вижу смысла использовать весь диапазон, когда он может пригодиться для иных целей, например для других конфигураций VPN-сервера.
                                            Да и по сути, я сильно конфиг OpenVPN не менял, такую маску поставили разработчики по умолчанию. Можете у них узнать.
                                              –1
                                              Для туннеля надо маску не /24, а /30. Соединение Point-to-Point, как-никак.
                                                0
                                                Маска выдается OpenVPN-cервером из конфигурационного файла. Маска /30 в данном случае не подойдет, клиентов у VPN-сервера может быть больше, чем позволяет маска /30. Надо или не надо — зависит от обстоятельств.
                                                  –2
                                                  В данном случае туннель между двумя устройствами, а так как на канале больше нет устройств, которым надо ip и маска поэтому — /32.
                                                  И так OpenVPN должен сделать с каждым туннелем.
                                                  Если OpenVPN экономит выделенные IP, тогда клиентам IP c маской /32.
                                                  Из какого блока IP OpenVPN берет адреса для туннелей непринципиально.
                                                    0
                                                    Не понимаю, чем вам так мешает маска /30. И почему Вы поэтому поводу готовы на спор тратить столько времени. Это не принципиально для сабжа.
                                                    В вашем случае OpenVPN будет брать адреса из диапазона 10.8.1.1-2, к серверу могут быть еще подключения. Как поведет себя OpenVPN при исчерпании это пула адресов я не знаю.
                                                      0
                                                      Возможно разработчики OpenVPN Вам дадут больше пояснений, чем я. Обратитесь к ним.
                                                        –1
                                                        Когда у вас будет дифцит реальных адресов и вы поймете, что такое правильный дизайн сети.
                                                        При исчерпании пула адресов OpenVPN не будет создавать туннели.
                                                          0
                                                          К счастью мне не грозит исчерпание частного диапазона. Рекомендую ссылку.
                                                            –1
                                                            Да-да, погуглите, к чему приводит совместное использование серых и белых IP адресов в глобальной маршрутизации.
                                                              0
                                                              Спасибо погуглил. Был не прав. Мое почтение.
                                                                –1
                                                                Для тех кто не гуглил, на шлюзах серые IP отсекаются.
                                                                  0
                                                                  Какое это имеет отношение к сабжу?
                                              0
                                              tap интерфейс для openvpn + brtcl нет? Серверам даже не надо айпишник на tap вешать.

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

                                              Самое читаемое