Локальная сеть глобального масштаба

У нашей компании есть группы серверов, расположенные в разных датацентрах и даже городах. На данный момент мы используем 6 датацентров. Между большей частью серверов идёт интенсивный обмен трафиком, а протоколы обмена данными не всегда обеспечивают необходимый уровень защиты. Поэтому мы решили создать общую локальную сеть между всеми имеющимися серверами. Мы отказались от создания сети при помощи OpenVPN с использованием маршрутизации из-за чрезмерной громоздкости архитектуры подобных сетей. На наш взгляд, самый простой и удобный вариант — это одноранговая сеть. Далее мы расскажем подробнее о том, как создать и настроить одноранговую сеть.

Для ее создания мы используем OpenVPN и Bridge-utils.
Стандартная сеть на OpenVPN состоит из одного или нескольких серверов с OpenVPN и клиентов, которые к ним подключаются. OpenVPN поддерживает соеднинения по протоколам TCP и UDP. Поскольку на наших выделенных серверах нет какой-либо контролируемой фильтрации трафика, лучше выбрать протокол UDP, к тому же UDP является более быстрым протоколом.

Первый сервер

Первый сервер (фактически это наша точка обмена трафиком) настраиваем по стандартной схеме. Поскольку на большинстве серверов установлен Debian, дальнейшие инструкции будут даны с учетом особенностей этой ОС.

aptitude install openvpn openvpn-blacklist
cd /etc/openvpn/
cp -R /usr/share/openvpn/easy-rsa/2.0 /etc/openvpn/easy-rsa
mkdir /etc/openvpn/keys
chmod 750 /etc/openvpn/keys


Правим /etc/openvpn/easy-rsa/vars следующим образом:

export EASY_RSA="/etc/openvpn/easy-rsa"
export KEY_DIR="/etc/openvpn/keys"
export KEY_SIZE=2048
export KEY_COUNTRY=«RU»
export KEY_PROVINCE=«MSK»
export KEY_CITY=«Samara»
export KEY_ORG=«Regtime Ltd.»
export KEY_EMAIL=«support@regtime.net»


Далее по той же схеме готовим ключи:

cd /etc/openvpn/easy-rsa
. ./vars
./clean-all
./build-ca
./build-key-server servername
./build-dh


Создаём минимальный конфиг для сервера в /etc/openvpn/udp-server. Можно указать намного больше параметров: возможности оптимизации очень широки.

dev tap0
proto udp
port 1194
ca keys/ca.crt
cert keys/servername.crt
key keys/servername.key
dh keys/dh2048.pem
user nobody
group nogroup
server 172.18.5.208 255.255.255.240
persist-key
persist-tun
status /dev/shm/openvpn-status-udp
verb 3
client-to-client
client-config-dir ccd-udp
log-append /var/log/openvpn-udp.log
comp-lzo
script-security 2
up "/etc/init.d/lan0 start"
down "/etc/init.d/lan0 stop"


Подключаем его и запускаем сервер:

ln -s udp-server udp-server.conf
/etc/init.d/openvpn start


Обратите внимание на последние три строки конфига. Именно они дают возможность использовать этот сервер в одноранговой сети. Стоит отметить, что сделать это можно только для UDP сервера. Сам скрипт выглядит так — /etc/init.d/lan0:
#!/bin/bash

### BEGIN INIT INFO
# Provides: lan0
# Required-Start: $network $remote_fs $syslog openvpn
# Required-Stop: $network $remote_fs $syslog openvpn
# Should-Start:
# Should-Stop:
# X-Start-Before: $x-display-manager gdm kdm xdm wdm ldm sdm nodm
# X-Interactive: true
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: lan0 service
### END INIT INFO

. /lib/lsb/init-functions

PATH=/bin:/sbin:/usr/bin:/usr/sbin

br=«lan0»
tap=«tap0»
eth=«eth1»
eth_ip=«172.18.5.2»
eth_netmask=«255.255.255.0»
eth_broadcast=«172.18.5.255»

case "$1" in
start)
brctl addbr $br
brctl addif $br $eth

for t in $tap; do
brctl addif $br $t
done

for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up

ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
;;

stop)
ifconfig $br down
brctl delbr $br

ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast
;;
*)
echo «usage lan0 {start|stop}»

exit 1
;;
esac
exit 0


Этот же скрипт можно использовать для rc.d.

update-rc.d lan0 defaults


Последовательность при ручном запуске такая:

/etc/init.d/openvpn start
/etc/init.d/lan0 start
При ручной остановке:
/etc/init.d/lan0 stop
/etc/init.d/openvpn stop


Следует учесть, что при перезапуске OpenVPN lan0 будет подниматься заново. В некоторых случаях это нужно делать вручную. Например, через cron задача выглядит так:

[ -n "`/sbin/ifconfig tap0`" ] && [ -z "`/usr/sbin/brctl show|grep tap0`" ] && /etc/init.d/lan0 start


Сервер готов! Теперь надо создать ключи и сертификаты для клиентов.

Клиенты

На сервере создаём сертификаты для клиентов, которые будут подключаться снаружи:

cd /etc/openvpn/easy-rsa
. ./vars
./build-key client


Разумеется, имя каждого клиента (здесь client) должно быть уникальным.
После ввода и подтверждения данных для сертификата появятся следующие файлы:

client.crt
client.csr
client.key


На стороне клиента нам понадобятся следующие файлы из каталога /etc/openvpn/keys на сервере:

ca.crt
client.key
client.crt


Также на стороне клиента устанавливаем OpenVPN:

aptitude install openvpn openvpn-blacklist
mkdir /etc/openvpn/keys
chmod 750 /etc/openvpn/keys


Копируем ключ и сертификаты в /etc/openvpn/keys:
Создаём простейший конфиг /etc/openvpn/client.conf:
dev tap0
proto udp
client
remote server 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
comp-lzo
verb 3
status /dev/shm/client-status-udp
log /var/log/openvpn-client.log
ping 10
ping-restart 1800
script-security 2
up "/etc/init.d/lan0 start"
down "/etc/init.d/lan0 stop"


Для подключения к общей одноранговой сети используется тот же скрипт lan0 (с исправлением eth_ip на нужный), что и на сервере.

Множество серверов

В сети может быть несколько точек обмена трафиком. При этом необходимо, чтобы клиент мог подключиться к любой из них и попасть в ту же сеть. Ничего сложного в этом нет. Можно настроить любое количество серверов указанным выше способом. Но есть два нюанса.
1. Каждый сервер должен выдавать отдельные уникальные IP адреса.
Это достигается заменой одной строки в конфигах:

server 172.18.5.208 255.255.255.240


2. Нужно синхронизировать сертификаты между серверами OpenVPN.
Самое простое решение — это просто скопировать каталог /etc/openvpn/keys по ssh. Но есть способ лучше — rsync.
Для двухстороннего обмена нам потребуется два скрипта — загрузки обновлений и скачивания оных.
Загрузка — push
#!/bin/bash

export RSYNC_RSH=«ssh -c arcfour -o Compression=no -x -l root»

rsync --delete-after \
-zu --modify-window=10 -aHAX --numeric-ids --sparse \
/etc/openvpn/keys remotehost:/etc/openvpn/keys

Обновление — pop
#!/bin/bash

export RSYNC_RSH=«ssh -c arcfour -o Compression=no -x -l root»

rsync --delete-after \
-zu --modify-window=10 -aHAX --numeric-ids --sparse \
remotehost:/etc/openvpn/keys /etc/openvpn/keys


Обратите внимание на ключ —delete-after. Он используется для того, чтобы после синхронизации удалить файлы, которых нет на стороне назначения. Т.е. pop удалит локально всё то, чего нет на remotehost.

Также важен порядок обновления ключей. В обычных условиях новые ключи и сертификаты нужно создавать на первом (основном) сервере OpenVPN, а все остальные должны получать с него обновления через pop. Таким образом, push нам не нужен вообще. Но при необходимости можно добавлять новых пользователей на любом сервере, и вот тогда надо сначала сделать push для загрузки, а затем pop на всех остальных OpenVPN серверах.

Поскольку взаимодействие идёт по ssh, то всем серверам нужно обменяться ключами ssh для root’а. Ключ можно сгенерить при помощи команды

ssh-keygen -t rsa -b 2048


а скопировать при помощи

ssh-copy-id remote host


Учтите, что на всех этих серверах должен быть разрешен вход для root. Для безопасности можно отключить авторизацию по паролю. /etc/ssh/sshd_config

PermitRootLogin yes
PasswordAuthentication no


Теперь после добавления нового клиента нужно сделать push на сервере, где ключ был добавлен, и pop на всех остальных OpenVPN серверах.

Люди

Иногда сотрудникам приходится работать не из офиса, но им нужен доступ в локальную сеть. Это тоже легко реализовать в рамках lan0. Но поскольку здесь нет однозначности в вопросах операционных систем и фильтрации трафика, то лучше здесь использовать более медленный, но неприхотливый протокол TCP на OpenVPN.

Конфиг /etc/openvpn/tcp-server:
dev tun0
proto tcp
port 1194
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh2048.pem
user nobody
group nogroup
server 172.18.5.248 255.255.255.240
persist-key
persist-tun
status /dev/shm/openvpn-status-tcp
verb 3
client-to-client
client-config-dir ccd-tcp
push «route 172.18.5.0 255.255.255.0»
log-append /var/log/openvpn-tcp.log
comp-lzo


Ключ и сертификат подготавливаются также как и для UDP. Конфиг для такого подключения будет даже несколько проще — client.ovpn:

client
proto tcp
remote server 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo


Клиенты под разные операционки лучше качать с официального сайта: openvpn.net
Webnames.ru
Все, что необходимо для старта интернет-проекта
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 50

    0
    Мы отказались от создания сети при помощи OpenVPN с использованием маршрутизации из-за чрезмерной громоздкости архитектуры подобных сетей. На наш взгляд, самый простой и удобный вариант — это одноранговая сеть.

    А что вы пронимаете под «громоздкостью»? А широковещательные пакеты не сильно мешают?
      0
      А что вы пронимаете под «громоздкостью»?

      Необходимость обеспечивать эту самую маршрутизацию на каждой точке сети, плюс обслуживание маршрутизаторов. Без оной наращивание сети происходит намного проще, что нам и нужно.

      А широковещательные пакеты не сильно мешают?

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

        Вовсе нет, достаточно только на точках обмена трафиком.

        Они нужны некоторым нашим подсистемам.

        И они не сильно мусорят на ВСЮ шифрованную одноранговую сеть?
          0
          Вовсе нет, достаточно только на точках обмена трафиком.

          Это если точка обмена трафиком является шлюзом по умолчанию. А это не так.

          И они не сильно мусорят на ВСЮ шифрованную одноранговую сеть?

          Нет. :)
            0
            Это если точка обмена трафиком является шлюзом по умолчанию. А это не так.

            а тогда какая маршрутизация имеется в виду?
              0
              Допустим, у нас всего 3 сети: 10.0.1.0/24 (2 сервера), 10.0.2.0/24 (10 серверов), 10.0.3.0/24 (3 сервера)
              Каждый сервер имеет внешний IP и внешние сервисы. Т.е default gw wan.
              Объединяем их при помощи OpenVPN без построения общей локальной сети.
              Получаем, например, связи: 10.0.1.1 — 10.0.2.1, 10.0.2.1 — 10.0.3.1
              Теперь как 10.0.3.2 узнает куда ему девать пакеты для 10.0.2.4 или 10.0.1.2?
              Самый простой способ прописать ему маршруты на 10.0.2.0/24 и 10.0.1.0/24 через 10.0.3.1. Иначе он их бросит на wan.
                0
                а 10.0.3.2 — клиент у OpenVPN или нет?
                  0
                  Нет. Он как раз про VPN ничего и не знает.
                    0
                    а как тогда он к одноранговой сети будет подключён?
                      0
                      Статья как раз об этом. :) Собственно объединение делает описанный выше скрипт /etc/init.d/lan0
                      Для одноранговой сети мы используем единую сетевую адресацию. Если рассматривать тот же пример, то придётся расширить маску до /16.
                      И вот тогда пакет от 10.0.3.2 до 10.0.2.4, например, пойдёт по lan, проскочит по мосту на 10.0.3.1, затем по такому же мосту на 10.0.2.1 и попадёт на lan 10.0.2.4. И без всякой маршрутизации.
                        0
                        Статья как раз об этом. :) Собственно объединение делает описанный выше скрипт /etc/init.d/lan0
                        Для одноранговой сети мы используем единую сетевую адресацию. Если рассматривать тот же пример, то придётся расширить маску до /16.

                        Я пропустил выделенный фрагмент комента в самой статье.
                        НО ведь вам тогда придётся менять сетевые настройки всех серверов.
                          0
                          При любой интеграции что-то приходится переделывать. Здесь, пришлось свести всё к единой адресации, т.к. именно это и было нужно.
                          И это оказалось проще чем организовать внутреннюю маршрутизацию на всех серверах.
                          +3
                          ЗАЧЕМ тогда объединять ЦОДы по L2, тем более что адресные пространства не пересекаются? Я вижу одну причину: «чукча не умеет / не знает как делать правильно» (уже имеющимися средствами это делается за несколько минут). Вы не упростили, а, наоборот, серьезно усложнили себе жизнь. L2 DCI, тем более на 6 узлов, как раз наиболее сложная топология, требующая серьезного планирования, под это даже специальные стандарты разрабатывают. IPoEoMPLSoGREoIP например для транспорта — не потеряв резервирования, исключить прохождение лишнего трафика между площадками, изолировать домены STP, в общем и целом — убрать влияние одной площадки на другие; приблуда для отъема у IP адреса роли идентификатора местоположения узла в сети для обеспечения оптимальной маршрутизации входящего трафика, иначе он скакал бы как бешеный между площадками, создавая бешеную нагрузку на каналы.
                          Нет идиотов просто взять и соединить все площадки транками. Ну по крайней мере я раньше так думал.

                          И нет ничего проще, чем банальная L3 связь между площадками — легко обеспечить любое резервирование и любое масштабирование каналов; легко сопровождать; практически невозможно сломать.

                          Если бы я был вашим клиентом — прочитав такой пост, я бы к настоящему моменту уже перестал быть вашим клиентом. Просто на всякий случай.
        +5
        Мать моя женщина!
          +5
          Эм… как забрать от вас свои домены?
            0
            Что мешало установить маршрутизаторы, которые бы справлялись с этой задачей намного продуктивнее? Теже Mikrotik например?
              0
              Да, именно железные маршрутизаторы, пароли на настройки которых знает только админ в центральном офисе. Ибо эникейщикам на местах в этих вопросах лучше не доверять.

              От себя добавлю, что порекомендовал бы использовать TP-Link+openWRT. Мой знакомый, использующий mikrotik, затруднился с ответом на вопрос:
              «сколько времени бизнес будет простаивать при аппаратном выходе из строя mikrotika»
                +2
                Попутный вопрос — а чем обеспечивается надёжность и резервируемость рекомендованного вами решения?

                Почему я предложил выбор микротика, так это из-за наличия решений в 1U корпусе, т.к. топикстартер ставит сервера в дата-центрах. Как известно, многие дата-центры запрещают использовать не юнитовое оборудование.

                А на счёт аппаратного выхода из строя микротика в дата-центре — поможет только наличие второго микротика рядом с сервером в этом же дата-центре. А если они стоят под боком, то достаточно иметь на складе несколько простых микротиков серии RB750, и копию конфигурации.
                  0
                  аа, у Вас и топикстартера просто уровень выше. Я имел в виду малый бизнес, где нерационально покупать два микротика на каждую точку, а сбегать за TP-Link-ом в ближайший магазин недолго.
                0
                Сильная удалённость датацентров от нас и отсутствие собственного персонала в них, который бы смог заменить эти маршрутизаторы в случае необходимости. Простой в несколько дней — не самый лучший вариант развития событий.
                0
                При чтении очередной статьи не устану задавать «неудобные» вопросы:
                1. Учёт «выбывших» ключей клиентов — в OpenVPN принцип разрешено что не запрещено — т.е. пока вы не внесете ключ в чёрный список — клиент может подключиться. А если вы не знаете сколько ключей выдано?

                2. Одновременное подключение из двух мест под одним ключом — стандартно ситуацию невозможно диагностировать
                  +1
                  2. Одновременное подключение из двух мест под одним ключом — стандартно ситуацию невозможно диагностировать

                  По-умолчанию это запрещено.
                    0
                    Да, запрещено. Но на клиенте не так-то просто диагностировать причину неподключения.
                    +1
                    1. Почему мы не знаем количество выданных ключей? Но даже если это внезапно случилось, то достаточно заглянуть в /etc/openvpn/keys. Удалить/заблокировать выбывший ключ, конечно же, придётся вручную. Но в чём здесь проблема?
                    2. Какова практическая ценность одновременных подключений? Тем более, что сеть в первую очередь объединяет серверы, а не людей.
                      0
                      1. Предыдущий админ мог сгенерировать и «взять с собой» ключ, не оставив ничего в /etc/openvpn/keys
                      Его ключ будет подписан CA, и сервер будет принимать подключения, а мы — не знаем что включить в black list

                      2. Ценности одновременного подключения никакой нет, просто если одно подключение с таким ключом уже установлено — повторное не будет устанавливаться, НО причину понять будет непросто.
                        0
                        1. Не готов аргументировано возразить, но поставлю в свой todo list.
                        2. imho проблема раздута… Решатся чтением лога.
                    +6
                    Поэтому мы решили создать общую локальную сеть между всеми имеющимися серверами.

                    Мои глаза меня не подводят? Вы создаете шифрованные туннели между всеми серверами, терминируя их на самих серверах? Спасибо, теперь в моем личном рейтинге «самые кошмарные сетевые решения» появился новый лидер.
                      0
                      Я был уверен, что этот комментарий появится, практически в таком виде =))))
                        0
                        Но оно реально так и выгледит. Я несколько раз в голове строил сеть.
                        У меня только два решение
                        1) вы извращениц
                        2) вы ничего не понимаете в сетях и идете какоим то своим странным и долгим путем.
                          0
                          Но оно реально так и выгледит.

                          Вы ошибаетесь. Читайте внимательно.
                          JDima тоже либо не прочитал, либо не понял.
                            +1
                            Приведенные конфиги мне мало о чем говорят, а текстовые пояснения слишком невнятны.
                              0
                              Но выводы-то далеко идущие это не мешает делать.
                              Того о чём вы пишите нет, не было и не будет.
                              Строятся каналы между существующими ethernet сетями в виде мостов. Каналы — OpenVPN, мосты — bridge-utils.
                                +1
                                Между 6-ю ЦОДами? Тем более рад видеть данное решение в качестве лидера моего рейтинга. Особенно это умиляет ввиду того, что автор хочет 100% доступности, а сделал все, чтобы все 6 площадок могли лечь одновременно.
                                  0
                                  Всё также не поняли, но всё также не одобряете. ;)
                                    0
                                    Я прочитал habrahabr.ru/company/webnames/blog/162193/#comment_5574689 и вконец выпал в осадок. Ради интереса: сколько времени работает в IT человек, придумавший такое? У меня есть подозрение, что буквально вчера он услышал про такую прикольную штуку, как статический маршрут в серверной ОС, но так и не осилил концепцию маршрутизации. И наворотил нечто абсолютно несопровождаемое.
                            0
                            Слава богу — извращенец тут не я =)))
                        0
                        Эталонный пример, как делать не надо. По всем пунктам статьи.
                          0
                          Я только сейчас увидел в какой компании это реализовано. Как передать мои домены другому регистратору?
                          • UFO just landed and posted this here
                              +3
                              1. Для объединения территориально распределенных сетей существует протокол IP. И именно его и нужно использовать в вашем случае. Использование в этом качестве Ethernet over VPN over IP over Ethernet не самая лучшая идея. Проблемы: множественная инкапсуляция и все что из нее вытекает, сложность изменения дизайна сети, масштабируемость, отказоустойчивость, сложность фильтрации, мониторинга.
                              2. На основе тех же OpenVPN сложно, но тоже можно построить на L3 сеть. Есть чудесные опции
                              route, push «route/redirect-gateway
                              client-config-dir
                              ifconfig-push
                              iroute
                              Это вполне достаточный инструментарий для развертывания статической маршрутизации любой сложности.
                              3. Если статической будет недостаточно, можно использовать IPSec и OSPF например. Причем внедрять можно частично, не спеша, по сегментам, не мешая остальным.
                                0
                                1. Проблемы более чем надуманные. Опыт показывает отсутствие оных с изменением дизайна, сложностью фильтрации и мониторинга. Масштабируемость — вообще большая проблема в IT — не претендуем на её решение. А отказоустойчивость… на практике стало лучше чем было.
                                А вот от подробностей проблем множественной инкапсуляции не откажемся.
                                2 и 3 — как раз те самые причины по которым от такого решения и отказались. Чуть более развернуто в диалоге с 4dmonster чуть выше.
                                  +2
                                  Опыт? Расскажите про Ваш опыт фильтрации и мониторинга L2 трафика. Отсуствие проблем вследствии отсуствия фильтрации и мониторинга? )). Масштабируемость давно решена в протоколах, которые я описал выше. Отказоустойчивость из коробки в протоколах динамической маршрутизации. Отсутствие изменения дизайна сети… Вы вчера или позавчера запустили такой дизайн? Побуду Вангой, но предрекаю вам изменение дизайна сети, добавление\удаление новых хостов\площадок не позднее чем ближайший год.
                                  Проблемы множественной инкапсуляции растут в прогрессии относительно уровней инкапсуляции. Сходу, напрмиер, измените MTU транспорта и дивитесь на метаморфозы. Подсказываю, OpenVPN не умеет корректно фрагментировать.
                                  2 и 3 я делаю вывод «неосилили».

                                  На вашем месте, я бы учился признавать ошибки, засел за курс CCNA (за 2 мес, вечером по 2 часа вполне можно осилить) и в своей работе опирался бы на многомиллионный опыт профессионалов, а не на свой, пока его еще нет.
                                    0
                                    А отказоустойчивость… на практике стало лучше чем было.

                                    Расскажите, как реализованы:
                                    1) резервирование каналов, каналообразующих систем (VPN сервера?) и сетевого оборудования.
                                    2) изолирование сетевых сбоев на площадках (на примере простейшего: L2 луп).
                                      0
                                      1. OpenVPN серверов несколько. Они равнозначны. Находятся в двух ДЦ. Все на разных физических серверах. Из доп. сетевого оборудования используются только свичи. Там где серверов всего два — они соединены отдельным шнурком напрямую. Внешние каналы в компетенции датацентров.
                                      2. В конфигах клиентов несколько записей remote. Один клиент подключается только к одному серверу в один момент времени. Самый большой сегмент не является клиентом ни для кого. L2 луп так никак не получится же.
                                        0
                                        1. Как резервируются сервера на остальных 4-х площадках? Как резервируются свитчи? Как резервируются аплинки от серверов до оборудования датацентра?
                                        2. Луп можно вызвать даже специфической настройкой серверов (обычных, не VPN). И даже бывало, что гигабитная сетевушка на ровном месте начинает слать гигабит броадкастов, что примерно равносильно лупу. Как защищаетесь?
                                          0
                                          1. Конфиги для OpenVPN клиентов есть на всех серверах на остальных 4-х площадках. Но сам OpenVPN придётся запустить вручную.
                                          Свитчи — никак.
                                          От серверов до оборудования ДЦ ведут только патч-корды. Заменять их будут, если понадобится, сотрудники ДЦ.

                                          2. От такого — никак.
                                            +1
                                            То есть резервирования нет вообще. Круто, что тут еще сказать? Зачем тогда вообще было разносить системы по нескольким площадкам? Собрали бы на одной. Все равно катастрофоустойчивости нет.
                                              0
                                              А мы всё еще про локальную сеть говорим или вас уже интересуют сервисы компании? Последнее не входит в тему статьи вообще никак.
                                          0
                                          Речь не о петле через впн-тунели, если появится петля на свиче? Любая поясняющая картинка сильно упростила бы дело, но как понял — какие-то свичи есть, к ним что-то подключено, раз «Нет. Он как раз про VPN ничего и не знает.» Вот там и может появится источник широковещательного шторма. Может это не будет петля в виде патчкорта из порта в порт. Может это будет неисправность свича в виде замыкания rx на tx или просто широковещательный флуд. Все это пойдет через мосты по тунелям на другие площадки. То, что этого не было до сих пор, не значит что вероястностью этого можно легко пренебречь. Я знал такие истории, когда тоже люди считали достаточно надуманной проблему и это сходило с рук годами. Зато когда это «выстреливает» — мало не кажется.
                              0
                              Cпасибо!!!

                              Смеялся до слёз!!!

                              Only users with full accounts can post comments. Log in, please.