Русский
Русский
English
Статистика
Реклама

Сети

Одновременный speedtest на нескольких LTE-модемах

08.07.2020 12:13:32 | Автор: admin
На карантине мне предложили поучаствовать в разработке устройства измерения скорости LTE-модемов для нескольких операторов сотовой связи.



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

Сразу скажу, что задача не самая простая и наукоемкая, расскажу, какие проблемы мне встретились и как я их решал. Итак, поехали.

Примечание


Измерение скорости LTE-соединение дело весьма сложное: необходимо правильно выбрать оборудования и методику измерения, также хорошо представлять топологию и работу сотовой сети. Плюс на скорость может влиять несколько факторов: количество абонентов на соте, погодные условия, даже от соты к соте скорость может разительно отличаться из-за топологии сети. В общем, эта задача с огромным количеством неизвестных, и ее правильно решить может только оператор связи.

Изначально заказчик хотел просто гонять курьера с телефонами операторов, проводить измерения прямо на телефоне и далее в тетрадку записывать результаты измерения скорости. Мое решение измерения скорости сетей lte, хоть не идеально, но решает поставленную задачу.

Из-за нехватки времени, я принимал решения не в пользу удобства или практичности, а в пользу скорости разработки. Например, для удаленного доступа поднимался обратный ssh, вместо более практичного vpn, ради экономии времени на настройку сервера и каждого отдельного клиента.

Техническое задание


Как сказано в статье Без ТЗ: почему клиент не хочет его: Не работайте без ТЗ! Никогда, нигде!

Техническое задание было достаточно простое, я немного его расширю для понимания конечного пользователя. Выбор технических решений и оборудования был продиктован заказчиком. Итак, само ТЗ, после всех согласований:

На базе одноплатного компьютера vim2 сделать тестер скорости lte-соединения через модемы Huawei e3372h 153 нескольких операторов связи (от одного до n). Так же необходимо получать координаты с GPS-приемника, подключенного по UART. Замеры скорости производить с помощью сервиса www.speedtest.net и сводить их в таблицу вида:



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

ТЗ я описал в вольной форме, после множества согласований. Но смысл задачи уже виден. Срок на все про все был дан неделя. Но в реальности он растянулся на три недели. Это с учетом того, что я делал это только после основной работы и по выходным.

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

Архитектура и разработка


Схема проста и очевидна. Поэтому оставлю ее без особых комментариев.



Весь проект решил реализовать на python, несмотря на то, что опыта разработки на этом языке у меня не было совсем. Выбрал его, так как была куча готовых примеров и решений, которые могли ускорить разработку. Поэтому, прошу всех профессиональных программистов не ругать мой первый опыт разработки на python, и всегда с удовольствием готов услышать конструктивную критику, для повышения своего скилла.

Также в процессе открыл, что python имеет две ходовые версии 2 и 3, в результате остановился на третьей.

Аппаратные узлы


Одноплатник vim2


В качестве основной машины мне был дан одноплатник vim2



Отличный, мощный медиакомбайн для умного дома и SMART-TV, но на редкость неподходящий для данной задачи, или скажем так, слабо подходящий. Например, его главная ОС это Android, а Linux это попутная ОС, и соответственно никто не гарантирует качественной работы всех узлов и драйверов под Linux. И я предполагаю, что часть проблем была связана с драйверами USB данной платформы, поэтому модемы работали на данной плате не так как ожидал. Так же у него очень плохая и разрозненная документация, поэтому каждая операция занимала много времени копания в доках. Даже рядовая работа с GPIO попила много крови. Например, чтобы настроить работу со светодиодом, мне понадобилось несколько часов. Но, если быть объективным, то принципиально не было важно, что за одноплатник, главное, чтобы работал и были USB-порты.

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

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

О прошивке криво рассказано тут. Перевожу со странного на русский. Для того, чтобы прошить плату, мне необходимо подключить аппаратный UART. Подключал его следующим образом.

  • Tool Pin GND: <> Pin17 of VIMss GPIO
  • Tool Pin TXD: <> Pin18 of VIMss GPIO (Linux_Rx)
  • Tool Pin RXD: <> Pin19 of VIMss GPIO (Linux_Tx)
  • Tool Pin VCC: <> Pin20 of VIMss GPIO



После чего, я скачал прошивку отсюда. Конкретная версия прошивки VIM1_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20191231.
Для того, чтобы залить данную прошивку, мне необходимы нужны утилиты. Более подробно об этом рассказано тут. Под Windows не пробовал прошивать, а вот о прошивке под Linux надо пару слов рассказать. Для начала установлю утилиты, согласно инструкции.

git clone https://github.com/khadas/utilscd /path/to/utilssudo ./INSTALL

Иии Ничего не работает. Потратил пару часов занимаясь правками установочных скриптов, чтобы все корректно установилось у меня. Что там делал не помню, но тоже еще тот цирк с конями. Так что будьте осторожны. Но без этих утилит дальше мучить vim2 смысла нет. Лучше с ним вообще не связываться!

После семи кругов ада, конфигурации скриптов и установки получил пакет работающих утилит. Подключил плата по USB к моему компьютеру линукс, и так же подключен UART по схеме выше.
Настраиваю мой любимый терминал minicom на скорость 115200, без аппаратного и программного контроля ошибок. И приступаем.



При загрузке VIM2 в терминале UART нажимаю какую-либо клавишу, например пробел, чтобы остановить загрузку. После того, как появится строка

kvim2# 

Ввожу команду:

kvim2# run update

На хосте, откуда загружаем, выполняю:

burn-tool -v aml -b VIM2 -i  VIM2_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20191231.img

Все, фух. Прошил, на плате есть Linux. Логин/пароль khadas:khadas.

После этого небольшие первичные настройки. Для дальнейшей работы отключаю пароль у sudo (да, не безопасно, но удобно).

sudo visudo

Редактирую строку до вида и сохраняем

# Allow members of group sudo to execute any command%sudo ALL=(ALL:ALL) NOPASSWD: ALL

После чего меняю текущую локаль, чтобы время было по Москве, иначе будет по Гринвичу.

sudo timedatectl set-timezone Europe/Moscow

либо

ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Если вам показалось сложно, то не пользуйтесь данной платой, лучше Raspberry Pi. Честно.

Модем Huawei e3372h 153


Данный модем у меня попил крови знатно, и, по сути, он и стал самым узким местом всего проекта. Вообще, название модем для данных устройств совершенно не отражает суть работы: это мощнейший комбайн, эта железяка имеет составное устройство, которое прикидывается CD-ROM для того, чтобы установить драйвера, а потом переходит в режим сетевой карты.

Архитектурно, с точки зрения пользователя Linux после всех настроек, выглядит так: после подключения модема, у меня появляется сетевой интерфейс eth*, который по dhcp получает ip адрес 192.168.8.100, и шлюз по умолчанию 192.168.8.1.

И самый главный момент! Данная модель модема, не умеет работать в режиме именно модема, который управляется АТ-командами. Все было бы сильно проще, создать ppp-соединения на каждый модем и дальше уже оперировать с ними. Но в моем случае сам (точнее дайвера Linux согласно правилам udev), создает eth-интерфейс и по dhcp назначают ему ip-адрес.

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



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

Изначально у меня было простое решение: с помощью команды ifconfig или ip гасить все интерфейсы и просто включать по очереди один и тестировать его. Решение было всем хорошо, кроме того, что в моменты коммутации я не имел возможности подключиться к устройству. А поскольку коммутации частые и быстрые, то фактически у меня не было возможности подключиться вообще.

Поэтому я выбрал путь менять вручную ip-адреса модемов и дальше гонять трафик с помощью настроек маршрутизации.



На этом у меня проблемы с модемами не закончились: в случае проблем с питанием, они отваливались, требовалось хорошее стабильное питание USB-хаба. Эту проблему решил жестко припаяв питание прямо к хабу. Другая проблема, с которой я столкнулся и которая погубила весь проект: после перезагрузки или холодного старта устройства определялись не все модемы и не всегда, и почему это происходило и по какому алгоритму мне установить не удалось. Но обо всем по порядку.

Для корректной работы модема, я установил пакет usb-modeswitch.

sudo apt updatesudo apt install -y usb-modeswitch

После чего, модем после подключения будет корректно определяться и конфигурироваться подсистемой udev. Проверяю, просто подключив модем и убедившись, что сеть появилась.
Еще одна проблема, которую я не смог решить: это как из этого модема получить имя оператора, с которым мы работаем? Имя оператора содержится в веб-интерфейсе модема по адресу 192.168.8.1. Это динамическая веб-страница, которая получает данные посредством ajax-запросов, поэтому просто wget-тнуть страницу и спарсить имя не получится. Поэтому начал смотреть, как отработать web-страницу и т.п., и понял, что занимаюсь какой-то ерундой. В результате плюнул, и оператора начал получать с помощью API самого Speedtest.

Многое было бы проще, если бы у модема был бы доступ через AT-команды. Можно было бы его переконфигурировать, создавать ppp-соединение, назначать IP, получать оператора связи и т.д. Но увы, работаю с тем что дали.

GPS


GPS-приемник, который мне выдали, имел интерфейс UART и питание. Это было не самое лучшее решение, но тем не менее рабочее и простое. Приемник был примерно такого вида.



Честно говоря, впервые работал с GPS-приемником, но как предполагал, все давно придумано за нас. Так что просто пользуемся готовыми решениями.

Для начала включаю uart_AO_B (UART_RX_AO_B, UART_TX_AO_B) для подключения GPS.

khadas@Khadas:~$ sudo fdtput -t s /dtb.img /serial@c81004e0 status okay

После проверяю успешность операции.

khadas@Khadas:~$ fdtget /dtb.img /serial@c81004e0 statusokay

Данная команда, судя по всему, на лету редактирует devtree, что весьма удобно.

После успеха этой операции перезагружаемся и устанавливаем gps-демон.

khadas@Khadas:~$ sudo reboot

Установка gps-демона. Устанавливаю все и отрубаю его сразу для дальнейшей конфигурации.

sudo apt install gpsd gpsd-clients -ysudo killall gpsd /* GPS daemon stop/disable */sudo systemctl stop gpsd.socketsudo systemctl disable gpsd.socket

Редактирую файл настроек.

sudo vim /etc/default/gpsd

Устанавливаю UART, на котором будет висеть GPS.

DEVICES="/dev/ttyS4"

И после все включаем и стартуем.

/* GPS daemon enable/start */sudo systemctl enable gpsd.socketsudo systemctl start gpsd.socket

После чего, подключаю GPS.



В руках провод GPS, под пальцами видны провода UART отладчика.

Перезагружаюсь, и проверяю работу GPS с помощью программы gpsmon.



На этом скриншоте спутников не видать, но видно общение с GPS-приемником, и это говорит, что все хорошо.

На python опробовал много вариантов работы с данным демоном, но я остановился на том, который корректно работал с python 3.

Устанавливаю необходимую библиотеку.

sudo -H pip3 install gps3 

И ваяю код работы.

from gps3.agps3threaded import AGPS3mechanism...def getPositionData(agps_thread):counter = 0;while True:longitude = agps_thread.data_stream.lonlatitude = agps_thread.data_stream.latif latitude != 'n/a' and longitude != 'n/a':return '{}' .format(longitude), '{}' .format(latitude)counter = counter + 1print ("Wait gps counter = %d" % counter)if counter == 10:ErrorMessage("Ошибка GPS приемника!!!")return "NA", "NA"time.sleep(1.0)...f __name__ == '__main__':...#gpsagps_thread = AGPS3mechanism()  # Instantiate AGPS3 Mechanismsagps_thread.stream_data()  # From localhost (), or other hosts, by example, (host='gps.ddns.net')agps_thread.run_thread()  # Throttle time to sleep after an empty lookup, default '()' 0.2 two tenths of a second

Если мне нужно получить координаты, то делается это следующим вызовом:

longitude, latitude = getPositionData(agps_thread)

И в течении 1-10 секунд я либо получу координату, либо нет. Да, у меня попыток получить координаты было десять. Не оптимально, криво и косо, но работает. Я решил так сделать, потому что GPS может ловить плохо и не всегда получать данные. Если ждать получения данных, то в случае работы в глухом помещении, программа зависнет в это месте. Поэтому реализовал такой не элегантный вариант.

В принципе, было бы больше времени, можно было бы напрямую по UART получать данные с GSP, парсить их в отдельном потоке и работать с ними. Но времени не было совсем, отсюда лютый некрасивый код. И да, мне не стыдно.

Светодиод


С подключением светодиода было все просто и сложно одновременно. Главная сложность в том, что номер пина в системе не соответствует номеру пина на плате и потому что документация написана левой пяткой. Чтобы сопоставить номер аппаратного пина и номер пина в ОС, надо выполнить команду:

gpio readall

Будет выведена таблица соответствия пина в системе, и на плате. После чего я уже могу оперировать пином в самой ОС. В моем случае светодиод подключен к GPIOH_5.



Перевожу пин GPIO в режим вывода.

gpio -g mode 421 out

Записываю нуль.

gpio -g write 421 0

Записываю единицу.

gpio -g write 421 1


Все горит, после записи 1

#gpio subsistemdef gpio_init():os.system("gpio -g mode 421 out")os.system("gpio -g write 421 1")def gpio_set(val):os.system("gpio -g write 421 %d" % val)def error_blink():gpio_set(0)time.sleep(0.1)gpio_set(1)time.sleep(0.1)gpio_set(0)time.sleep(0.1)gpio_set(1)time.sleep(0.1)gpio_set(0)time.sleep(1.0)gpio_set(1)def good_blink():gpio_set(1)

Теперь, в случае ошибок я вызываю error_blink() и светодиод нам красиво помигает.

Программные узлы


Speedtest API


Большая радость, что у сервиса speedtest.net есть свой собственный python-API, посмотреть можно на Github.

Чем хорошо, что есть исходные коды, которые тоже можно посмотреть. Как работать с данным API (простейшие примеры) можно посмотреть в соответствующем разделе.

Устанавливаю python-библиотеку следующей командой.

sudo -H pip3 install speedtest-cli

Для примера вы можете вообще поставить спидтестер в Ubuntu прямо из реп. Это тоже самое python-приложение, которое потом можно запустить прямо из консоли.

sudo apt install speedtest-cli -y

И произвести замеры скорости вашего интернета.

speedtest-cli
Retrieving speedtest.net configuration...
Testing from B***** (*.*.*.*)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by MTS (Moscow) [0.12 km]: 11.8 ms
Testing download speed................................................................................
Download: 7.10 Mbit/s
Testing upload speed......................................................................................................
Upload: 3.86 Mbit/s


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

import speedtestfrom datetime import datetime...#Указываем конкретный сервер для теста#6053) MaximaTelecom (Moscow, Russian Federation)servers = ["6053"]# If you want to use a single threaded testthreads = Nones = speedtest.Speedtest()#получаем имя оператора сотовой связиopos = '%(isp)s' % s.config['client']s.get_servers(servers)#получаем текстовую строку с параметрами сервераtestserver = '%(sponsor)s (%(name)s) [%(d)0.2f km]: %(latency)s ms' % s.results.server#тест загрузкиs.download(threads=threads)#тест выгрузкиs.upload(threads=threads)#получаем результатыs.results.share()#После чего формируется строка для записи в csv-файл.#получаем позицию GPSlongitude, latitude = getPositionData(agps_thread)#время и датаcurdata = datetime.now().strftime('%d.%m.%Y')curtime = datetime.now().strftime('%H:%M:%S')delimiter = ';'result_string = opos + delimiter + str(curpos) + delimiter + \curdata + delimiter + curtime + delimiter + longitude + ', ' + latitude + delimiter + \str(s.results.download/1000.0/1000.0) + delimiter + str(s.results.upload / 1000.0 / 1000.0) + \delimiter + str(s.results.ping) + delimiter + testserver + "\n"#тут идет запись в файл логов

Здесь тоже оказалось не так все просто, хотя, казалось бы, куда проще. Изначально параметр servers у меня был равен [], мол выбери лучший сервер. В результате у меня были случайные сервера, и как нетрудно догадаться, плавающая скорость. Это достаточно сложная тема, использовать фиксированный сервер, если да, то какой или динамический, требует исследования. Но вот пример графиков замеров скорости оператора Билайна при динамическом выборе тестового сервера и статически зафиксированного.


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


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

Шерсть при тестировании есть и там и там, и ее нужно убирать математическими методами. Но при фиксированном сервере ее немного меньше и амплитуда стабильнее.
Вообще это место больших исследований. И я бы проводил замеры скорости к своему серверу, по средством утилиты iperf. Но мы не отходим от ТЗ.

Отправка почты и ошибок


Для отправки почты попробовал несколько десятков различных вариантов, но в результате остановился на следующем. Зарегистрировал почтовый ящик на yandex и далее взял данный пример отправки почты. Проверил его и внедрил в программу. В этом примере разбираются различные варианты, в том числе отправка с gmail и т.п. Возится с поднятием своего почтового сервера мне не хотелось и не было времени на это, но как потом оказалось тоже напрасно.

Отправка логов производил по планировщику, при наличии связи, каждые 6 часов: в 00 часов, 06 утра, 12 дня и 18 вечера. Отправлял следующим образом.

from send_email import *...message_log = "Логи тестирования платы 1"EmailForSend = ["dlinyj@trololo.ru", "pupkin@trololo.ru"]files = ["/home/khadas/modems_speedtest/csv"]...def sendLogs():global EmailForSendcurdata = datetime.now().strftime('%d.%m.%Y')сurtime = datetime.now().strftime('%H:%M:%S')try:for addr_to in EmailForSend:send_email(addr_to, message_log, "Логи за " + curdata + " " + сurtime, files)except:print("Network problem for send mail")return Falsereturn True

Ошибки тоже изначально отправлялись. Для начала они накапливались в списке, и потом отправлял также с помощью планировщика, при наличии связи. Однако потом возникли проблемы с тем, что yandex имеет ограничение на количество отправляемых сообщений в сутки (это боль, печаль и унижение). Поскольку ошибок даже в минуту могло быть огромное количество, соответственно от отправки ошибок по почте пришлось отказаться. Так что имейте в виду, при автоматической отправки через сервисы яндекса о такой проблеме.

Сервер обратной связи


Для того, чтобы иметь доступ к удаленной железке и иметь возможность ее донастроить и переконфигурировать мне понадобился внешний сервер. Вообще, справедливости говоря, правильно было бы все данные отправлять на сервер и в веб-интерфейсе строить все красивые графики. Но не все сразу.

В качестве VPS я выбрал ruvds.com. Можно было бы взять самый простой сервер. И в целом для моих бы целей этого хватило бы за глаза. Но поскольку платил за сервер не из своего кармана, решил взять с небольшим запасом, чтобы хватило, если будем разворачивать web-интерфейс, свой SMTP-сервер, vpn и т.д. Плюс иметь возможность настроить Telegram-бота и не иметь проблем с его блокировками. Поэтому выбрал Amsterdam и следующие параметры.



В качестве способа связи с железкой vim2 выбрал обратное ssh соединение и как показала практика не самое лучшее. При разрыве соединения, сервер удерживает порт и по нему невозможно подключиться некоторое время. Поэтому, все же лучше использовать другие способы связи, например vpn. В будущем хотел перейти на vpn, но не успел.

Не буду вдаваться в подробности настройки файрвола, ограничения прав, отключения ssh соединения root и прочие прописные истины настройки VPS. Хочется верить, что вы и так все знаете. Для удаленного соединения, создаю нового пользователя на сервере.

adduser vimssh

На нашей железке генерирую ключи ssh соединения.

ssh-keygen

И копирую их на наш сервер.

ssh-copy-id vimssh@host.com

На нашей железке создаю автоматическое подключение обратного ssh при каждой загрузке.

[Unit]
Description=Auto Reverse SSH
Requires=systemd-networkd-wait-online.service
After=systemd-networkd-wait-online.service
[Service]
User=khadas
ExecStart=/usr/bin/ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -CD 8080 -R 8083:localhost:22 vimssh@host.com
RestartSec=5
Restart=always
[Install]
WantedBy=multi-user.target


Обратите внимание на порт 8083: он и определяет по какому порту у меня будет осуществляется подключение через обратный ssh. Добавляем в автозагрузку и стартуем.

sudo systemctl enable autossh.servicesudo systemctl start autossh.service

Можно даже посмотреть статус:

sudo systemctl status autossh.service

Теперь, на нашем VPS-сервере, если выполнить:

ssh -p 8083 khadas@localhost

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

Собираем все воедино



Включение, приступаем к разработке и отладке

Фух, ну вроде все, описал все узлы. Теперь пришло время собрать все это в единую кучу. Код можно посмотреть вот тут.

Важный момент с кодом: Данный проект вот так вот влоб может не запуститься, так как затачивался на определенную задачу, определенной архитектуры. Хоть я и даю исходники, но все же самое ценное разберу вот тут, прямо в тексте, иначе совершенно непонятно.

В начале у меня идет инициализация gps, gpio и запуск отдельного потока планировщика.

#запуск потока планировщикаpShedulerThread = threading.Thread(target=ShedulerThread, args=(1,))pShedulerThread.start()

Планировщик достаточно прост: он смотрит не пришло ли время отправки сообщений и какой сейчас стоит статус ошибок. Если есть флаг ошибки, то мигаем светодиодом.

#shedulerdef ShedulerThread(name):global ready_to_sendwhile True:d = datetime.today()time_x = d.strftime('%H:%M')if time_x in time_send_csv:ready_to_send = Trueif error_status:error_blink()else:good_blink()time.sleep(1)

Самый сложный момент в данном проекте это сохранять обратное ssh-соединение при каждом тесте. В каждом тесте идет заново настройка шлюза по умолчанию и dns-сервера. Поскольку все равно никто не читает, то знайте, что поезд не катается по деревянным рельсам. Кто найдет пасхалку, тому конфетка.

Для этого я создаю отдельную таблица маршрутизации --set-mark 0x2 и правило для перенаправления трафика.

def InitRouteForSSH():cmd_run("sudo iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 22 -j MARK --set-mark 0x2")cmd_run("sudo ip rule add fwmark 0x2/0x2 lookup 102")

Подробнее о том, как это работает можно прочитать в этой статье.

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

network_list = getNetworklist()

Получение списка сетевых интерфейсов достаточно простое.

def getNetworklist():full_networklist = os.listdir('/sys/class/net/')network_list = [x for x in full_networklist if "eth" in x and x != "eth0"]return network_list

После получения списка, задаю IP-адреса всем интерфейсам, как я приводил на картинке в главе про модем.

SetIpAllNetwork(network_list)def SetIpAllNetwork(network_list):for iface in network_list:lastip = "%d" % (3 + network_list.index(iface))cmd_run ("sudo ifconfig " + iface + " 192.168.8." + lastip +" up")

Далее просто в цикле иду по каждому интерфейсу. И конфигурирую каждый интерфейс.

for iface in network_list:ConfigNetwork(iface)

def ConfigNetwork(iface):#сбрасываем все настройкиcmd_run("sudo ip route flush all")#Назначаем шлюз по умолчаниюcmd_run("sudo route add default gw 192.168.8.1 " + iface)#задаем dns-сервер (это нужно для работы speedtest)cmd_run ("sudo bash -c 'echo nameserver 8.8.8.8 > /etc/resolv.conf'")

Проверяю интерфейс на работоспособность, если сети нет, то формирую ошибки. Если сеть есть, то время действовать!

Здесь я настраиваю ssh маршрутизацию на данный интерфейс (если не было сделано), отправляю ошибки на сервер, если время пришло, отправляю логи и в конце концов провожу speedtest и сохраняем логи в csv-файл.

if not NetworkAvalible():....#Здесь мы формируем ошибки....else: #Есть сеть, ура, работаем!#Если у нас проблемный интерфейс, на котором ssh, то меняем его  if (sshint == lastbanint or sshint =="free"):    print("********** Setup SSH ********************")    if sshint !="free":      сmd_run("sudo ip route del default via 192.168.8.1 dev " + sshint +" table 102")    SetupReverseSSH(iface)    sshint = iface#раз сетка работает, то давай срочно все отправим!!!    if ready_to_send:      print ("**** Ready to send!!!")        if sendLogs():          ready_to_send = False        if error_status:          SendErrors()        if (error_status):          SendErrors()#и далее тестируем скорость и сохраняем логи. 

Разве что стоит сказать о функции настройки обратного ssh.

def SetupReverseSSH(iface):cmd_run("sudo systemctl stop autossh.service")cmd_run("sudo ip route add default via 192.168.8.1 dev " + iface +" table 102")cmd_run("sudo systemctl start autossh.service")

Ну и конечно же, необходимо всю эту красоту добавить в автозагрузку. Для этого создаю файл:

sudo vim /etc/systemd/system/modems_speedtest.service

И записываю в него:

[Unit]
Description=Modem Speed Test
Requires=systemd-networkd-wait-online.service
After=systemd-networkd-wait-online.service
[Service]
User=khadas
ExecStart=/usr/bin/python3.6 /home/khadas/modems_speedtest/networks.py
RestartSec=5
Restart=always
[Install]
WantedBy=multi-user.target


Включаю автозагрузку и стартую!

sudo systemctl enable modems_speedtest.servicesudo systemctl start modems_speedtest.service

Теперь я могу смотреть логи того, что происходит с помощью команды:

journalctl -u modems_speedtest.service --no-pager -f

Результаты


Ну теперь самое главное, что же получилось в результате? Приведу несколько графиков, которые мне удалось заснять в процессе разработки и отладки. Графики строились с помощью gnuplot следующим скриптом.

#! /usr/bin/gnuplot -persistset terminal postscript eps enhanced color solidset output "Rostelecom.ps" #set terminal png size 1024, 768#set output "Rostelecom.png" set datafile separator ';'set grid xtics yticsset xdata timeset ylabel "Speed Mb/s"set xlabel 'Time'set timefmt '%d.%m.%Y;%H:%M:%S'set title "Rostelecom Speed"plot "Rostelecom.csv" using 3:6 with lines title "Download", '' using 3:7 with lines title "Upload" set title "Rostelecom 2 Ping"set ylabel "Ping ms"plot "Rostelecom.csv" using 3:8 with lines title "Ping"

Первый опыт был оператора Tele2, который я проводил в течении нескольких дней.



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

Позднее я построил еще ряд графиков, для других операторов связи. Сервер тестирования в этом случае уже был один, и результаты тоже очень интересные.









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

Итог работы


Работа была резко завершена по независящим от меня обстоятельствам. Одной из слабых сторон данного проекта, на мой субъективный взгляд, был модем, который не очень хотел работать одновременно с другими модемами, и при каждой загрузке выделывал такие фортеля. Для данных целей существует громадное количество других моделей модемов, обычно они уже имеют формат Mini PCI-e и ставятся внутрь устройства и их сильно проще конфигурировать. Но это уже совсем другая история. Проект был интересный и был очень рад, что удалось в нем поучаствовать.

Подробнее..

Сетевики нужны и вот почему

30.10.2020 12:22:53 | Автор: admin

Картинка взята из телнет-видео Звёздных войн: telnet towel.blinkenlights.nl

Недавно был пост о том, нужны ли сетевики. До тех пор, пока проверка доступности tcp/ip порта кажется чем-то сложным даже для администраторов БД и AD, сетевики несомненно нужны. Они особенно полезны в тех случаях, когда необходимо понять почему так плохо работает некое клиент-серверное приложение ценой в пароход.
Иногда мало знать ping и traceroute для того, чтобы понять и устранить проблему в сети. Необходимо понимать как работают все звенья в цепи, а сделать это может лишь сетевик. Рассмотрим несколько таких примеров.

Чем Netcat лучше telnet?


Практически всегда, если речь идет о проверке TCP/UDP порта стараются сделать это через telnet и приходится всякий раз просить поставить Netcat. Есть несколько причин, по которым telnet сильно проигрывает. Вот основные причины.

  • telnet не умеет различать причины недоступности порта. Все, или ничего connect, либо fail. Netcat может подсказать, в чем проблема. В этом случае все просто, такого порта в состоянии LISTENING нет.
  • Не умеет в UDP, SCTP и прочие, ничего кроме TCP.
  • Не имеет опций тайм-аута соединения -w и проверки без подключения -z

Теперь не говорите, что вы не знали и закопайте поглубже telnet.

(1:1004)$ ncat -v -w3 -z some.server 1111Ncat: Version 7.80 ( https://nmap.org/ncat )Ncat: Connection refused.

Если этот хост включен и пингуется, то дело скорее всего в файрволе, а telnet этого не покажет. На самом деле все немного сложнее и зависит от настроек файрвола, чаще всего заблокированные пакеты просто отбрасываются, но при желании можно применить другие политики.

(1:1005)$ ncat -v -w3 -z another.server 1521Ncat: Version 7.80 ( https://nmap.org/ncat )Ncat: No route to host.

Бытует мнение, что на Windows нет альтернативы telnet, однако это неверно. Существует штатная утилита Test-NetConnection, которую можно запустить из PowerShell.

Test-NetConnection -ComputerName "www.contoso.com" -Port 80

Linux MIB в помощь


Если ваш сервер вдруг перестал реагировать на внешние раздражители и клиентские запросы стали провисать, не всегда причина в выдернутом сетевом кабеле, или зависших сервисах JBoss/Tomcat. Прежде, чем заводить кейс в тех-поддержку проверьте Linux MIB. Есть множество программ, выдающих статистику ядра Linux по внутренним счетчикам SNMP. Самая распространенная из них все еще netstat.

(1:1008)$ netstat -s |grep prune873 packets pruned from receive queue because of socket buffer overrun(1:1009)$ nstat -s |grep PruneTcpExtPruneCalled   873 0.0

Если сервер не справляется с сетевой нагрузкой и буфер сокета перманентно переполнен, тогда ядро будет просто сбрасывать все новые пакеты и счетчик будет расти на глазах. Чтобы исправить эту ситуацию, можно добавить некоторые настраиваемые параметры в файле sysctl.conf. Текущие значения можно увидеть из файловой системы /proc.

(1:1010)$ cat /proc/sys/net/ipv4/tcp_rmem4096    16384   4194304(1:1011)$ cat /proc/sys/net/ipv4/wcp_rmem4096    16384   4194304(1:1012)$ grep -e tcp_rmem -e tcp_wmem /etc/sysctl.confnet.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 65536 16777216

Три значения параметра tcp_rmem/tcp_wmem обозначает соответственно минимальное, пороговое и максимальное значение. По умолчанию величины выставлены довольно разумно, поэтому менять их без веских оснований не стоит. Чаще всего такая ситуация может возникнуть на сети с пропускной способностью 10 GiB/s. После сохранения изменений в файле sysctl.conf следует выполнить systcl -p. Эта команда запускает системный вызов setsockopt (SO_RCVBUF).
Следует отметить, что буфер setsockopt(SO_RCVBUF), установленный в приложении, будет ограничен значениями, установленными в net.core.rmem_default и net.core.rmem_max и если приложение имеет буфер размером 1 мб, но net.core.rmem_max составляет всего 256 кб, то буфер сокета приложения будет ограничен этим значением.

Диагностика сети с помощью системных вызовов


Для любого сетевика WireShark абсолютно необходимый инструмент отладки, иногда главный. Не раз и не два только благодаря WireShark удавалось спасти проект в очень сложной ситуации. Но бывают случаи, когда только в системных вызовах ядра можно увидеть сетевую проблему.
В частности отброшенные пакеты нельзя будет увидеть в tcpdump, или WireShark. Зато можно их увидеть в режиме реального времени с помощью tcpdrop из сета bcc-tools. У команды нет никаких опций, просто выполните tcpdop. Вывод состоит из сокета, статусе соединения и флагах TCP. Далее идет трассировка стека ядра, которая привела к этому сбросу пакета.

(1:1013)$ /usr/share/bcc/tools/tcpdropTIME     PID    IP SADDR:SPORT  > DADDR:DPORT  STATE (FLAGS)16:31:07 3103   4  93.184.216.34:443       > 192.168.11.32:36222   ESTABLISHED (PSH|ACK)b'tcp_drop+0x1'b'tcp_data_queue+0x1e7'b'tcp_rcv_established+0x1df'b'tcp_v4_do_rcv+0x131'b'tcp_v4_rcv+0xad3'b'ip_protocol_deliver_rcu+0x2b'b'ip_local_deliver_finish+0x55'b'ip_local_deliver+0xe8'b'ip_rcv+0xcf'b'__netif_receive_skb_core+0x429'b'__netif_receive_skb_list_core+0x10a'b'netif_receive_skb_list_internal+0x1bf'b'netif_receive_skb_list+0x26'b'iwl_pcie_rx_handle+0x447'b'iwl_pcie_irq_handler+0x4d5'b'irq_thread_fn+0x20'b'irq_thread+0xdc'b'kthread+0x113'b'ret_from_fork+0x35'

В bcc-tools имеется еще одна очень полезная утилита tcplife, которая показывает параметры TCP соединение, в том числе, длительность сеанса. У этой команды есть некоторые опции.

(1:1014)$ /usr/share/bcc/tools/tcplife -h...examples:    ./tcplife           # trace all TCP connect()s    ./tcplife -T        # include time column (HH:MM:SS)    ./tcplife -w        # wider columns (fit IPv6)    ./tcplife -stT      # csv output, with times & timestamps    ./tcplife -p 181    # only trace PID 181    ./tcplife -L 80     # only trace local port 80    ./tcplife -L 80,81  # only trace local ports 80 and 81    ./tcplife -D 80     # only trace remote port 80

Просмотр сессий выглядит так.

# ./tcplife -D 80PID   COMM       LADDR           LPORT RADDR           RPORT TX_KB RX_KB MS27448 curl       100.66.11.247   54146 54.154.224.174  80        0     1 263.8527450 curl       100.66.11.247   20618 54.154.164.22   80        0     1 243.6227452 curl       100.66.11.247   11480 54.154.43.103   80        0     1 231.1627454 curl       100.66.11.247   31382 54.154.15.7     80        0     1 249.95

Может так случится, что между клиентом и сервером расположен межсетевой экран, либо IPS/IDS с набором правил по обрыву длительности TCP сессии по прошествии определенного времени, или достижении некоего объёма трафика. В этом случае диагностика подобного кейса может затянутся неопределенно долго, так как находится в слепой зоне, как со стороны клиентского, так и со стороны серверного приложения. Единственный способ понять в чему тут дело, это использовать инструменты bcc-tools.

Недооцененный резолвинг


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

getnameinfo(getaddrinfo(HOSTNAME)) = HOSTMANE

ункции getnameinfo и getaddrinfo являются заменой устаревших gethostbyname и gethostbyaddr соответственно.

int getnameinfo(const struct sockaddr *addr, socklen_t addrlen,    char *host, socklen_t hostlen,    char *serv, socklen_t servlen, int flags);int getaddrinfo(const char *node, const char *service,    const struct addrinfo *hints, struct addrinfo **res);

Положительный пример lib.ru

(1:1015)$ host lib.rulib.ru has address 81.176.66.163...(1:1016)$ host 81.176.66.163163.66.176.81.in-addr.arpa domain name pointer lib.ru.Отрицательный пример - example.com.(1:1017)$ host example.comexample.com has address 93.184.216.34(1:1018)$ host 93.184.216.34Host 34.216.184.93.in-addr.arpa. not found: 3(NXDOMAIN)


Если бы IP 93.184.216.34 указывал не на example.com, а на иной хост, то и это было бы ошибкой. Только тождество результат двустороннего разрешения имен гарантирует отсутствие ошибок настройки.
Вообще-то используя утилиту host следует помнить, что она так же, как dig и nslookup используют лишь DNS для разрешения имён хостов и игнорируют записи в файле /etc/hosts. По этой причине целесообразнее использовать команду getent.

(1:1019)$ strace -f -e trace=openat host my.router 2>&1 |grep -e "^openat" -e addressopenat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libuv.so.1", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libunistring.so.2", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/proc/self/task/7164/comm", O_RDWR) = 3(1:1020)$ strace -f -e trace=openat getent ahosts my.router openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/libunistring.so.2", O_RDONLY|O_CLOEXEC) = 3openat(AT_FDCWD, "/usr/lib64/charset.alias", O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such file or directory)192.168.10.10    STREAM my.router192.168.10.10    DGRAM  192.168.10.10    RAW    +++ exited with 0 +++


Из вывода видно, что host не обращается к файлу /etc/hosts и по этой причине не в состоянии определить IP адрес маршрутизатора. Напротив, getent ищет в этом файле и находит соответствующую запись.

Использованные материалы






Подробнее..

Wireguard для Kubernetes и удобные GUI

09.12.2020 16:05:25 | Автор: admin

Can I just once again state my love for [WireGuard] and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.

Linus Torvalds, on the Linux Kernel Mailing List

Уверен, что многие уже слышали про Wireguard. Некоторые даже щупали вживую. Мне он вполне понравился в продакшене как по производительности, так и по простоте настройки. Да, там нет миллиона загадочных конфигураций на все случаи жизни как у OpenVPN и XFRM+StrongSwan в IPSEC VPN. Он прост и лаконичен как в коде, так и в конфигах. Жирным и неповоротливым он станет еще нескоро. Короче, такой позитивный вариант сценария сжечь легаси и написать все как надо.

Я решил не писать очередной гайд как я поставил Wireguard, а поделиться некоторыми полезными утилитами. Некоторые с очень удачным, на мой вкус GUI, что уместно для сервисов со множеством пользователей. Разберем использование этого VPN для связи между нодами в разных кластерах Kubernetes, несколько web-GUI для генерации и пару полезных ресурсов.

Зачем он вообще нужен?


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


Источник: www.wireguard.com/performance

Причем стоит обратить внимание на то, что он был включен в состав ядра начиная с Linux 5.6, а с весны этого года он также включен в состав основной ветки ядра Android, что дает нам отличную энергоэффективность на мобильниках. Хотя, надо сказать, что он и до этого не особо напрягал батарею телефона.

Kilo wireguard для Kubernetes


Очень часто у компаний крупнее среднего возникают ситуации, когда необходимо использовать несколько разных облаков. Причины разные отказоустойчивость, хорошее присутствие в регионе и низкие пинги. Иногда цены на конкретные продукты. Например, вы можете крутить фронтенд и основную логику на собственных серверах, а GPU-hungry задачи выносить на AWS-инстансы.

Как это работает? Kilo требует наличия wireguard kernel-модуля на всех нодах. Если вы используете ядра новее 5.6, то модуль будет уже в основной ветке и допиливать ничего не придется. Далее, kilo agent, kg, запускается на каждой ноде кластера, настраивая приватные и публичные ключи для организации VPN. Также автоматически настраиваются правила маршрутизации трафика между отдельными регионами. Также kilo может работать совместно с другими сетевыми решениями для кластеров, например с Flannel. При этом kilo будет обеспечивать связь между регионами, а Flannel позаботится о трафике внутри одной локации.
При построении сетевой топологии он опирается на topology.kubernetes.io/region, но можно разметить регионы и вручную.

Требования:

  • Ядро новее 5.6 или отдельный модуль wireguard
  • Белые IP у нод, для организации прямого коннекта между ними.


Более подробная информация есть в прошлогоднем выступлении разработчиков на Kubernetes Forums в Сеуле и в документации.

wg-gen-web


image
Что называется, yet another config generator. Но очень приятный в работе. Основное отличие в подходе автор не пытается на лету править конфигурацию работающего сервиса, а лишь предоставляет удобный GUI для генерации правил. Дальше вы сами имплементируете обновление конфигов на свой вкус.

Ключевые фичи генерирует удобные QR-коды для мобильных клиентов и отправляет на почту клиенту все необходимые данные для подключения. Ну и докеризирован, само собой. Репозиторий тут.

Деплой довольно прост:

docker run --rm -it -v /tmp/wireguard:/data -p 8080:8080 -e "WG_CONF_DIR=/data" vx3r/wg-gen-web:latest

Subspace



Еще один GUI для удобной работы с множеством клиентских устройств.
Основные фичи:

  1. Single Sign-On с использованием SAML. Можно заходить под Google учеткой.
  2. Добавление и удаление устройств в несколько кликов
  3. Генерация индивидуальных конфигов для каждого устройства. Ну и QR-код, конечно.
  4. HTTPS от Let's Encrypt из коробки и автоматический редирект на 443 порт

Легко деплоится на VPS. У нас, кстати, они есть. Можем отсыпать)
На сервере должен быть установлен wireguard и открыты порты: 80/tcp, 443/tcp, 51820/udp (WireGuard). При этом надо удалить штатный dnsmasq, так как он будет запущен в контейнере.
Дальше все довольно типично, только --env SUBSPACE_HTTP_HOST заменить на свой домен:
# Your data directory should be bind-mounted as `/data` inside the container using the `--volume` flag.$ mkdir /datadocker create \    --name subspace \    --restart always \    --network host \    --cap-add NET_ADMIN \    --volume /usr/bin/wg:/usr/bin/wg \    --volume /data:/data \    --env SUBSPACE_HTTP_HOST=subspace.example.com \    subspacecloud/subspace:latest$ sudo docker start subspace

Репозиторий тут.

Вместо выводов


Если вы еще не пробовали этот VPN настоятельно рекомендую. Часто он способен оживить не очень мощное железо, которое не справлялось под нагрузкой ранее. А еще он не очень сложен в конфигурации. Правда, его основная задача все же пробивание прямых, заранее настроенных туннелей. Всякие динамические конфигурации ему недоступны в привычном понимании. Своеобразная плата за простоту и производительность.
Кстати, если вы еще не в курсе, то wireguard уже включен в бета-версию RouterOS 7.1 от MikroTik. Попробовать можно уже сейчас, но, по моим ощущениям, оно еще сыровато.


Ну и традиционно могу пригласить попробовать . Например, чтобы заворачивать часть трафика домашней сети в Швейцарию или Нидерланды. У нас много разных локаций и ценовая политика весьма приятная для подобных задач.

Как я уже говорил, Wireguard очень экономно потребляет ресурсы, поэтому более чем достаточно будет минимальной конфигурации с 1 ядром и 1 ГБ оперативной памяти для поддержки большого количества клиентов. Цены тоже получаются довольно гуманные:

  • 503 /мес.
  • 240 /мес.




Подробнее..

Сравнение ZeroTier и WireGuard, а так же других решений

26.01.2021 16:05:52 | Автор: admin


В предыдущих статьях, от RSagittarius, посвящённых ZeroTier было подробно рассмотрено практическое применение данного инструмента и его настройка. Настало время сравнить его с таким, набирающим популярность, решением как WireGuard, что бы понять в каких случаях лучше выбрать ZeroTier, а в каких WireGuard. Так же, на закуску, рассмотрим такую штуку как локалка RuVDS.

Wireguard относительно новый популярный VPN из коробки


Существует огромное множество VPN решений, наиболее известными, на сегодняшний день, являются IPSec, WireGuard и до недавнего времени наиболее популярный, OpenVPN. Так почему-же я решил сравнивать ZeroTier, который производителем не позиционируется как классическое VPN решение, именно с WireGuard? На то есть несколько причин:

  1. Простота настройки низкий порог входа.
  2. Мультиплатформенность наличие клиентов под все распространённые платформы, включая мобильные.
  3. Новизна продуктов и тот и другой стали на слуху сравнительно недавно.
  4. Было интересно сравнить то что идёт прямо в поставке ядра Linux, современных версий (WireGuard) с ZeroTier.

Итак, что-же такое WireGuard: Wireguard классическое, клиент-серверное, VPN решение. Опенсорсное, довольно простое, в настройке и производительное. Давайте пробежимся по пунктам из списка выше.

1. Простота настройки


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


и это только для двух хостов, а ведь ещё WG умеет в топологию звезда и в mesh. Разумеется, в продакшене, всё делается через создание конфигов в /etc/wireguard/interface_name.conf и добавление в автозапуск systemd wg-quick@interface_name.service. Или штатным конфигурированием интерфейса, если используется systemd-networkd. Там-же можно посмотреть как конфигурировать wireguard для других менеджеров сети, включая NetworkManager.

2. Мультиплатформенность


У WireGuard всё более чем хорошо с мультиплатформенностью. Вот что мы имеем на текущий момент:
  • Android
  • iOS
  • Linux
  • FreeBSD
  • MacOS
  • Mikrotik (RouterOS 7.1beta)
  • NetBSD
  • OpenBSD
  • OpenWRT
  • Windows

3. Новизна


WireGuard впервые вышел в свет в конце июня 2016-го и сразу в прод маленькой кучки VPN провайдеров:

> Earliest snapshots of the code base exist from June 30, 2016. Four early adopters of WireGuard were > the VPN service providers Mullvad, AzireVPN, IVPN and cryptostorm.

Wikipedia

ZeroTier виртуальный коммутатор с функцией VPN и файрволом


Скажу сразу и честно. Давно не испытывал такого удовольствия от соединения энного количества хостов в сеть. Простота и логичность работы и настройки ZeroTier просто подкупает. А с учётом того, что RuVDS предоставляет готовый шаблон, для поднятия собственного ZeroTier контроллера, так ещё и сокращает время развёртывания VPN сети. Ни в одном опенсорс проекте, до этого, я ещё не видел такой лёгкости добавления отдельных хостов и целых локальных сетей, в VPN сеть. Да именно сеть, ибо производитель позиционирует свой продукт как виртуальный коммутатор с функцией VPN. Теперь можно пройтись по тем-же пунктам что и в случае WireGuard.

1. Простота настройки


Не буду повторяться, ибо всё уже написано до нас. Отмечу лишь то, что добавление нового хоста это одна команда на клиенте вида zerotier-cli join 7ca3bd9b52f9d96b и и всё! (ну и плюс поставить галочку авторизации, в веб-интерфейсе контроллера, для свеже-добавленного хоста). Роутинг в локалки, например в локалки филиалов, тоже никаких проблем! Галочка в GUI и статик роуты на маршрутизаторах локалок. Вобщем, как минимум, я рекомендую попробовать!

2. Мультиплатформенность


ZT тоже балует обилием клиентов подо всё что движется, включая практически все популярные NAS и даже OpenWRT.

  • Android
  • Docker
  • iOS
  • Linux
  • FreeBSD
  • MacOS
  • OpenWRT
  • QNap
  • Synology
  • WD MyCloud NAS
  • Windows

3. Новизна


ZeroTier уже не мальчик. Всё-таки 10 лет развития, по айтишным меркам, это уже что-то. Но, тем не менее, продукт выглядит свежо, по крайней мере по концепциям. А главное, он работает ровно так, как задумано. Но это всё лирика. Как мне кажется пора переходить к самому главному к сравнению

Сравниваем наших героев


Здесь мы сведём воедино все практические аспекты обоих продуктов, плюс сравним производительность ну и определимся с тем, когда и для чего лучше использовать WireGuard, а когда ZeroTier. Итак:
  1. Простота настройки. Здесь вперёд, со значительным отрывом вырывается ZeroTier. Проще решения я не видел.
  2. Мультиплатформенность. Здесь паритет. Но у WireGuard появилась поддержка маршрутизаторов от Mikrotik, что может стать решающим фактором при выборе решения.
  3. Дополнительные возможности. Наличие встроенного в ZeroTier файрвола (да, там такое есть! Но, к сожалению рассмотрение этой фичи выходит за рамки данной статьи) позволяющего блокировать/разрешать трафик на уровне VPN сети.
  4. Самое интересное. Производительность.


  • Чем тестировали: iperf3 -P 5 -R
  • ОС, клиент и сервер: Ubuntu 20.04.
  • Железо RuVDS клиент + сервер:
    • CPU: 1 X Intel Xeon CPU E5-2680 v4 @ 2.40GHz
    • Mem 0.5Gb
    • ДЦ RuVDS в Королёве iperf3 сервер
    • ДЦ RuVDS в Казани iperf3 клиент



WireGuard, результаты
root@ruvds-9qxnx:~# iperf3 -c 10.0.0.2 -P 5 -R Connecting to host 10.0.0.2, port 5201Reverse mode, remote host 10.0.0.2 is sending[  5] local 10.0.0.1 port 44108 connected to 10.0.0.2 port 5201[  7] local 10.0.0.1 port 44110 connected to 10.0.0.2 port 5201[  9] local 10.0.0.1 port 44112 connected to 10.0.0.2 port 5201[ 11] local 10.0.0.1 port 44114 connected to 10.0.0.2 port 5201[ 13] local 10.0.0.1 port 44116 connected to 10.0.0.2 port 5201[ ID] Interval           Transfer     Bitrate[  5]   0.00-1.00   sec  2.20 MBytes  18.4 Mbits/sec                  [  7]   0.00-1.00   sec  2.12 MBytes  17.8 Mbits/sec                  [  9]   0.00-1.00   sec  1.23 MBytes  10.3 Mbits/sec                  [ 11]   0.00-1.00   sec  1.90 MBytes  15.9 Mbits/sec                  [ 13]   0.00-1.00   sec  1.86 MBytes  15.6 Mbits/sec                  [SUM]   0.00-1.00   sec  9.30 MBytes  78.0 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   1.00-2.00   sec  2.22 MBytes  18.6 Mbits/sec                  [  7]   1.00-2.00   sec  2.24 MBytes  18.8 Mbits/sec                  [  9]   1.00-2.00   sec  1.07 MBytes  9.01 Mbits/sec                  [ 11]   1.00-2.00   sec  2.17 MBytes  18.2 Mbits/sec                  [ 13]   1.00-2.00   sec  2.30 MBytes  19.3 Mbits/sec                  [SUM]   1.00-2.00   sec  10.0 MBytes  84.0 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   2.00-3.00   sec  2.07 MBytes  17.4 Mbits/sec                  [  7]   2.00-3.00   sec  2.83 MBytes  23.7 Mbits/sec                  [  9]   2.00-3.00   sec  1.08 MBytes  9.08 Mbits/sec                  [ 11]   2.00-3.00   sec  2.21 MBytes  18.6 Mbits/sec                  [ 13]   2.00-3.00   sec  2.45 MBytes  20.6 Mbits/sec                  [SUM]   2.00-3.00   sec  10.7 MBytes  89.4 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   3.00-4.00   sec  2.06 MBytes  17.3 Mbits/sec                  [  7]   3.00-4.00   sec  2.87 MBytes  24.1 Mbits/sec                  [  9]   3.00-4.00   sec   890 KBytes  7.29 Mbits/sec                  [ 11]   3.00-4.00   sec  2.10 MBytes  17.6 Mbits/sec                  [ 13]   3.00-4.00   sec  2.12 MBytes  17.8 Mbits/sec                  [SUM]   3.00-4.00   sec  10.0 MBytes  84.1 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   4.00-5.00   sec  2.27 MBytes  19.0 Mbits/sec                  [  7]   4.00-5.00   sec  2.57 MBytes  21.5 Mbits/sec                  [  9]   4.00-5.00   sec   967 KBytes  7.92 Mbits/sec                  [ 11]   4.00-5.00   sec  2.07 MBytes  17.4 Mbits/sec                  [ 13]   4.00-5.00   sec  2.31 MBytes  19.4 Mbits/sec                  [SUM]   4.00-5.00   sec  10.2 MBytes  85.2 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   5.00-6.00   sec  2.20 MBytes  18.4 Mbits/sec                  [  7]   5.00-6.00   sec  2.78 MBytes  23.3 Mbits/sec                  [  9]   5.00-6.00   sec   927 KBytes  7.60 Mbits/sec                  [ 11]   5.00-6.00   sec  2.11 MBytes  17.7 Mbits/sec                  [ 13]   5.00-6.00   sec  2.72 MBytes  22.8 Mbits/sec                  [SUM]   5.00-6.00   sec  10.7 MBytes  89.9 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   6.00-7.00   sec  1.97 MBytes  16.5 Mbits/sec                  [  7]   6.00-7.00   sec  2.66 MBytes  22.3 Mbits/sec                  [  9]   6.00-7.00   sec   840 KBytes  6.88 Mbits/sec                  [ 11]   6.00-7.00   sec  2.22 MBytes  18.6 Mbits/sec                  [ 13]   6.00-7.00   sec  2.65 MBytes  22.3 Mbits/sec                  [SUM]   6.00-7.00   sec  10.3 MBytes  86.6 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   7.00-8.00   sec  1.96 MBytes  16.4 Mbits/sec                  [  7]   7.00-8.00   sec  2.98 MBytes  25.0 Mbits/sec                  [  9]   7.00-8.00   sec   798 KBytes  6.53 Mbits/sec[ 11]   7.00-8.00   sec  1.89 MBytes  15.8 Mbits/sec                  [ 13]   7.00-8.00   sec  2.55 MBytes  21.4 Mbits/sec                  [SUM]   7.00-8.00   sec  10.2 MBytes  85.2 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   8.00-9.00   sec  2.00 MBytes  16.8 Mbits/sec                  [  7]   8.00-9.00   sec  3.05 MBytes  25.6 Mbits/sec                  [  9]   8.00-9.00   sec   826 KBytes  6.76 Mbits/sec                  [ 11]   8.00-9.00   sec  2.03 MBytes  17.1 Mbits/sec                  [ 13]   8.00-9.00   sec  2.58 MBytes  21.6 Mbits/sec                  [SUM]   8.00-9.00   sec  10.5 MBytes  87.7 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   9.00-10.00  sec  1.95 MBytes  16.4 Mbits/sec                  [  7]   9.00-10.00  sec  3.16 MBytes  26.5 Mbits/sec                  [  9]   9.00-10.00  sec   827 KBytes  6.77 Mbits/sec                  [ 11]   9.00-10.00  sec  2.04 MBytes  17.1 Mbits/sec                  [ 13]   9.00-10.00  sec  2.52 MBytes  21.1 Mbits/sec                  [SUM]   9.00-10.00  sec  10.5 MBytes  87.9 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[ ID] Interval           Transfer     Bitrate         Retr[  5]   0.00-10.06  sec  22.1 MBytes  18.4 Mbits/sec    0             sender[  5]   0.00-10.00  sec  20.9 MBytes  17.5 Mbits/sec                  receiver[  7]   0.00-10.06  sec  29.2 MBytes  24.3 Mbits/sec    0             sender[  7]   0.00-10.00  sec  27.3 MBytes  22.9 Mbits/sec                  receiver[  9]   0.00-10.06  sec  10.3 MBytes  8.58 Mbits/sec    0             sender[  9]   0.00-10.00  sec  9.31 MBytes  7.81 Mbits/sec                  receiver[ 11]   0.00-10.06  sec  21.9 MBytes  18.2 Mbits/sec    0             sender[ 11]   0.00-10.00  sec  20.7 MBytes  17.4 Mbits/sec                  receiver[ 13]   0.00-10.06  sec  25.8 MBytes  21.5 Mbits/sec    1             sender[ 13]   0.00-10.00  sec  24.1 MBytes  20.2 Mbits/sec                  receiver[SUM]   0.00-10.06  sec   109 MBytes  91.0 Mbits/sec    1             sender[SUM]   0.00-10.00  sec   102 MBytes  85.8 Mbits/sec                  receiveriperf Done.



ZeroTier, результаты
root@ruvds-9qxnx:~# iperf3 -c 172.28.1.64 -P 5 -R Connecting to host 172.28.1.64, port 5201Reverse mode, remote host 172.28.1.64 is sending[  5] local 172.28.1.91 port 34468 connected to 172.28.1.64 port 5201[  7] local 172.28.1.91 port 34470 connected to 172.28.1.64 port 5201[  9] local 172.28.1.91 port 34472 connected to 172.28.1.64 port 5201[ 11] local 172.28.1.91 port 34474 connected to 172.28.1.64 port 5201[ 13] local 172.28.1.91 port 34476 connected to 172.28.1.64 port 5201[ ID] Interval           Transfer     Bitrate[  5]   0.00-1.00   sec  1.08 MBytes  9.07 Mbits/sec                  [  7]   0.00-1.00   sec   988 KBytes  8.08 Mbits/sec                  [  9]   0.00-1.00   sec   768 KBytes  6.28 Mbits/sec                  [ 11]   0.00-1.00   sec   615 KBytes  5.03 Mbits/sec                  [ 13]   0.00-1.00   sec  1.03 MBytes  8.65 Mbits/sec                  [SUM]   0.00-1.00   sec  4.43 MBytes  37.1 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   1.00-2.00   sec  1.28 MBytes  10.8 Mbits/sec                  [  7]   1.00-2.00   sec  1006 KBytes  8.25 Mbits/sec                  [  9]   1.00-2.00   sec   808 KBytes  6.63 Mbits/sec                  [ 11]   1.00-2.00   sec   660 KBytes  5.41 Mbits/sec                  [ 13]   1.00-2.00   sec  1.26 MBytes  10.6 Mbits/sec                  [SUM]   1.00-2.00   sec  4.96 MBytes  41.6 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   2.00-3.00   sec  1.14 MBytes  9.55 Mbits/sec                  [  7]   2.00-3.00   sec  1.04 MBytes  8.72 Mbits/sec                  [  9]   2.00-3.00   sec   872 KBytes  7.14 Mbits/sec                  [ 11]   2.00-3.00   sec   437 KBytes  3.58 Mbits/sec                  [ 13]   2.00-3.00   sec  1.12 MBytes  9.40 Mbits/sec                  [SUM]   2.00-3.00   sec  4.58 MBytes  38.4 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   3.00-4.00   sec   625 KBytes  5.13 Mbits/sec                  [  7]   3.00-4.00   sec   845 KBytes  6.93 Mbits/sec                  [  9]   3.00-4.00   sec   953 KBytes  7.81 Mbits/sec                  [ 11]   3.00-4.00   sec   400 KBytes  3.28 Mbits/sec                  [ 13]   3.00-4.00   sec   832 KBytes  6.82 Mbits/sec                  [SUM]   3.00-4.00   sec  3.57 MBytes  30.0 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   4.00-5.00   sec   620 KBytes  5.08 Mbits/sec                  [  7]   4.00-5.00   sec   606 KBytes  4.97 Mbits/sec                  [  9]   4.00-5.00   sec  1.12 MBytes  9.37 Mbits/sec                  [ 11]   4.00-5.00   sec   633 KBytes  5.19 Mbits/sec                  [ 13]   4.00-5.00   sec  1.00 MBytes  8.42 Mbits/sec                  [SUM]   4.00-5.00   sec  3.94 MBytes  33.0 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   5.00-6.00   sec   802 KBytes  6.57 Mbits/sec                  [  7]   5.00-6.00   sec   690 KBytes  5.65 Mbits/sec                  [  9]   5.00-6.00   sec  1.53 MBytes  12.8 Mbits/sec                  [ 11]   5.00-6.00   sec   920 KBytes  7.54 Mbits/sec                  [ 13]   5.00-6.00   sec   955 KBytes  7.82 Mbits/sec                  [SUM]   5.00-6.00   sec  4.82 MBytes  40.4 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   6.00-7.00   sec   309 KBytes  2.53 Mbits/sec                  [  7]   6.00-7.00   sec   228 KBytes  1.87 Mbits/sec                  [  9]   6.00-7.00   sec   464 KBytes  3.80 Mbits/sec                  [ 11]   6.00-7.00   sec   322 KBytes  2.64 Mbits/sec                  [ 13]   6.00-7.00   sec   311 KBytes  2.55 Mbits/sec                  [SUM]   6.00-7.00   sec  1.60 MBytes  13.4 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   7.00-8.00   sec   577 KBytes  4.73 Mbits/sec                  [  7]   7.00-8.00   sec   580 KBytes  4.75 Mbits/sec[  9]   7.00-8.00   sec  1.30 MBytes  10.9 Mbits/sec                  [ 11]   7.00-8.00   sec   792 KBytes  6.49 Mbits/sec                  [ 13]   7.00-8.00   sec   655 KBytes  5.36 Mbits/sec                  [SUM]   7.00-8.00   sec  3.84 MBytes  32.2 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   8.00-9.00   sec   781 KBytes  6.40 Mbits/sec                  [  7]   8.00-9.00   sec   561 KBytes  4.59 Mbits/sec                  [  9]   8.00-9.00   sec  1.29 MBytes  10.8 Mbits/sec                  [ 11]   8.00-9.00   sec  1.18 MBytes  9.87 Mbits/sec                  [ 13]   8.00-9.00   sec   631 KBytes  5.17 Mbits/sec                  [SUM]   8.00-9.00   sec  4.39 MBytes  36.8 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   9.00-10.00  sec   961 KBytes  7.87 Mbits/sec                  [  7]   9.00-10.00  sec   762 KBytes  6.24 Mbits/sec                  [  9]   9.00-10.00  sec  1.44 MBytes  12.0 Mbits/sec                  [ 11]   9.00-10.00  sec  1.15 MBytes  9.67 Mbits/sec                  [ 13]   9.00-10.00  sec   717 KBytes  5.87 Mbits/sec                  [SUM]   9.00-10.00  sec  4.97 MBytes  41.7 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[ ID] Interval           Transfer     Bitrate         Retr[  5]   0.00-10.99  sec  8.33 MBytes  6.36 Mbits/sec   33             sender[  5]   0.00-10.00  sec  8.07 MBytes  6.77 Mbits/sec                  receiver[  7]   0.00-10.99  sec  7.32 MBytes  5.58 Mbits/sec   64             sender[  7]   0.00-10.00  sec  7.16 MBytes  6.01 Mbits/sec                  receiver[  9]   0.00-10.99  sec  10.7 MBytes  8.20 Mbits/sec   61             sender[  9]   0.00-10.00  sec  10.4 MBytes  8.76 Mbits/sec                  receiver[ 11]   0.00-10.99  sec  7.25 MBytes  5.53 Mbits/sec   70             sender[ 11]   0.00-10.00  sec  7.00 MBytes  5.87 Mbits/sec                  receiver[ 13]   0.00-10.99  sec  8.61 MBytes  6.57 Mbits/sec   55             sender[ 13]   0.00-10.00  sec  8.42 MBytes  7.07 Mbits/sec                  receiver[SUM]   0.00-10.99  sec  42.3 MBytes  32.2 Mbits/sec  283             sender[SUM]   0.00-10.00  sec  41.1 MBytes  34.5 Mbits/sec                  receiver



Выводы


К сожалению ZeroTier, предсказуемо, проиграл по производительности. По крайней мере для систем на ядре Linux. Но, по моему скромному мнению, ZeroTier победил в простоте и удобстве администрирования. Отсюда вывод. Если вам нужна высокая производительность между серверами и рабочими станциями на линукс, выбирайте WireGuard. Если-же у вас клиенты, по большей части на MacOS, Windows, и мобильных платформах, то я-бы выбрал ZeroTier. Особенно если нужно добавлять / удалять новых клиентов, в большом количестве, раздавать права доступа и так далее. Ну и, для клиентов RuVDS, может стать решающим фактором быстрота и удобство развёртывания собственного контроллера, в один клик. Так-же, для упрощения выбора, приведу сводную таблицу совместимых платформ:



А теперь небольшой сюрприз


На самом деле, для случая соединения между собой серверов размещённых у RuVDS, есть ещё один вариант. Вариант указанный в заголовке статьи. И этот вариант, по производительности, уделывает даже WireGuard, но, при этом, по простоте настройки сравним с ZeroTier. Это Локальная сеть . Под спойлером где искать и как всё это настроить:

Краткий манул, в картинках
В панели управления серверами у любого сервера который хотим добавить в локалку идём на вкладку сеть(1) и смело жмём на капу настроить локальные сети(2).



Далее создаём новую локалку.



Задаём имя локальной сети(1). Выделяем подсеть в любом из частных диапазонов (10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12 etc), с маской в CIDR нотации(2). Опционально придумываем описание(3). Выбираем сервер который хотим подключить(4), подключаем(5), при необходимости повторяем шаги 4 и 5. Жмём зелёную капу(6).



Выглядит локалка как-то так Проверяем, жмём Deploy.



Мы подключены к сети(2), но пока в оффлайне(1). Ждём пару минут.



После чего жмём обновить список(1) и убеждаемся что сеть перешла в состояние online(2).



После того как сеть поднялась, заходим на виртуалки и проверяем связность. Локалка видна как обычный сетевой интерфейс, с адресом из той подсети которую мы задали(1). Соседний сервер на другом конце страны, прекрасно пингуется(2).




Самое интересное производительность (сервера те-же что и в тестах WireGuard и ZeroTier):

$ iperf3 -c 192.168.0.3 -P 5 -R Connecting to host 192.168.0.3, port 5201Reverse mode, remote host 192.168.0.3 is sending[  5] local 192.168.0.4 port 35816 connected to 192.168.0.3 port 5201[  7] local 192.168.0.4 port 35818 connected to 192.168.0.3 port 5201[  9] local 192.168.0.4 port 35820 connected to 192.168.0.3 port 5201[ 11] local 192.168.0.4 port 35822 connected to 192.168.0.3 port 5201[ 13] local 192.168.0.4 port 35824 connected to 192.168.0.3 port 5201[ ID] Interval           Transfer     Bitrate[  5]   0.00-1.00   sec  14.8 MBytes   124 Mbits/sec                  [  7]   0.00-1.00   sec  14.9 MBytes   125 Mbits/sec                  [  9]   0.00-1.00   sec  14.7 MBytes   123 Mbits/sec                  [ 11]   0.00-1.00   sec  14.7 MBytes   123 Mbits/sec                  [ 13]   0.00-1.00   sec  14.6 MBytes   122 Mbits/sec                  [SUM]   0.00-1.00   sec  73.7 MBytes   617 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   1.00-2.00   sec  20.9 MBytes   176 Mbits/sec                  [  7]   1.00-2.00   sec  20.7 MBytes   174 Mbits/sec                  [  9]   1.00-2.00   sec  20.7 MBytes   174 Mbits/sec                  [ 11]   1.00-2.00   sec  20.6 MBytes   173 Mbits/sec                  [ 13]   1.00-2.00   sec  20.4 MBytes   171 Mbits/sec                  [SUM]   1.00-2.00   sec   103 MBytes   868 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   2.00-3.00   sec  18.3 MBytes   153 Mbits/sec                  [  7]   2.00-3.00   sec  18.5 MBytes   155 Mbits/sec                  [  9]   2.00-3.00   sec  18.6 MBytes   155 Mbits/sec                  [ 11]   2.00-3.00   sec  18.2 MBytes   153 Mbits/sec                  [ 13]   2.00-3.00   sec  18.5 MBytes   155 Mbits/sec                  [SUM]   2.00-3.00   sec  92.0 MBytes   771 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   3.00-4.00   sec  18.3 MBytes   154 Mbits/sec                  [  7]   3.00-4.00   sec  18.4 MBytes   155 Mbits/sec                  [  9]   3.00-4.00   sec  18.2 MBytes   153 Mbits/sec                  [ 11]   3.00-4.00   sec  18.4 MBytes   155 Mbits/sec                  [ 13]   3.00-4.00   sec  18.1 MBytes   152 Mbits/sec                  [SUM]   3.00-4.00   sec  91.4 MBytes   768 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   4.00-5.00   sec  17.0 MBytes   142 Mbits/sec                  [  7]   4.00-5.00   sec  17.2 MBytes   144 Mbits/sec                  [  9]   4.00-5.00   sec  17.0 MBytes   142 Mbits/sec                  [ 11]   4.00-5.00   sec  17.4 MBytes   146 Mbits/sec                  [ 13]   4.00-5.00   sec  16.7 MBytes   140 Mbits/sec                  [SUM]   4.00-5.00   sec  85.3 MBytes   713 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   5.00-6.00   sec  16.5 MBytes   139 Mbits/sec                  [  7]   5.00-6.00   sec  16.7 MBytes   141 Mbits/sec                  [  9]   5.00-6.00   sec  16.7 MBytes   140 Mbits/sec                  [ 11]   5.00-6.00   sec  16.4 MBytes   138 Mbits/sec                  [ 13]   5.00-6.00   sec  16.1 MBytes   136 Mbits/sec                  [SUM]   5.00-6.00   sec  82.4 MBytes   694 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   6.00-7.00   sec  17.7 MBytes   148 Mbits/sec                  [  7]   6.00-7.00   sec  17.8 MBytes   149 Mbits/sec                  [  9]   6.00-7.00   sec  17.6 MBytes   148 Mbits/sec                  [ 11]   6.00-7.00   sec  17.5 MBytes   146 Mbits/sec                  [ 13]   6.00-7.00   sec  17.3 MBytes   145 Mbits/sec                  [SUM]   6.00-7.00   sec  87.9 MBytes   736 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   7.00-8.00   sec  17.7 MBytes   148 Mbits/sec                  [  7]   7.00-8.00   sec  17.9 MBytes   149 Mbits/sec                  [  9]   7.00-8.00   sec  17.6 MBytes   148 Mbits/sec                  [ 11]   7.00-8.00   sec  17.7 MBytes   148 Mbits/sec                  [ 13]   7.00-8.00   sec  17.5 MBytes   147 Mbits/sec                  [SUM]   7.00-8.00   sec  88.5 MBytes   741 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   8.00-9.00   sec  18.7 MBytes   157 Mbits/sec                  [  7]   8.00-9.00   sec  18.8 MBytes   158 Mbits/sec                  [  9]   8.00-9.00   sec  18.9 MBytes   159 Mbits/sec                  [ 11]   8.00-9.00   sec  18.7 MBytes   157 Mbits/sec                  [ 13]   8.00-9.00   sec  18.5 MBytes   155 Mbits/sec                  [SUM]   8.00-9.00   sec  93.6 MBytes   787 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[  5]   9.00-10.00  sec  19.2 MBytes   161 Mbits/sec                  [  7]   9.00-10.00  sec  19.1 MBytes   160 Mbits/sec                  [  9]   9.00-10.00  sec  19.0 MBytes   160 Mbits/sec                  [ 11]   9.00-10.00  sec  19.0 MBytes   160 Mbits/sec                  [ 13]   9.00-10.00  sec  18.8 MBytes   158 Mbits/sec                  [SUM]   9.00-10.00  sec  95.1 MBytes   799 Mbits/sec                  - - - - - - - - - - - - - - - - - - - - - - - - -[ ID] Interval           Transfer     Bitrate         Retr[  5]   0.00-10.05  sec   181 MBytes   151 Mbits/sec  150             sender[  5]   0.00-10.00  sec   179 MBytes   150 Mbits/sec                  receiver[  7]   0.00-10.05  sec   182 MBytes   152 Mbits/sec  144             sender[  7]   0.00-10.00  sec   180 MBytes   151 Mbits/sec                  receiver[  9]   0.00-10.05  sec   181 MBytes   151 Mbits/sec  166             sender[  9]   0.00-10.00  sec   179 MBytes   150 Mbits/sec                  receiver[ 11]   0.00-10.05  sec   181 MBytes   151 Mbits/sec  253             sender[ 11]   0.00-10.00  sec   179 MBytes   150 Mbits/sec                  receiver[ 13]   0.00-10.05  sec   179 MBytes   149 Mbits/sec  168             sender[ 13]   0.00-10.00  sec   176 MBytes   148 Mbits/sec                  receiver[SUM]   0.00-10.05  sec   904 MBytes   755 Mbits/sec  881             sender[SUM]   0.00-10.00  sec   893 MBytes   749 Mbits/sec                  receiver

Очевидные вопросы


1. Что у этого решения под капотом?
VLAN/IPsec, при этом **не используются** ресурсы виртуалки.
2. Где использовать?
Для соединения серверов в рамках RuVDS.
3. Простота настройки?
Сравнима с настройкой ZeroTier.

Окончательные выводы по областям применения


  • Wireguard Соединение линукс хостов между собой, включая клиентские машины и если нужно объединить в VPN хосты у других хостеров. Высокая скорость передачи данных.
  • ZeroTier Мультиплатформенное решение, в основном для объединения клиентских устройств и подсетей, с удобным менеджментом. Средняя скорость передачи данных.
  • Локальная сеть RuVDS объединение в единую, высокопроизводительную, защищённую сеть Linux и Windows хостов, в рамках датацентров хостера. Очень высокая скорость передачи данных.


Подробнее..

Даешь свободную литературу! Или как я с политикой вуза боролся

25.04.2021 12:10:20 | Автор: admin

Доброго времени суток, хабровчане! Это мой первый пост на форуме, так что прошу строго не судить.

Коротко обо мне: студент, увлекаюсь электроникой, микроконтроллерами, и программированием. Однако, моя специальность ни коим образом не связана с It. Со мной покончено, переходим к сути.

Как и полагается любому техническому вузу в нашем есть куча интернет ресурсов, которыми вуз чрезмерно гордится. Однако есть оборотная сторона медали качество этих сервисов. А именно, если говорить про электронную библиотеку, о коей и пойдет речь в данной статье, то в ней напрочь отсутствует возможность скачивания pdf-версии нужной тебе методички, точнее она есть, но за это придется заплатить немало денЯк. Деньги далеко не маленькие (если говорить именно про цену за вузовские методички). Если же такой формат не устраивает, то можешь пользоваться онлайн библиотекой.

В онлайн библиотеке есть просмотрщик книг, через который можно читать литературу.

Просмотрщик оформлен максимально неудобно: долгое время не работал переход на определенную страницу книги, и книгу в 700 страниц приходилось перелистывать по страничке, что превращалось в адскую муку. Но самое ужасное в этом сайте то, что каждые 20 минут он просит авторизоваться по новой

И теперь представьте картину: человек пытается подготовиться к контрольной по квантовой механике по методичкам преподавателя, объемом 700 страниц, где необходимый материал находится на 500, и может перелистывать по 5 страничек в минуту, и каждые 20 минут, его попытки приходится возобновлять. В общем, жесть. И вот после очередной неудачной попытки прочитать нужную главу, я решил, что пришло время положить конец данному произволу.

Первым делом, средствами браузера, была получена ссылка на необходимый ресурс с изображением страницы. Ссылка выглядела примерно следующим образом:

http://www.<название сайта>/plugins/<название просмоторщика>/getDoc.php?Id=<id книги>&page=<номер страницы>

После получения данной ссылки скачивание книги не составляет и труда:

  1. Необходимо получить id книги (или лучше ссылку на нее)

  2. Узнать количество страниц

  3. В самом простом цикле for пробежаться по всем страницам, загрузив их на компьютер

  4. Объединить фотографии в единый файл pdf

  5. Радоваться

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

Самая первая версия программы выглядела максимально убого: я использовал java и библиотеку selenium для работы с сетью. Приложение получилось явно не user-friendly: запускалась только из IDEA, в которой ручками необходимо было вставлять ссылку на каждую книгу, также ручками забивать количество страниц. Более того, самым убожеством был тот факт, что приложение полностью имитировало пользователя:

  • Открывался сайт в браузере

  • Далее проводился поиск полей для логина и пароля и их заполнение

  • Затем переход по ссылке с первой страницей книги

  • И сочетание клавиш CTRL+S, нажатие на Enter.

В общем фу! Нельзя так делать!

Но когда у тебя на носу контрольная по квантмеху, и так сойдет. Программа была написана минут за 20, и книжки она выкачивала долго, и иногда не все страницы, хуже того, после скачивания, опять же ручками приходилось объединять картинки в единый файл pdf.

Но, не спешите бросаться помидорами, данный кошмар в дальнейшем был преобразован в весьма неплохой код. Я перешел на Delphi! Да, многие могут сказать, что язык устарел, и не обладает должным функционалам, однако в своей работе я его применяю постоянно. Обучился сему творению благодаря Михаилу Фленову (низкий поклон вам, Миша).

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

Рисунок 1 - Главная форма приложенияРисунок 1 - Главная форма приложения

Итак, суть осталось точно такой же, да и шаги не поменялись. Программулиной Wire Shark узнал, какая последовательность отправляется в POST запросе при авторизации. И меня сильно напугал один факт: пароль был зашифрованным.

Небольшое отклонение: логин на сайте представляет собой некоторый набор цифр, а пароль имя, написанной на русском языке. Однако, в программе WireShark на сайт отправлялся шестнадцатеричный код следующего формата: %D0% FF %D0% FF %D1% FF. Как позже выяснилось, символы FF кодировали буквы имени, а %D0% и %D1%, что то вроде контрольных байт. З.. Огромная просьба к знатокам, читающим эту статью, если это какой либо общеизвестный сетевой протокол, то не кидайтесь помидорами, а дайте, пожалуйста, ссылку, где можно прочитать про него. Но т.к. я не сталкивался с таким раньше, пришлось разбираться во всем самому.

Первым делом я обратил внимание на повторяющиеся символы %D1% и %D0%, которые, как я сразу и предположил, являются контрольными байтами, однако, оставалась загадкой, чем отличается %D0% от %D1%. Но это пока отложим, едем дальше. Как же шифруется пароль? А он шифруется достаточно просто, предположим, меня зовут Василий, давайте запишем мое имя в ACII символах:

82 (В) A0 (а) E1 (с) A8 (и) AB (л) A8 (и) A9 (й)

А на сайт отправляется следующая последовательность:

72 (В) 90 (а) 61 (с) 98 (и) 9B (л) 98 (и) 99 (й)

Хм, просматривается одна зависимость. А, точно! Если внимательно приглядеться, то у каждого символа, отправляемого на сайт, старший байт уменьшается на 1. Бум! Загадка разгадана.

Хотя, стоп, а почему же тогда вместо D1 (буква с), на сайт отправляется 61? А черт ее знает! Просто запомним, что для символов, лежащих в диапазоне от E0 до EF из старшего байта необходимо вычитать не 1, а 6. Собственно и все! А помните, я говорил про контрольный символ %D1%? Так вот, этот символ как раз таки ставится перед символами из данного диапазона. Ну, собственно и все. Далее привожу кусок кода, отвечающий за шифровку.

Код ""
 for i := 1 to length(password) do begin    temp := Ord(password[i]);    //Представили пароль в HEX виде    if (temp < 1088) or (temp > 1103) then // Значения символов E0 и EF        begin                 //Если вне этого диапазона, то %D0%pasBytes[i] := '%D0%' + IntToHex(((temp) - 896), 2); // + 128 - 1024 для шифрования   newPassword := newPassword + pasBytes[i];         end    elsebegin   //Иначе %D1%pasBytes[i] := '%D1%' + IntToHex(((temp) - 960), 2); // +64 -1024 для шифрования                   newPassword := newPassword + pasBytes[i];end; end;//1024 здесь вычитается потому, что в Delphi почему то ASCII символы начинаются с #400//Почему - не ясно 

Финальная последовательность, отправляемая на сайт, будет выглядеть следующим образом:

%D0% 72 %D0% 90 %D1% 61 %D0% 98 %D0% 9B %D0% 98 %D0% 99

Собственно это и была самая сложная часть работы.

Далее, после авторизации, пользователь вставляет в строку ввода ссылку на необходимую книгу. Программа же в это время отправляет Get запрос на сервер, из ответа которого, затем в автоматическом режиме находит название книги, ее ID, и количество страниц. Все эти данные сохраняются в глобальные переменные. И, затем, после нажатия кнопки Download, в отдельном потоке отправляются Get запросы на сервер, из которых и забираются картинки с изображениями страниц. Которые в дальнейшем, с помощью библиотеки Synapse формируются в единый PDF файл.

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

В общем, то и все. Если кому надо, могу выложить исходники на Github и выложить в комментариях ссылку. Также хотелось услышать ваше мнение по поводу моей дешифровки. Всем спасибо, до скорых встреч на просторах интернета.

Подробнее..

Быстрая сеть в домашней лаборатории или как я связался с InfiniBand

25.11.2020 20:07:40 | Автор: admin

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

tl;dr Если кому интересно, то сейчас такая ситуация, что пару десктопов можно связать 56Gb сеткой за <$100+доставка из штатов. Если хочется больше компьютеров, то это <$100 за 12 портовый свитч 40Gb и ~$60 за десктоп, плюс доставка. Но это всё б/у и ноль гарантий.

Заранее извиняюсь, но аббревиатур будет много. И это не реклама - всему этому оборудованию уже лет как много, оно уже не поддерживается производителем и легко ищется б/у на eBay за очень недорого, по сравнению с ценами на новое от производителя. Но должен сказать, что новое (анонсировано в конце 2020) - уже почти на порядок быстрее. Так что это всё про домашние эксперименты и самообучение.

Медный век

Когда появился в домашней лаборатории второй компьютер, а это год 2013, то в какой-то момент стало понятно, что скорости Ethernet в 1Gb - маловато будет, а хочется экспериментов. Стал выяснять, что же есть в природе на тот момент. 10GbE было ужасно дорого, и нашлись карточки производства Mellanox. Кроме Ethernet, они умеют и InfiniBand (это важно в дальнейшем). Можно почитать на Wiki, чем они отличается, но кроме всего прочего - IB умеет и IP over IB, а это ровно то, что нужно для нормальной жизни. Большим плюсом было то, что б/у адаптеры на eBay продавали чуть-ли не за копейки ($20-30). Поэтому было куплено сразу три (одна про запас) Mellanox-овские карточки MHEH28-XTC, которые умеют и InfiniBand SDR и Ethernet 10GbE, но имели странный разъем CX4. Также за пиво были найдены 3 кабеля (длиной всего 0.5м, но для лабы - самое то).

Дальше пошли всякие эксперименты, скорость передачи файлов по сети 600-700MB/s была получена. На RAM диске конечно, мои SSD в то время больше 250-300MB/s не умели.

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

Как известно, аппетит растет во время еды, поэтому апгрейд. Нашлись MHGH28-XTC, которые уже умеют InfiniBand DDR, а это уже 16Gbps. Выяснилось, что не все кабели одинаково полезны, скорость не выросла, пришлось искать новые. Нашлись медные, но аж 8 метров длины, и ощутимо тяжелые, это вам не Cat 5/6. С ними измерения показали до 1600MB/s, и до более тонкого тюнинга руки не дошли. Диски и рейды, что были - всё равно медленнее.

Следующий апгрейд, самый бестолковый, MHJH29-XTC, умеют аж QDR - 32Gbps. Только выяснилось, что Firmware для этих новинок - есть только очень старая. Такая, что под Win ничего работать даже не собирается. Хорошо хоть, что Linux выручил. Но ничего не работает на скорости QDR на старых кабелях, а кабели для скорости QDR найти - нереально.

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

Оптический век

С первых опытов уже прошло пять лет, и год стал 2018. Насколько я понимаю ситуацию, и почему так произошло - штатовские дата центры начали (и закончили) апгрейды своих сетей, и на eBay появилась куча новых интересных б/у железок за гуманную цены. А именно карточки ConnectX-3, свитчи, и оптические кабели. Это уже не предания старины глубокой, а относительно новое железо.

SIDENOTE: как я понимаю, это из-за перехода с 10/40GbE на 25/50/100+GbE. И у них есть вопросы совместимости, поэтому старое просто утилизировали.

Что тут можно рассказать, сначала были куплены карточки и кабели. Причем они уже были настолько распространены, что искать не обязательно Mellanox'ы, есть тоже самое под именами HP/Dell/IBM, и они дешевле. Драйвера встроенные есть и в Win, и в Linux, работает всё почти само. Это всё железо умеет QDR/FDR10/FDR14, то есть по сути 40/56Gbps. Реальную скорость при правильной настройке можно 4700+MB/sec увидеть. Хоть диски и стали NVMe (PCI 3 все-таки), но сеть всё равно оказалась быстрее.

А самое хорошее - есть свитчи за разумные деньги (<$100 за 8/12 портов 32/40Gb). Например старенький IS5022, из недостатков - умеет только QDR, и кому-то может быть важно, что только 8 портов, из плюсов - можно держать дома и даже спать рядом, если доработать.

Вообще не шумит, если вентилятор Noctua, дует холодным воздухом, но совершенно не продакшен решение, конечно. Зато по ГОСТ 26074-84 и ГОСТ 8486-86.

WARNING: если кто-то захочет повторить - надо перепаивать провода у вентилятора, там другая распиновка. При попытке просто воткнуть обычный вентилятор - он не вертится, а начинает дымиться!

Или SX6005 - эти уже умеют FDR10 на 12 портов, но главный чип у них снизу, и просто бросить кулер сверху я пока не решился. Но собираюсь этот свитч раскурочить и попробовать. DIY, всё-же.

Есть ещё много разных вариантов, но все их расписывать - я не настолько разбираюсь в ситуации (Brocade ICX серию можно посмотреть).

У всего этого благолепия есть один важный недостаток - те два примера железок, что я выше привёл - это InfiniBand свитчи. Они не умеют Ethernet, и получается только IPoIB. Что из этого следует - Win/Linux машины прекрасно видят друг друга, общаются и всё работает отлично. Главная проблема для меня была - если вам нужны виртуальные машины и чтобы они видели друг друга по быстрой сети - просто так не получится, IB не маршрутизируется на level 3 (поправьте, кто умнее, если я тут чушь написал). Точнее сделать это с виртуальными машинами можно, но не на домашнем железе (SR-IOV нужен и проброс VF внутрь виртуалки), с муторным процессом настройки, плюс с миграцией отдельные заморочки.

К сожалению, пока на eBay нет дешевых 40/56GbE Ethernet свитчей (можете поискать SX1012, если интересно), с которыми можно было-бы поэкспериментировать. Придётся ещё несколько лет подождать. А там, глядишь, и до 25/100GbE можно будет в домашней лабе подобраться.

PS: С IB есть ещё всякие нюансы типа необходимости OpenSM где-то, если switch non-managed, но это всё-же не про настройку IB статья.

Подробнее..

Пьеса об СКС в трех действиях, или Как мы создавали систему из 70 тысяч оптических волокон

10.11.2020 10:22:20 | Автор: admin

Что общего между Крымским мостом и СКС? Мы случайно выяснили: для железнодорожной части этого моста потребовалось 76 000 шпал (по информации из открытых источников). И примерно столько же оптических волокон в нашей СКС, построенной для банка Открытие. Под катом рассказываю, как мы ее делали и тестировали (и даже немного о том, зачем на проекте понадобился маляр).

Действующие лица

  • Банк Открытие он же заказчик, входит в ТОП-10 банков России.

  • ЦОД Компрессор входит в сеть отказоустойчивых дата-центров ИТ-компании КРОК. Cертифицирован Uptime Institute на уровень Tier III.

  • СКС структурированная кабельная система.

  • Инженеры КРОК.

Пролог

В 2019 году банк Открытие решил использовать Компрессор в качестве резервной площадки. В ЦОД для банка выделили машинный зал на 200 стойко-мест. Разумеется, сразу встал вопрос об адаптации инженерной инфраструктуры. Чтобы соответствовать техническим требованиям заказчика, нужно было перестроить всю систему кабельных каналов и смонтировать новую высокоплотную СКС.

Предварительные расчеты по проекту мы провели еще в феврале 2019 года. Приблизительно к апрелю стал понятен объем закупок. В течение всего этого времени мы вели переговоры с Открытием: согласовывали объемы, спецификацию, утверждали проект.

Действие первое: организация

Надежность главное требование для банка при построении СКС. Минута простоя ЦОДа приводит к миллионным убыткам. Также требуется максимально возможная скорость в 100 Гбит/с. По сравнению с активным оборудованием кабельные сети стоят существенно дешевле, так что экономить на СКС дурной тон.

Есть две основные структуры построения СКС: интерконнект и кроссконнект. Заказчик выбрал более дорогой кроссконнект как максимально гибкое решение, с заделом на будущее. Порт на активном оборудовании подключается один раз, так что все переключения происходят в кроссе, а не на оборудовании. Соответственно, риск повредить порт на активке практически отсутствует. А в кроссе его всегда можно заменить.

Уже на этапе проектирования мы поняли, что проект простым не будет. Главной сложностью были объемы: центральный кросс 60+ тысяч волокон нужно было разместить в шести шкафах. И это далеко не максимальная загрузка, а с возможностью роста.

Структурная схема:

Решения с такой плотностью и такими маленькими размерами кросса есть не у всех вендоров, и, как правило, они дорогие. Выбор пал в сторону американского Corning. Во-первых, это качественный поставщик оптоволокна. Во-вторых, только они смогли гарантировать соблюдение сроков. Обещали поставку за 5 недель поставили за 5. Для сравнения: все прочие компании говорили о сроке в 8-10 недель.

Действие второе: монтаж

К маю 2019 года в ЦОДе все еще стояло оборудование предыдущего заказчика, которое требовалось демонтировать. Сделали мы это довольно быстро, и уже в начале июня стартовал монтаж. В это же время мы поняли, что не все стандартные практики тут применимы.

Во-первых, кабель оказался необычайно толстым. Поскольку это была одна из первых реализаций высокоплотной СКС, мы слегка не рассчитали, что кабель с большим количеством волокон будет ощутимо толще обычного. Ведь, когда говорим про оптику, то сразу думаем она же тонкая, около 6 мм в диаметре! А тут мы столкнулись с диаметром около 12 мм. Если раньше такого не встречал, то и представить такой вариант сложно. Так что дорабатывать лоточную систему пришлось буквально на ходу. Кроме того, кабель оказался еще и довольно тяжелым. Пришлось пересчитывать подвесы опорные крепления самого лотка.

Во-вторых, у нас оптика претерминированная, то есть предоконцованная с двух сторон. Проектировщики в таком случае всегда боятся ошибиться с длиной, закладывают запас. Потому что столкнуться с нехваткой куда большая проблема, чем перезаложить. Плюс при заказе претерминированной оптики производители рекомендуют соблюдать условную номенклатуру 3-5 метров. Нормальная практика предусматривать бублики в лотках, куда этот запас можно уложить. В этот раз пришлось искать нестандартный вариант: из-за толщины кабеля не смогли его нужным радиусом разложить в лотке, поэтому аккуратно скрутили его над шкафом.

В-третьих, частично сказались и некоторые ограничения самого ЦОДа. Во время его строительства использовались несколько иные нормы, в том числе, для СКС. Заказчик же выбрал очень высокие шкафы 48U чтобы держать в одной стойке больше железа. Поэтому лотки под оптику, электричество, сами панели было достаточно трудно разместить в просвете над шкафами. Пространства для маневра у нас практически не оставалось рукой подать до фальшпотолка, поэтому сделали так компактно, насколько возможно. Чтобы оптический кросс не занимал половину зала, мы реализовали гибридную систему: с одной стороны разъем на два волокна, с другой на восемь.

Действие третье: тестирование

Без тестирования ни один производитель не поставит свою СКС на гарантию. Есть много вариантов тестирования: с одной перемычкой, с двумя, с тремя, и у многих производителей в дополнение к основным стандартам идут еще и свои собственные требования. Это иногда приводит к недопониманию. На одном из объектов, например, мы тестировали по стандартам, а они со стандартами вендора в некритичных моментах расходились. В итоге пришлось по просьбе заказчика провести повторное тестирование.

Смысл тестирования заключается в том, чтобы проверить, укладываемся ли мы в определенные показатели затухания. Заклятый враг всех оптических систем при тестировании стройка. Пыль оседает на волокно, и протестировать в нужное затухание сложно. При слишком большом затухании некоторые протоколы просто не заработают, а систему необходимо ставить на гарантию. Поэтому приходится чистить от пыли. И тут нам, кстати, помогли ребята из Corning. Приехал их специалист и объяснил: если по результатам теста затухание больше 6 децибел, то чистка не поможет проблема точно в волокне. Кроме того, при подключении тоже рекомендуется продуть сжатым воздухом разъемы на панели.

Для очистки можно использовать любое оборудование, но ведущие производители рекомендуют эталонные патч-корды Fluke, а они сами по себе достаточно дорогие. Обычная штука, которая нужна для прочистки LC разъема, стоит не меньше 5000 рублей (есть и дешевле, но они, как правило, очень быстро выходят из строя). По заявлениям производителей, хватает ее на 500-600 разъемов. Еще дороже эталонные шнуры около 30 тысяч рублей. При этом одного комплекта может хватить и на 100 разъемов, и на 1500.

Тестирование шло около месяца, в ежедневном режиме. И тут надо сказать, что проблем с кабелем практически не было, а единичные случаи Corning оперативно заменил.

В итоге заказчик заехал в ЦОД в июле. Привезли и ввели в эксплуатацию оборудование. В первую очередь телеком, затем серверное железо.

Так выглядит центральный кросс:

Эпилог

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

Подробнее..

AV over IP что это, зачем и для чего?

04.02.2021 16:05:13 | Автор: admin
image

Эта статья целиком и полностью посвящена технологии AV over IP. Это современная технология, которой вряд ли можно кого-то удивить. У нее большое количество достоинств и широкий спектр функций.

Основная функция передача видео по IP-сетям, причем без ограничений по длине кабеля. Технология работает с привычным многим сетевым оборудованием. Так, можно использовать хороший коммутатор, который поддерживает multicast, IGMP, QoS и использовать его в своих целях. Подробности технологии под катом.

Как это работает?


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

В общем-то, технология не особо новая, но с течением времени она совершенствуется. Так, недавно появилась возможность передачи видео в формате 4K/UHD. Соответственно, появилась специализированная линейка систем, которые совместимы с этой технологией и способны обеспечить высокое качество передачи видео.

При этом неважно, на какое расстояние будут передаваться данные несколько метров, километр или десятки километров качество всегда обеспечивается на высоком уровне.

Зачем создали эту технологию?


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

  • Упрощается передача видеоконтента благодаря отсутствию дополнительных элементов, удешевляется построение системы, упрощается обслуживание.
  • Интеграция с существующими ИТ системами означает не только возможность использовать то же оборудование, но и уже существующие системы для контроля и управления сетью.
  • Не нужно дополнительно тратить деньги на дорогостоящее обучение специалистов ProAV.
  • Упрощаются вопросы проектирования, модернизации, логистики и так далее.

Критический момент здесь возможность масштабирования системы в будущем. Это относительно просто и недорого, особенно если сравнивать с масштабированием специализированных сетей на основе ProAV, HDBaseT и т.п.

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

А что насчет технических особенностей?


О преимуществах этой сети мы кратко рассказали выше, ну а сейчас можно обсудить подробнее, раскрыв и другие возможности. Всего у AV over IP три главных особенности.

Возможность сжатия контента


И на предприятиях, и в домах чаще всего используются гигабитные каналы. Это 1 и 10 Гбит/с. К сожалению, пропускной способности этих каналов недостаточно для передачи контента в ультравысоком качестве, поэтому приходится использовать сжатие. Оно применяется практически во всех решениях AV-over-IP.

В некоторых случаях возможна задержка, поскольку сжатие, хоть и выполняется быстро, но не является мгновенным процессом. Для ускорения применяется сильное сжатие с небольшими визуальными артефактами. Большинство пользователей эти изменения не замечают. Такой прием применяется для узких каналов. А вот в 10 Гбит/с каналах можно использовать сжатие почти без потерь качества.

Чаще всего применяются кодеки H.264, H.265 (также известен как HEVC), JPEG 2000 и AptoVision BlueRiver. Они хорошо подходят для передачи видео в формате 4К. AptoVision BlueRiver разработанный недавно кодек, который позволяет передавать видео очень высокого качества практически без потерь и задержек.



А что насчет HDMI?


Система передачи сигналов должна в обязательном порядке быть совместима с используемым оборудованием. Наиболее популярное и распространенное сейчас оборудование интерфейсы HDMI версий 1.x и 2.0. Отличаются они, в основном, пропускной способностью.

Кроме того, у HDMI есть и протокол защиты HDCP. Чтобы видео не блокировалось, должны поддерживаться все версии HDCP.

Плюс должны поддерживаться и версии HDMI. В случае v2 пропускная способность составляет 18 ГБ/с. У AV over IP все это есть, так что можно передавать видео в любом качестве, включая 4K/UHD HDR, без особых проблем.

Построение сети


Как и говорилось выше, для AV over IP вполне достаточно стандартных каналов 1 Гбит/с или 10 Гбит/с. Соответственно, и коммутатор можно выбрать стандартный. Если потеря качества и задержка примерно в полсекунды некритичны, можно выбрать сетевой коммутатор 1 Гбит/с. Такой способ стоит выбрать в том случае, если сигнал нужно передать на большое расстояние.

Что касается 10 Гбит/с, то такой коммутатор можно использовать для передачи видео высокого качества как на короткие расстояния, так и на большое расстояние. Изображение при этом будет оставаться максимально детализированным.

Коммутатор, который используется для построения сети, должен поддерживать следующие функции:
  • Full Layer 2/3, IGMP V. 2 snooping
  • FASTLEAVE для мгновенного переключения 4K
  • IGMP Queries и др.

Что касается стоимости создания такой сети, то в небольших системах стоит использовать оборудование HDBaseT и HDMI. Если планируется разработать масштабную инфраструктуру, тогда потребуются уже AV Over IP, для которых не нужна дополнительная кабельная инфраструктура.

В качестве вывода можно сказать, что поскольку качество передаваемого по сетям контента постоянно растет, то и AV over IP будет становиться все популярнее и востребованнее.

Что предлагает Zyxel


Совместно с ведущим производителем AV решений компанией ATEN AV Over IP функционал был включен состав двух серий коммутаторов:


Решение было всесторонне протестировано в лаборатории ATEN. Полученные результаты доступна в соответствующей статье: Часть 1 и Часть 2.

А если понравилось, заходите к нам и оставайтесь:
Новостной канал в Telegram
Телеграм-чат поддержки для специалистов
Форум для специалистов
Наш YouTube
Подробнее..

Перевод Сеть контейнеров это не сложно

26.05.2021 22:23:37 | Автор: admin

Работа с контейнерами многим кажется волшебством, пришло время разобраться как работает сеть контейнеров. Мы покажем на примерах, что это совсем не сложно. Помните, что контейнеры - всего лишь изолированные процессы Linux.

В этой статье мы ответим на следующие вопросы:

  • Как виртуализировать сетевые ресурсы, чтобы контейнеры думали, что у каждого из них есть выделенный сетевой стек?

  • Как превратить контейнеры в дружелюбных соседей, не дать им мешать друг другу и научить хорошо общаться?

  • Как настроить сетевой доступ из контейнера во внешний мир (например, в Интернет)?

  • Как получить доступ к контейнерам, работающим на сервере, из внешнего мира (публикация портов)?

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

  • Network namespaces

  • Virtual Ethernet devices (veth)

  • Virtual network switches (bridge)

  • IP маршрутизация и преобразование сетевых адресов (NAT)

Нам потребуется немного сетевой магии и никакого кода ...

С чего начать?

Все примеры в статье были сделаны на виртуальной машине CentOS 8. Но вы можете выбрать тот дистрибутив, который вам нравится.

Создадим виртуальную машину с помощью Vagrant и подключимся к ней по SSH:

$ vagrant init centos/8$ vagrant up$ vagrant ssh[vagrant@localhost ~]$ uname -aLinux localhost.localdomain 4.18.0-147.3.1.el8_1.x86_64

Мы не будем использовать какое-либо популярное решение для контейнеризации (например, docker или podman). Вместо этого мы сосредоточимся на основных концепциях и воспользуемся минимальным набором инструментов для достижения наших учебных целей.

Изоляция контейнеров с помощью Network namespaces

Что составляет сетевой стек Linux? Ну, очевидно, набор сетевых устройств. Что еще? Набор правил маршрутизации. И не забываем про настройку netfilter, создадим необходимые правила iptables.

Напишем небольшой скрипт inspect-net-stack.sh:

#!/usr/bin/env bashecho "> Network devices"ip linkecho -e "\n> Route table"ip routeecho -e "\n> Iptables rules"iptables --list-rules

Но прежде, чем запускать его, давайте внесём изменения в правила iptables, чтобы идентифицировать их в дальнейшем:

$ sudo iptables -N ROOT_NS

Запускаем скрипт:

$ sudo ./inspect-net-stack.sh> Network devices1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000    link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff> Route tabledefault via 10.0.2.2 dev eth0 proto dhcp metric 10010.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100> Iptables rules-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT-N ROOT_NS

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

Мы уже упоминали об одном из Linux namespaces, используемых для изоляции контейнеров, которое называет сетевое пространство имён (Network namespace). Если заглянуть в man ip-netns, то мы прочтём, что Network namespace логически является копией сетевого стека со своими собственными маршрутами, правилами брандмауэра и сетевыми устройствами. Мы не будем затрагивать другие Linux namespaces в этой статье и ограничимся только областью видимости сетевого стека.

Для создания Network namespace нам достаточно утилиты ip, которая входим в популярный пакет iproute2. Создадим новое сетевое пространство имён:

$ sudo ip netns add netns0$ ip netnsnetns0

Новое сетевое пространство имён создано, но как начать его использовать? Воспользуемся командой Linux под названием nsenter. Она осуществляет вход в одно или несколько указанных пространств имен, а затем выполняет в нём указанную программу:

$ sudo nsenter --net=/var/run/netns/netns0 bash# The newly created bash process lives in netns0$ sudo ./inspect-net-stack.sh> Network devices1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00> Route table> Iptables rules-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT

Приведённый выше пример показывает, что процесс bash, работающий внутри пространства имён netns0, видит совершенно другой сетевой стек. Отсутствуют правила маршрутизации, и правила iptables, есть только один loopback interface. Все идет по плану...

Подключаем контейнер к хосту через virtual Ethernet devices (veth)

Выделенный сетевой стек будет бесполезен, если к нему отсутствует доступ. К счастью, Linux предоставляет подходящее средство для этого - virtual Ethernet devices (veth)! Согласно man veth, veth-device - это виртуальные устройства Ethernet. Они работают как туннели между сетевыми пространствами имён для создания моста к физическому сетевому устройству в другом пространстве имён, а также могут использоваться как автономные сетевые устройства.

Виртуальные Ethernet устройства всегда работают парами. Создадим их прямо сейчас:

$ sudo ip link add veth0 type veth peer name ceth0

С помощью этой единственной команды мы только что создали пару взаимосвязанных виртуальных Ethernet устройств. Имена veth0 и ceth0 были выбраны произвольно:

$ ip link1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000    link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff5: ceth0@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000    link/ether 66:2d:24:e3:49:3f brd ff:ff:ff:ff:ff:ff6: veth0@ceth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000    link/ether 96:e8:de:1d:22:e0 brd ff:ff:ff:ff:ff:ff

И veth0, и ceth0 после создания находятся в сетевом стеке хоста (также называемом Root Network namespace). Чтобы связать корневое пространство имён с пространством имён netns0, нам нужно сохранить одно из устройств в корневом пространстве имён и переместить другое в netns0:

$ sudo ip link set ceth0 netns netns0# List all the devices to make sure one of them disappeared from the root stack$ ip link1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000    link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff6: veth0@if5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000    link/ether 96:e8:de:1d:22:e0 brd ff:ff:ff:ff:ff:ff link-netns netns0

Как только мы включаем устройства и назначаем правильные IP-адреса, любой пакет, происходящий на одном из них, немедленно появляется на его одноранговом устройстве, соединяющем два пространства имён. Начнем с корневого пространства имён:

$ sudo ip link set veth0 up$ sudo ip addr add 172.18.0.11/16 dev veth0

Продолжим сnetns0:

$ sudo nsenter --net=/var/run/netns/netns0$ ip link set lo up  # whoops$ ip link set ceth0 up$ ip addr add 172.18.0.10/16 dev ceth0$ ip link1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:005: ceth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000    link/ether 66:2d:24:e3:49:3f brd ff:ff:ff:ff:ff:ff link-netnsid 0

Проверяем подключение:

# From netns0, ping root's veth0$ ping -c 2 172.18.0.11PING 172.18.0.11 (172.18.0.11) 56(84) bytes of data.64 bytes from 172.18.0.11: icmp_seq=1 ttl=64 time=0.038 ms64 bytes from 172.18.0.11: icmp_seq=2 ttl=64 time=0.040 ms--- 172.18.0.11 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 58msrtt min/avg/max/mdev = 0.038/0.039/0.040/0.001 ms# Leave netns0$ exit# From root namespace, ping ceth0$ ping -c 2 172.18.0.10PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data.64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.073 ms64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.046 ms--- 172.18.0.10 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 3msrtt min/avg/max/mdev = 0.046/0.059/0.073/0.015 ms

Обратите внимание, если мы попытаемся проверить доступность любых других адресов из пространства имен netns0, у нас ничего не получится:

# Inside root namespace$ ip addr show dev eth02: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000    link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0       valid_lft 84057sec preferred_lft 84057sec    inet6 fe80::5054:ff:fee3:2777/64 scope link       valid_lft forever preferred_lft forever# Remember this 10.0.2.15$ sudo nsenter --net=/var/run/netns/netns0# Try host's eth0$ ping 10.0.2.15connect: Network is unreachable# Try something from the Internet$ ping 8.8.8.8connect: Network is unreachable

Для таких пакетов в таблице маршрутизации netns0 просто нет маршрута. В настоящий момент существует единственный маршрут до сети 172.18.0.0/16:

# From netns0 namespace:$ ip route172.18.0.0/16 dev ceth0 proto kernel scope link src 172.18.0.10

В Linux есть несколько способов заполнения таблицы маршрутизации. Один из них - извлечение маршрутов из подключенных напрямую сетевых интерфейсов. Помните, что таблица маршрутизации в netns0 была пустой сразу после создания пространства имен. Но затем мы добавили туда устройство ceth0 и присвоили ему IP-адрес 172.18.0.10/16. Поскольку мы использовали не простой IP-адрес, а комбинацию адреса и сетевой маски, сетевому стеку удалось извлечь из него информацию о маршрутизации. Каждый пакет, предназначенный для сети 172.18.0.0/16, будет отправлен через устройство ceth0. Но все остальные пакеты будут отброшены. Точно так же есть новый маршрут в корневом пространстве имен:

# From root namespace:$ ip route# ... omitted lines ...172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11

На этом этапе мы ответили на первый вопрос. Теперь мы знаем, как изолировать, виртуализировать и подключать сетевые стеки Linux.

Объединение контейнеров с помощью virtual network switch (bridge)

Вся идея контейнеризации сводится к эффективному совместному использованию ресурсов. То есть мы крайне редко запускаем на хосте единственный контейнер. Вместо этого стараемся запустить как можно больше изолированных процессов на одном хосте. Итак, чтобы произошло, если бы мы разместили несколько контейнеров на одном хосте, следуя описанному выше подходу? Добавим второй контейнер:

# From root namespace$ sudo ip netns add netns1$ sudo ip link add veth1 type veth peer name ceth1$ sudo ip link set ceth1 netns netns1$ sudo ip link set veth1 up$ sudo ip addr add 172.18.0.21/16 dev veth1$ sudo nsenter --net=/var/run/netns/netns1$ ip link set lo up$ ip link set ceth1 up$ ip addr add 172.18.0.20/16 dev ceth1

Проверим доступность:

# From netns1 we cannot reach the root namespace!$ ping -c 2 172.18.0.21PING 172.18.0.21 (172.18.0.21) 56(84) bytes of data.From 172.18.0.20 icmp_seq=1 Destination Host UnreachableFrom 172.18.0.20 icmp_seq=2 Destination Host Unreachable--- 172.18.0.21 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 55mspipe 2# But there is a route!$ ip route172.18.0.0/16 dev ceth1 proto kernel scope link src 172.18.0.20# Leaving netns1$ exit# From root namespace we cannot reach the netns1$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.From 172.18.0.11 icmp_seq=1 Destination Host UnreachableFrom 172.18.0.11 icmp_seq=2 Destination Host Unreachable--- 172.18.0.20 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 23mspipe 2# From netns0 we CAN reach veth1$ sudo nsenter --net=/var/run/netns/netns0$ ping -c 2 172.18.0.21PING 172.18.0.21 (172.18.0.21) 56(84) bytes of data.64 bytes from 172.18.0.21: icmp_seq=1 ttl=64 time=0.037 ms64 bytes from 172.18.0.21: icmp_seq=2 ttl=64 time=0.046 ms--- 172.18.0.21 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 33msrtt min/avg/max/mdev = 0.037/0.041/0.046/0.007 ms# But we still cannot reach netns1$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.From 172.18.0.10 icmp_seq=1 Destination Host UnreachableFrom 172.18.0.10 icmp_seq=2 Destination Host Unreachable--- 172.18.0.20 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 63mspipe 2

Что-то пошло не так... По какой-то причине мы не можем подключиться из netns1 к root namespace. А из root namespace мы не можем подключиться к netns1. Однако, поскольку оба контейнера находятся в одной IP-сети 172.18.0.0/16, есть доступ к veth1 хоста из контейнера netns0. Интересно...

Возможно, мы столкнулись с конфликтом маршрутов. Давайте проверим таблицу маршрутизации в root namespace:

$ ip route# ... omitted lines ...172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11172.18.0.0/16 dev veth1 proto kernel scope link src 172.18.0.21

После добавления второй пары veth в таблице маршрутизации root namespace появился новый маршрут 172.18.0.0/16 dev veth1 proto kernel scope link src 172.18.0.21, но маршрут до этой подсети уже существовал! Когда второй контейнер пытается проверить связь с устройством veth1, используется первый маршрут и мы видим ошибку подключения. Если бы мы удалили первый маршрут sudo ip route delete 172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11 и перепроверили подключение, то увидели бы обратную ситуацию, то есть подключение netns1 будет восстановлено, но netns0 останется в подвешенном состоянии.

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

Рассмотрим Linux Bridge - еще один виртуализированный сетевой объект! Linux Bridge ведёт себя как коммутатор. Он пересылает пакеты между подключенными к нему интерфейсами. А поскольку это коммутатор, то он работает на уровне L2 (то есть Ethernet).

Чтобы предыдущие этапы нашего эксперимента в дальнейшем не вносили путаницы, удалим существующие сетевые пространства имён:

$ sudo ip netns delete netns0$ sudo ip netns delete netns1# But if you still have some leftovers...$ sudo ip link delete veth0$ sudo ip link delete ceth0$ sudo ip link delete veth1$ sudo ip link delete ceth1

Заново создаём два контейнера. Обратите внимание, мы не назначаем IP-адреса новым устройствам veth0 и veth1:

$ sudo ip netns add netns0$ sudo ip link add veth0 type veth peer name ceth0$ sudo ip link set veth0 up$ sudo ip link set ceth0 netns netns0$ sudo nsenter --net=/var/run/netns/netns0$ ip link set lo up$ ip link set ceth0 up$ ip addr add 172.18.0.10/16 dev ceth0$ exit$ sudo ip netns add netns1$ sudo ip link add veth1 type veth peer name ceth1$ sudo ip link set veth1 up$ sudo ip link set ceth1 netns netns1$ sudo nsenter --net=/var/run/netns/netns1$ ip link set lo up$ ip link set ceth1 up$ ip addr add 172.18.0.20/16 dev ceth1$ exit

Убедимся, что на хосте нет новых маршрутов:

$ ip routedefault via 10.0.2.2 dev eth0 proto dhcp metric 10010.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100

И, наконец, создадим bridge интерфейс:

$ sudo ip link add br0 type bridge$ sudo ip link set br0 up

Теперь подключим к нему veth0 и veth1:

$ sudo ip link set veth0 master br0$ sudo ip link set veth1 master br0

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

$ sudo nsenter --net=/var/run/netns/netns0$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.64 bytes from 172.18.0.20: icmp_seq=1 ttl=64 time=0.259 ms64 bytes from 172.18.0.20: icmp_seq=2 ttl=64 time=0.051 ms--- 172.18.0.20 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 2msrtt min/avg/max/mdev = 0.051/0.155/0.259/0.104 ms
$ sudo nsenter --net=/var/run/netns/netns1$ ping -c 2 172.18.0.10PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data.64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.037 ms64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.089 ms--- 172.18.0.10 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 36msrtt min/avg/max/mdev = 0.037/0.063/0.089/0.026 ms

Прекрасно! Все отлично работает. При этом мы даже не настраивали интерфейсы veth0 и veth1. Мы назначили только два IP-адреса интерфейсам ceth0 и ceth1. Но поскольку они оба находятся в одном сегменте Ethernet (подключены к виртуальному коммутатору), существует возможность подключения на уровне L2:

$ sudo nsenter --net=/var/run/netns/netns0$ ip neigh172.18.0.20 dev ceth0 lladdr 6e:9c:ae:02:60:de STALE$ exit$ sudo nsenter --net=/var/run/netns/netns1$ ip neigh172.18.0.10 dev ceth1 lladdr 66:f3:8c:75:09:29 STALE$ exit

Поздравляем, мы узнали, как превратить контейнеры в дружественных соседей, избежать проблем и сохранить сетевую связность.

Настраиваем сетевой доступ из контейнера во внешний мир (IP routing and masquerading)

Сейчас контейнеры могут подключаться друг к другу. Но будут ли удачны подключения к хосту, то есть к корневому пространству имён?

$ sudo nsenter --net=/var/run/netns/netns0$ ping 10.0.2.15  # eth0 addressconnect: Network is unreachable

Интерфейс eth0 не доступен. Всё очевидно, в netns0 отсутствует маршрут для этого подключения:

$ ip route172.18.0.0/16 dev ceth0 proto kernel scope link src 172.18.0.10

Корневое пространство имён также не может взаимодействовать с контейнерами:

# Use exit to leave netns0 first:$ ping -c 2 172.18.0.10PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data.From 213.51.1.123 icmp_seq=1 Destination Net UnreachableFrom 213.51.1.123 icmp_seq=2 Destination Net Unreachable--- 172.18.0.10 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3ms$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.From 213.51.1.123 icmp_seq=1 Destination Net UnreachableFrom 213.51.1.123 icmp_seq=2 Destination Net Unreachable--- 172.18.0.20 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3ms

Чтобы установить связь между корневым пространством имён и пространством имён контейнера, нам нужно назначить IP-адрес сетевому интерфейсу моста:

$ sudo ip addr add 172.18.0.1/16 dev br0

Теперь после того, как мы назначили IP-адрес интерфейсу моста, мы получили маршрут в таблице маршрутизации хоста:

$ ip route# ... omitted lines ...172.18.0.0/16 dev br0 proto kernel scope link src 172.18.0.1$ ping -c 2 172.18.0.10PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data.64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.036 ms64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.049 ms--- 172.18.0.10 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 11msrtt min/avg/max/mdev = 0.036/0.042/0.049/0.009 ms$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.64 bytes from 172.18.0.20: icmp_seq=1 ttl=64 time=0.059 ms64 bytes from 172.18.0.20: icmp_seq=2 ttl=64 time=0.056 ms--- 172.18.0.20 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 4msrtt min/avg/max/mdev = 0.056/0.057/0.059/0.007 ms

Контейнер, вероятно, также получил возможность пинговать интерфейс моста, но они все ещё не могут связаться с хостом eth0. Нам нужно добавить маршрут по умолчанию для контейнеров:

$ sudo nsenter --net=/var/run/netns/netns0$ ip route add default via 172.18.0.1$ ping -c 2 10.0.2.15PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=0.036 ms64 bytes from 10.0.2.15: icmp_seq=2 ttl=64 time=0.053 ms--- 10.0.2.15 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 14msrtt min/avg/max/mdev = 0.036/0.044/0.053/0.010 ms# And repeat the change for netns1

Теперь наш хост является маршрутизатором, а интерфейс моста стал шлюзом по умолчанию для контейнеров.

Отлично, нам удалось добиться сетевой связности контейнеров с корневым пространством имён. Теперь давайте попробуем подключить их к внешнему миру. По умолчанию переадресация пакетов (ip packet forwarding), то есть функциональность маршрутизатора в Linux отключена. Нам нужно её включить

# In the root namespacesudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

Теперь самое интересное - проверка подключения:

$ sudo nsenter --net=/var/run/netns/netns0$ ping 8.8.8.8# hangs indefinitely long for me...

Всё равно не работает. Мы что-то упустили? Если бы контейнер отправлял пакеты во внешний мир, сервер-получатель не смог бы отправлять пакеты обратно в контейнер, потому что IP-адрес контейнера является частным и правила маршрутизации для этого конкретного IP-адреса известны только в локальной сети. К тому же многие контейнеры в мире имеют один и тот же частный IP-адрес 172.18.0.10. Решение этой проблемы называется преобразованием сетевых адресов (NAT). Принцип работы, следующий - перед отправкой во внешнюю сеть пакеты, отправленные контейнерами, заменяют свои исходные IP-адреса (source IP addesses) на адрес внешнего интерфейса хоста. Хост также будет отслеживать все существующие сопоставления (mapping) и по прибытии будет восстанавливать IP-адреса перед пересылкой пакетов обратно в контейнеры. Звучит сложно, но у меня для вас хорошие новости! Нам нужна всего одна команда, чтобы добиться требуемого результата:

$ sudo iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o br0 -j MASQUERADE

Команда довольно проста. Мы добавляем новое правило в таблицу nat цепочки POSTROUTING с просьбой выполнить MASQUERADE всех исходящих пакетов из сети 172.18.0.0/16, но не через интерфейс моста.

Проверьте подключение:

$ sudo nsenter --net=/var/run/netns/netns0$ ping -c 2 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=43.2 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=36.8 ms--- 8.8.8.8 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 2msrtt min/avg/max/mdev = 36.815/40.008/43.202/3.199 ms
$ sudo nsenter --net=/var/run/netns/netns0$ ping -c 2 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=43.2 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=36.8 ms--- 8.8.8.8 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 2msrtt min/avg/max/mdev = 36.815/40.008/43.202/3.199 ms

Помните, что политика iptables по умолчанию - ACCEPT для каждой цепочки, она может быть довольно опасной в реальных условиях:

sudo iptables -S-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT

В качестве хорошего примера Docker вместо этого ограничивает все по умолчанию, а затем разрешает только для известных маршрутов:

$ sudo iptables -t filter --list-rules-P INPUT ACCEPT-P FORWARD DROP-P OUTPUT ACCEPT-N DOCKER-N DOCKER-ISOLATION-STAGE-1-N DOCKER-ISOLATION-STAGE-2-N DOCKER-USER-A FORWARD -j DOCKER-USER-A FORWARD -j DOCKER-ISOLATION-STAGE-1-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT-A FORWARD -o docker0 -j DOCKER-A FORWARD -i docker0 ! -o docker0 -j ACCEPT-A FORWARD -i docker0 -o docker0 -j ACCEPT-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 5000 -j ACCEPT-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2-A DOCKER-ISOLATION-STAGE-1 -j RETURN-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP-A DOCKER-ISOLATION-STAGE-2 -j RETURN-A DOCKER-USER -j RETURN$ sudo iptables -t nat --list-rules-P PREROUTING ACCEPT-P INPUT ACCEPT-P POSTROUTING ACCEPT-P OUTPUT ACCEPT-N DOCKER-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 5000 -j MASQUERADE-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER-A DOCKER -i docker0 -j RETURN-A DOCKER ! -i docker0 -p tcp -m tcp --dport 5005 -j DNAT --to-destination 172.17.0.2:5000$ sudo iptables -t mangle --list-rules-P PREROUTING ACCEPT-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT-P POSTROUTING ACCEPT$ sudo iptables -t raw --list-rules-P PREROUTING ACCEPT-P OUTPUT ACCEPT

Настроим сетевой доступ из внешнего мира в контейнеры (port publishing)

Публикация портов контейнеров для некоторых (или всех) интерфейсов хоста - популярная практика. Но что на самом деле означает публикация порта?

Представьте, что у нас есть сервис, работающий внутри контейнера:

$ sudo nsenter --net=/var/run/netns/netns0$ python3 -m http.server --bind 172.18.0.10 5000

Если мы попытаемся отправить HTTP-запрос этому сервису с хоста, все будет работать (ну, есть связь между корневым пространством имён и всеми интерфейсами контейнера, почему бы и нет?):

# From root namespace$ curl 172.18.0.10:5000<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"># ... omitted lines ...

Однако, если бы мы получили доступ к этому серверу из внешнего мира, какой IP-адрес мы бы использовали? Единственный IP-адрес, который мы можем знать, - это адрес внешнего интерфейса хоста eth0:

$ curl 10.0.2.15:5000curl: (7) Failed to connect to 10.0.2.15 port 5000: Connection refused

Таким образом, нам нужно найти способ перенаправить все пакеты, поступающие на порт 5000 интерфейса eth0 хоста, на адрес172.18.0.10:5000. Или, другими словами, нам нужно опубликовать порт 5000 контейнера на интерфейсе eth0 хоста.

# External trafficsudo iptables -t nat -A PREROUTING -d 10.0.2.15 -p tcp -m tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000# Local traffic (since it doesn't pass the PREROUTING chain)sudo iptables -t nat -A OUTPUT -d 10.0.2.15 -p tcp -m tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000

Кроме того, нам нужно включить iptables intercepting traffic over bridged networks (перехватывать трафик bridged networks):

sudo modprobe br_netfilter

Время проверить!

curl 10.0.2.15:5000<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"># ... omitted lines ...

Разбираемся в работе Docker network drivers

Но что же вам сделать теперь со всеми этими бесполезными знаниями? Например, мы могли бы попытаться разобраться в некоторых сетевых режимах Docker!

Начнем с режима --network host. Попробуйте сравнить вывод следующих команд ip link и sudo docker run -it --rm --network host alpine ip link. Сюрприз, они совпадут! Таким образом host mode Docker просто не использует изоляцию сетевого пространства имён и контейнеры работают в корневом сетевом пространстве имён и совместно используют сетевой стек с хост-системой.

Следующий режим, который нужно проверить, - это --network none. Вывод команды sudo docker run -it --rm --network none alpine ip link показывает только один сетевой интерфейс обратной loopback. Это очень похоже на наши наблюдения за только что созданным сетевым пространством имен. То есть до того момента, когда мы добавляли какие-либо veth устройства.

И последнее, но не менее важное: режим --network bridge (по умолчанию), это именно то, что мы пытались воспроизвести в этой статье.

Сети и rootless контейнеры

Одной из приятных особенностей диспетчера контейнеров podman является его ориентация на rootless контейнеры. Однако, как вы, вероятно, заметили, в этой статье мы использовали много эскалаций sudo и без root-прав настроить сеть невозможно. При настройке сетей rootful контейнеров Podman очень близок к Docker. Но когда дело доходит до rootless контейнеров, Podman полагается на проект slirp4netns:

Начиная с Linux 3.8, непривилегированные пользователи могут создавать network_namespaces (7) вместе с user_namespaces (7). Однако непривилегированные сетевые пространства имен оказались не очень полезными, потому что для создания пар veth (4) в пространствах имен хоста и сети по-прежнему требуются привилегии root (иначе доступ в Интернету будет отсутствовать).

slirp4netns позволяет получить доступ из сетевое пространства имен в Интернет непривилегированным пользователям, подключая устройство TAP в сетевом пространстве имен к стеку TCP/IP usermode (slirp).

Сеть rootless контейнера весьма ограничена: технически сам контейнер не имеет IP-адреса, потому что без привилегий root невозможно настроить сетевое устройство. Более того, проверка связи (ping) из rootless контейнера не работает, поскольку в нем отсутствует функция безопасности CAP_NET_RAW, которая необходима для работы команды ping.

Заключение

Рассмотренный в этой статье подход к организации сети контейнеров является лишь одним из возможных (ну, пожалуй, наиболее широко используемым). Есть еще много других способов, реализованных через официальные или сторонние плагины, но все они сильно зависят от средств виртуализации сети Linux. Таким образом, контейнеризацию по праву можно рассматривать как технологию виртуализации.

Подробнее..

Как Иван ошибку в бэкенде локализовывал

09.09.2020 12:15:30 | Автор: admin
В комментариях к одной из моих статей про базовые команды Linux shell для тестировщиков справедливо заметили, что в ней не было указано применение команд в процессе тестирования. Я подумал, что лучше поздно, чем никогда, поэтому решил рассказать историю Backend QA-инженера Вани, который столкнулся с неожиданным поведением сервиса и попытался разобраться, где именно случилась ошибка.



Что тестировал Ваня


Ваня знал, что ему предстоит тестировать связку nginx + сервис.
Здесь я сразу сделаю ремарку: такая связка была выбрана для этой статьи просто потому, что она нагляднее всего может продемонстрировать применение различных утилит при дебаге проблемы и потому, что её очень просто сконфигурировать и поднять. В реальных условиях это может быть либо просто сервис, либо цепочка сервисов, которые делают запросы друг другу.

В качестве сервиса выступает дефолтный HTTP сервер Python SimpleHTTPServer, который в ответ на запрос без параметров выводит содержимое текущей директории:

[root@ivan test_dir_srv]# ls -ltotal 0-rw-r--r-- 1 root root 0 Aug 25 11:23 test_file[root@ivan test_dir_srv]# python3 -m http.server --bind 127.0.0.1 8000Serving HTTP on 127.0.0.1 port 8000 (http://personeltest.ru/away/127.0.0.1:8000/) ...

Nginx же сконфигурирован следующим образом:

upstream test {server 127.0.0.1:8000;}server {listen    80;location / {proxy_pass http://test;}}

Ване нужно было протестировать один-единственный тест-кейс: проверить, что запрос на / работает. Он проверил, и всё работало:

MacBook-Pro-Ivan:~ ivantester$ curl http://12.34.56.78<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Directory listing for /</title></head><body><h1>Directory listing for /</h1><hr><ul><li><a href="test_file">test_file</a></li></ul><hr></body></html>

Но затем в один момент на тестовом стенде разработчики что-то обновили, и Ваня получил ошибку:

MacBook-Pro-Ivan:~ ivantester$ curl http://12.34.56.78<html><head><title>502 Bad Gateway</title></head><body bgcolor="white"><center><h1>502 Bad Gateway</h1></center><hr><center>nginx/1.14.2</center></body></html>

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

Первая мысль Вани: логи


Действительно, если случилась ошибка, то нужно просто найти её в лог-файле. Но сначала нужно найти сам лог-файл. Ваня полез в Google и узнал, что часто логи лежат в директории /var/log. Действительно, там нашлась директория nginx:

[root@ivan ~]# ls /var/log/nginx/access.log access.log-20200831 error.log error.log-20200831

Иван посмотрел последние строчки error лога и понял, в чём дело: разработчики ошиблись в конфигурации nginx, в порт upstream закралась опечатка.

[root@ivan ~]# tail /var/log/nginx/error.log2020/08/31 04:36:21 [error] 15050#15050: *90452 connect() failed (111: Connection refused) while connecting to upstream, client: 31.170.95.221, server: , request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:8009/", host: "12.34.56.78"

Какой можно сделать из этого вывод? Логи лучший друг тестировщиков и разработчиков при локализации ошибок. Если есть какое-то неожиданное поведение сервиса, а в логах при этом ничего нет, то это повод вернуть задачу в разработку с просьбой добавить логов. Ведь если б nginx не писал в лог о неудачной попытке достучаться до апстрима, то, согласитесь, искать проблему было бы сложнее?

В тот момент Ваня задумался: А что, если бы в nginx логи лежали в другой директории? Как бы я их нашёл? Через пару лет у Вани будет больше опыта работы с сервисами в Linux, и он будет знать, что путь к лог-файлу часто передают сервису аргументом командной строки, либо он содержится в файле конфигурации, путь к которому также часто передают сервису аргументом командной строки. Ну и в идеале путь к лог-файлу должен быть прописан в документации сервиса.

Кстати, через файл конфигурации можно найти путь к лог-файлу и в nginx:

[root@ivan ~]# ps ax | grep nginx | grep masterroot   19899 0.0 0.0 57392 2872 ?    Ss  2019  0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf[root@ivan ~]# grep "log" /etc/nginx/nginx.conferror_log /var/log/nginx/error.log warn;log_format main '$remote_addr - $remote_user [$time_local] "$request" 'access_log /var/log/nginx/access.log main;

А что если в логах ничего нет?


В свободное время Ваня решил подумать, а как бы он справился с задачей, если бы nginx не писал ничего в лог. Ваня знал, что сервис слушает порт 8000, поэтому решил посмотреть трафик на этом порту на сервере. С этим ему помогла утилита tcpdump. При правильной конфигурации он видел запрос и ответ:

Дамп трафика на порту 8000
[root@ivan ~]# tcpdump -nn -i lo -A port 8000tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes09:10:42.114284 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [S], seq 3390176024, win 43690, options [mss 65495,sackOK,TS val 830366494 ecr 0,nop,wscale 8], length 0E..<..@.@..............@.............0.........1~c.........09:10:42.114293 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [S.], seq 4147196208, ack 3390176025, win 43690, options [mss 65495,sackOK,TS val 830366494 ecr 830366494,nop,wscale 8], length 0E..<..@.@.<..........@...110.........0.........1~c.1~c.....09:10:42.114302 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [.], ack 1, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4..@.@..............@.....111.....(.....1~c.1~c.09:10:42.114329 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [P.], seq 1:88, ack 1, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 87E.....@.@..b...........@.....111...........1~c.1~c.GET / HTTP/1.0Host: testConnection: closeUser-Agent: curl/7.64.1Accept: */*09:10:42.114333 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [.], ack 88, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4R/@.@............@...111...p.....(.....1~c.1~c.09:10:42.115062 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [P.], seq 1:155, ack 88, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 154E...R0@.@............@...111...p...........1~c.1~c.HTTP/1.0 200 OKServer: SimpleHTTP/0.6 Python/3.7.2Date: Mon, 07 Sep 2020 13:10:42 GMTContent-type: text/html; charset=utf-8Content-Length: 34009:10:42.115072 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [.], ack 155, win 175, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4.@.@..............@...p.11......(.....1~c.1~c.09:10:42.115094 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [P.], seq 155:495, ack 88, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 340E...R1@.@..<.........@...11....p.....|.....1~c.1~c.<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Directory listing for /</title></head><body><h1>Directory listing for /</h1><hr><ul><li><a href="test_file">test_file</a></li></ul><hr></body></html>09:10:42.115098 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [.], ack 495, win 180, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4.@.@..............@...p.13......(.....1~c.1~c.09:10:42.115128 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [F.], seq 495, ack 88, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4R2@.@............@...13....p.....(.....1~c.1~c.09:10:42.115264 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [F.], seq 88, ack 496, win 180, options [nop,nop,TS val 830366495 ecr 830366494], length 0E..4..@.@..............@...p.13 .....(.....1~c.1~c.09:10:42.115271 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [.], ack 89, win 171, options [nop,nop,TS val 830366495 ecr 830366495], length 0E..4R3@.@............@...13 ...q.....(.....1~c.1~c.^C12 packets captured24 packets received by filter0 packets dropped by kernel


При неправильной конфигурации (с портом 8009 в апстриме nginx) на порту 8000 никакого трафика не было. Ваня обрадовался: теперь даже если разработчики забыли реализовать запись в лог при сетевых ошибках, всё равно можно хотя бы узнать, идёт ли трафик на нужный хост или порт.

Какой вывод можно сделать из этой истории? Даже если логов нет, в Linux есть утилиты, которые могут помочь с локализацией проблем.

А если не сеть?


Всё хорошо работало, но однажды Ваня снова получил ошибку, на этот раз другую:

MacBook-Pro-Ivan:~ ivantester$ curl http://12.34.56.78<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"><html><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8"><title>Error response</title></head><body><h1>Error response</h1><p>Error code: 404</p><p>Message: File not found.</p><p>Error code explanation: HTTPStatus.NOT_FOUND - Nothing matches the given URI.</p></body></html>

Ваня снова зашёл на сервер, но в этот раз проблема не была связана с сетью. В логе сервиса тоже было написано File not found, и Ваня решил разобраться, почему внезапно появилась такая ошибка. Он знает, что есть процесс python3 -m http.server, но не знает, содержимое какой директории выводит этот сервис (или, другими словами, какая у этого процесса current working directory). Он узнаёт это с помощью команды lsof:

[root@ivan ~]# ps aux | grep python | grep "http.server"root   20638 0.0 0.3 270144 13552 pts/2  S+  08:29  0:00 python3 -m http.server[root@ivan ~]# lsof -p 20638 | grep cwdpython3 20638 root cwd  DIR   253,1   4096 1843551 /root/test_dir_srv2

Также это можно сделать с помощью команды pwdx или с помощью директории proc:

[root@ivan ~]# pwdx 2063820638: /root/test_dir_srv2[root@ivan ~]# ls -l /proc/20638/cwdlrwxrwxrwx 1 root root 0 Aug 31 08:37 /proc/20638/cwd -> /root/test_dir_srv2

Такая директория действительно есть на сервере, и в ней лежит файл с именем test_file. В чём же дело? Иван погуглил и нашёл утилиту strace, с помощью которой можно смотреть, какие системные вызовы выполняет процесс (про strace, кстати, есть хорошая статья на Хабре, и даже не одна). Можно либо запускать новый процесс через strace, либо подключаться этой утилитой к уже запущенному процессу. Ване подходил второй вариант:

Вывод утилиты strace
[root@ivan ~]# strace -ff -p 20638strace: Process 20638 attachedrestart_syscall(<... resuming interrupted poll ...>) = 0poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 1 ([{fd=4, revents=POLLIN}])accept4(4, {sa_family=AF_INET, sin_port=htons(57530), sin_addr=inet_addr("127.0.0.1")}, [16], SOCK_CLOEXEC) = 5clone(child_stack=0x7f2beeb28fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2beeb299d0, tls=0x7f2beeb29700, child_tidptr=0x7f2beeb299d0) = 21062futex(0x11204d0, FUTEX_WAIT_PRIVATE, 0, NULLstrace: Process 21062 attached<unfinished ...>[pid 21062] set_robust_list(0x7f2beeb299e0, 24) = 0[pid 21062] futex(0x11204d0, FUTEX_WAKE_PRIVATE, 1) = 1[pid 20638] <... futex resumed> )    = 0[pid 20638] futex(0x921c9c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 27, {1598879772, 978949000}, ffffffff <unfinished ...>[pid 21062] futex(0x921c9c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x921c98, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1[pid 20638] <... futex resumed> )    = 0[pid 20638] futex(0x921cc8, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>[pid 21062] futex(0x921cc8, FUTEX_WAKE_PRIVATE, 1) = 1[pid 20638] <... futex resumed> )    = 0[pid 20638] futex(0x921cc8, FUTEX_WAKE_PRIVATE, 1) = 0[pid 20638] poll([{fd=4, events=POLLIN}], 1, 500 <unfinished ...>[pid 21062] recvfrom(5, "GET / HTTP/1.1\r\nConnection: upgr"..., 8192, 0, NULL, NULL) = 153[pid 21062] stat("/root/test_dir_srv/", 0x7f2beeb27350) = -1 ENOENT (No such file or directory)[pid 21062] open("/root/test_dir_srv/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)[pid 21062] write(2, "127.0.0.1 - - [31/Aug/2020 09:16"..., 70) = 70[pid 21062] write(2, "127.0.0.1 - - [31/Aug/2020 09:16"..., 60) = 60[pid 21062] sendto(5, "HTTP/1.0 404 File not found\r\nSer"..., 184, 0, NULL, 0) = 184[pid 21062] sendto(5, "<!DOCTYPE HTML PUBLIC \"-//W3C//D"..., 469, 0, NULL, 0) = 469[pid 21062] shutdown(5, SHUT_WR)    = 0[pid 21062] close(5)          = 0[pid 21062] madvise(0x7f2bee329000, 8368128, MADV_DONTNEED) = 0[pid 21062] exit(0)           = ?[pid 21062] +++ exited with 0 +++<... poll resumed> )          = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500^Cstrace: Process 20638 detached<detached ...>


Обычно вывод strace довольно объёмный (а может быть и очень большим), поэтому удобнее сразу перенаправлять его в файл и потом уже искать в нём нужные системные вызовы. В данном же случае можно сразу обнаружить, что сервис пытается открыть директорию /root/test_dir_srv/ кто-то переименовал её и не перезапустил после этого сервис, поэтому он возвращает 404.

Если сразу понятно, какие именно системные вызовы нужно посмотреть, можно использовать опцию -e:

[root@ivan ~]# strace -ff -e trace=open,stat -p 20638strace: Process 20638 attachedstrace: Process 21396 attached[pid 21396] stat("/root/test_dir_srv/", 0x7f2beeb27350) = -1 ENOENT (No such file or directory)[pid 21396] open("/root/test_dir_srv/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)[pid 21396] +++ exited with 0 +++^Cstrace: Process 20638 detached

Вывод: иногда можно немножко залезть под капот процессу, а помогает с этим strace. Так как эта утилита выводит все системные вызовы, которые использует процесс, то с её помощью также можно находить и сетевые проблемы (например, к какому хосту/порту пытается подключиться процесс), что делает её довольно универсальным инструментом дебага. Также существует похожая утилита ltrace.

Есть ли что-то ещё?


Ваня на этом не остановился и узнал, что есть GNU Project Debugger GDB. С его помощью можно залезть в процесс и даже немного модифицировать его. И Ваня решил попробовать обнаружить последнюю ошибку с помощью GDB. Он предположил, что раз сервис выводит содержимое директории, то можно попробовать поставить breakpoint на функции open() и посмотреть, что будет:
Вывод утилиты gdb
[root@ivan ~]# gdb -p 23998GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.el7Copyright (C) 2013 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.  Type "show copying"and "show warranty" for details.This GDB was configured as "x86_64-redhat-linux-gnu".For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>.Attaching to process 23998 <здесь много сообщений о загрузке символов и отсутствии debugging symbols...>...0x00007f2284c0b20d in poll () at ../sysdeps/unix/syscall-template.S:8181T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-34.el7.x86_64 libcom_err-1.42.9-13.el7.x86_64 libgcc-4.8.5-36.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 openssl-libs-1.0.2k-16.el7.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64(gdb) set follow-fork-mode child(gdb) b openBreakpoint 1 at 0x7f2284c06d20: open. (2 locations)(gdb) cContinuing.[New Thread 0x7f227a165700 (LWP 24030)][Switching to Thread 0x7f227a165700 (LWP 24030)]Breakpoint 1, open64 () at ../sysdeps/unix/syscall-template.S:8181T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)(gdb) n83T_PSEUDO_END (SYSCALL_SYMBOL)(gdb) n_io_FileIO___init___impl (opener=<optimized out>, closefd=<optimized out>, mode=<optimized out>, nameobj=0x7f227a68f6f0, self=0x7f227a68f6c0) at ./Modules/_io/fileio.c:381381                Py_END_ALLOW_THREADS(gdb) n379                self->fd = open(name, flags, 0666);(gdb) n381                Py_END_ALLOW_THREADS(gdb) print name$1 = 0x7f227a687c90 "/root/test_dir_srv/"(gdb) qA debugging session is active.Inferior 1 [process 23998] will be detached.Quit anyway? (y or n) yDetaching from program: /usr/local/bin/python3.7, process 23998[Inferior 1 (process 23998) detached]


После команды c (continue) Ваня в другой консоли запустил curl, попал в дебаггере в точку останова и стал выполнять эту программу (то есть сервис) по шагам. Как только он нашёл в коде open по какому-то пути name, он вывел значение этой переменной и увидел /root/test_dir_srv/.
GDB это мощный инструмент, и здесь описан простейший вариант его использования. Иногда он может помочь в воспроизведении каких-либо сложных кейсов (например, можно приостановить процесс в нужный момент и воспроизвести состояние гонки), также он помогает с чтением core dump файлов.

А что если Docker?


В один момент DevOps решили, что сервис теперь будет деплоиться Docker-контейнером, и нужно было провести ретест всех кейсов, которые нашёл Ваня. Ваня без проблем нагуглил следующее:

  1. Использовать tcpdump, strace и gdb можно и внутри контейнера, но нужно иметь ввиду Linux capabilities (есть статья, которая объясняет, почему strace не работал в контейнере без --cap-add=SYS_PTRACE).
  2. Можно использовать опцию --pid.

Но ему стало интересно, можно ли посмотреть весь трафик, идущий в контейнер (или из контейнера), прям с хоста. У tcpdump есть возможность выводить трафик какого-либо интерфейса (опция -i), каждому контейнеру соответствует один виртуальный интерфейс veth (это можно увидеть, например, через ifconfig или ip a), но как понять, какому контейнеру какой интерфейс соответствует? Если контейнер не использует host networking, то внутри него будет сетевой интерфейс eth0, через который он может общаться по сети с другими контейнерами и хостом. Остаётся лишь найти, ifindex какого интерфейса на хосте совпадает с iflink интерфейса eth0 контейнера (что это означает можно почитать здесь).

[root@ivan ~]# for f in `ls /sys/class/net/veth*/ifindex`; do echo $f; cat $f; done | grep -B 1 `docker exec test_service_container cat /sys/class/net/eth0/iflink` | head -1/sys/class/net/veth6c18dba/ifindex

Теперь можно запускать tcpdump для интерфейса veth6c18dba:

tcpdump -i veth6c18dba

Но есть способ проще: можно найти IP-адрес контейнера в его сети и слушать трафик на нём:

[root@ivan ~]# docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' test_service_container172.17.0.10[root@ivan ~]# tcpdump -i any host 172.17.0.10

Вывод: дебаг в Docker-контейнере это не страшно. Утилиты в нём работают, а для чтения логов можно использовать docker logs.

Выводы


Как ответственный инженер, Ваня решил кратко законспектировать новую для себя информацию во внутренней базе знаний. Вот что он написал:

  • Логи лучший друг человека. Если встречается неожиданное поведение сервиса и при этом он не пишет ничего в лог это повод попросить разработчиков добавить логов.
  • Иногда бывает, что локализовать ошибку надо, даже если в логах ничего нет. К счастью, в Linux есть много утилит, которые помогают с этим.
  • С дебагом любых сетевых коммуникаций помогает tcpdump. Он помогает видеть, какой трафик откуда и куда идёт на сервере.
  • Заглянуть внутрь процесса помогают утилиты strace, ltrace и gdb.
  • Всё это можно использовать, если сервис работает в Docker-контейнере.
  • Много информации о процессе есть в директориях /proc/PID. Например, в /proc/PID/fd находятся симлинки на все открытые процессом файлы.
  • Также помочь получить различную информацию о системе, файлах или процессах могут утилиты ps, ls, stat, lsof, ss, du, top, free, ip, ldconfig, ldd и прочие.

Надеюсь, вам была полезна эта история, и хотя бы однажды она поможет вам понять, в чём дело, когда вы будете что-то дебажить в Linux. Если Ваня что-то упустил, делитесь этим в комментариях!
Подробнее..

Цензура в интернете. Когда базовых мер недостаточно I2P

28.02.2021 12:13:00 | Автор: admin

В прошлой статье я рассказал, какие выкрутасы можно сделать одним только браузером. Нам потребуются эти знания далее

Жаркий август 2020 показал, что базовые меры это слишком мало и неэффективно. Нужно что-то большее

Выбирая решение, я ставил перед собой несколько целей:

  1. Решение должно быть открытым

  2. Решение должно быть бесплатным только так оно может стать массовым

  3. Решение должно быть децентрализованным не должно быть единой точки отказа

  4. Бомж-VPN. Хотелось иметь возможность соединиться с любым узлом сети забесплатно

  5. Бомж-хостинг. Следствие предыдущего пункта. Возможность выкатить тестовый ресурс забесплатно

VPN отвалился сразу: даже рабочий VPN умер. VPN требует централизованного внешнего сервера единая точка отказа. Наконец, VPN платный не назвал бы лично себя нищебродом, но это точно не массовый вариант

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

Я начал осваивать I2P. Идея мне показалась симпатичной. Особенно интересно, что сеть не просто выдержит резкий рост числа пользователей она от этого станет работать лишь надёжнее (но это не точно). На луркеочень вдохновляющее описание возможностей, а wikiспускает с небес на Землю и даёт понять, что I2P не серебряная пуля, и атаки по деанонимизации реальность. Сложно и дорого, но реально. Для сравнения, без I2P это как по паспорту представиться и приготовиться к обыску

Возможности, ограничения и болячки

Точно так же, как и в сети TOR, в сети I2P есть выходные ноды. Это значит, что через сеть I2P можно пролезть в обычный интернет. Однако следует понимать, что скорость работы оставляет желать лучшего потоковое видео через I2P смотреть так себе идея

I2P не ограничивает себя каким-то протоколом. Вместо этого сеть предоставляет среду передачи данных. Я пробрасывал через сеть I2P соединение с базой данных. Туннели I2P позволяют пробросить любой ресурс, таким образом сделав его доступным для использования любыми программами. Если кто-то не знаком с туннелями идея проста и состоит в том, чтобы для некоторого открытого порта на удалённом сервере открыть порт на своей машине, и в дальнейшем любой локальной программой подключаться к локальному порту, что точно умеет любая программа, а тонкостями переноса байтов на тот порт удалённой машины и обратно занимается уже туннелирующая программа (частный случай туннеля).

Следствия туннелей бомж-VPN и бомж-хостинг. Я счастлив я могу выкатить ресурс бесплатно. Я могу соединить 2 машины бесплатно. Любой другой участник сети может сделать всё то же самое бесплатно. Вкусно

Функционировать сеть сможет, даже если шаловливые ручки вновь потянутся к Большому Рубильнику белорусские реалии именно такие, онсуществует

Больным местом является изменение маршрутов (следовательно, dest hash). Но я надеюсь, что проблема решаема существует версия для Android, которая подразумевает переход между сетью оператора и разными точками доступа wifi, а в настройках роутера появился экспериментальный Laptop Mode

Ошибки и заблуждения

Я заметил несколько шаблонов заблуждений

Ой, мне по телевизору сказали, что в этом вашем i2p такое показывают! Это вообще законно?

Больше верьте слухам. Ничего там нет такого, чего нет в обычном интернете. I2P ставит своей целью среду передачи данных. Протоколы TCP и UDP, передают более чем 99% информации в интернете, включая незаконный контент. Давайте бороться с контентом, а не транспортом его доставки

Как интернет отключат обязательно установлю

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

Хорошо, я установил, запустил, что-то потыкал и выключил. Как только интернет выключат ух держите меня семеро! Включу I2P и всё у меня станет расчудесно!

Та же проблема. С высокой вероятностью, тебе не удастся найти вообще никого из тех, с кем ты ранее устанавливал соединение. Запусти I2P как службу пусть висит себе в фоне. Она есть не просит (ну кроме памяти). Только так ты встретишь час Ч в готовности

Я на минуточку. Туда и назад

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

Ну и совсем кошерная остановка службы I2P это в консоли роутера нажать кнопочку Shutdown / Выключить. Демон I2P остановися сам в худшем случае через 10 минут как только истекут уже установленные соединения с другими участниками сети i2p

Кнопки Restart / Перезапуск и Shutdown / Выключить находятся на скриншоте в нижнем правом углуКнопки Restart / Перезапуск и Shutdown / Выключить находятся на скриншоте в нижнем правом углу

Установка на desktop

Состоит из двух обязательных частей установки шлюза (inproxy) и настройки браузера (лайт или пожёстче выбираем сами на свой вкус). Важно выполнить оба этапа, по отдельности они не имеют смысла

Установка шлюза

Наоффициальном сайте проекта есть список загрузок можно взять оттуда

В этом же списке присутствует секция Пакеты для Debian/Ubuntu

После установки пытаемся открытьhttp://localhost:7657/ web-консоль роутера. Настоятельно рекомендую добавить страницу в закладки или даже закрепить (Pin Tab). Если страница открылась вы всё сделали правильно

Настройка браузера. Лайт

В данном случае мы исходим из предположения, что вы не делаете ничего плохого, и просто желаете получить доступ к информации, которая огорчила ваше правительство. А правительство, словно плаксивая девочка, склонно обижаться на любую информацию. Например, в России заблокирован linkedin. Жутко опасный и экстремистский ресурс, ага

В данном случае нас не пугают утечки информации. Например, сайт в сети i2p может запрашивать какой-нибудь jquery с CDN. Что такого в js-библиотеке, которую запрашивают миллионы, если не миллиарды раз в день?

Мы предполагаем, что не делаем ничего плохого, и нас не интересует сайт-приманка товарища майора Василия Мусорова с какой-то жестью, который загружает ресурсы напрямую в обход I2P или TOR по абсолютным ссылкам, выдавая ваш реальный IP-адрес. Оригинал изображения искать где-то тут: http://vasya-lozhkin.ru/pictures/. Я не нашёл =(Мы предполагаем, что не делаем ничего плохого, и нас не интересует сайт-приманка товарища майора Василия Мусорова с какой-то жестью, который загружает ресурсы напрямую в обход I2P или TOR по абсолютным ссылкам, выдавая ваш реальный IP-адрес. Оригинал изображения искать где-то тут: http://vasya-lozhkin.ru/pictures/. Я не нашёл =(

Для настройки нам потребуется дополнениеSmartProxy. Настройка производится в 2 простых шага необходимо добавить входной шлюз I2P в список proxy-серверов и создать правило проксирования

Добавляем входной шлюз I2P в список proxy-серверовДобавляем входной шлюз I2P в список proxy-серверовСоздаём правила проксирования для i2p-сайтовСоздаём правила проксирования для i2p-сайтов

Настройка браузера. Для любителей пожёстче

Паранойя может затребовать гарантий отсутствия утечек. Из наличия паранойи не следует, что мы кинемся смотреть упомянутый ранее сайт товарища майора Василия Мусорова. Настройка проводится в несколько простых шагов

У меня нет лишнего браузера в системе, чтобы полностью выделить его под I2P. Воспользуюсь уже установленным firefox. Следующий вариант работает в Linux:

FIREFOX_PROFILE="firefox-i2p"FIREFOX_HOME="${HOME}/${FIREFOX_PROFILE}"mkdir -p "$FIREFOX_HOME"env HOME="$FIREFOX_HOME" firefox

То есть идея проста: заставить firefox работать с полностью чистым профилем, который никак не повлияет на основной, и который мы сможем снести при первых же намёках на проблемы, как дедушке яичко. Какие бы мы туда дополнения ни ставили, какие бы настройки там не делали основным профилем можно будет продолжать пользоваться

У меня нет ни одной машины с Windows и MacOS. В комментариях, пожалуйста, расскажите, как сделать похожий финт ушами в Windows. А в MacOS этот фокус должен сработать, но я не тестировал

Открываем настройки и находим Network Settings / Настройки СетиОткрываем настройки и находим Network Settings / Настройки СетиИ указываем входной шлюз I2PИ указываем входной шлюз I2P

Установка на Android

Суть ровно та же, но инструменты немного другие

Установка шлюза

На всё той жестранице загрузок есть секция Android

Секция загрузок для AndroidСекция загрузок для Android

Настройка браузера. Лайт

Находим в менеджере дополнений FoxyProxy и устанавливаемНаходим в менеджере дополнений FoxyProxy и устанавливаемПереходим в его настройки, нажимаем ДобавитьПереходим в его настройки, нажимаем ДобавитьУказываем адрес шлюза, листаем вниз и жмём СохранитьУказываем адрес шлюза, листаем вниз и жмём СохранитьИ добавляем шаблон для всего домена i2pИ добавляем шаблон для всего домена i2pВ настройках FoxyProxy убеждаемся, что он включенВ настройках FoxyProxy убеждаемся, что он включен

Рецепты по настройке

Я расскажу про несколько опциональных шагов

DNS-over-HTTPS

Для тех, что не читалпредыдущую статью: необходимо добавитьi2p иonion в исключения. Иначе браузер будет пытаться резолвить эти домены на Cloudflare с предсказуемым результатом

I2P + uBlock Origin

Мы умеем учиться на ошибках, поэтому добавим в исключения зоны i2p и onion, таким образом полностью отключив блокировщик рекламы для всех ресурсов i2p и onion

Открываем настройки uBlock OriginОткрываем настройки uBlock OriginДобавляем в uBlock Origin исключения для доменов i2p и onionДобавляем в uBlock Origin исключения для доменов i2p и onion

Стало лучше, чем было, но не идеально теряется контроль над загрузкой стороннего контента (3rd party). Хотелось бы только отключить резолв имён i2p и onion

Дополнительные подписки

В список подписок есть смысл добавить адреса:

  1. http://identiguy.i2p/hosts.txt

  2. http://inr.i2p/export/alive-hosts.txt

  3. http://stats.i2p/cgi-bin/newhosts.txt

Покорми java памятью

Входной шлюз I2P написан на языке java. По умолчанию он стартует с ограничением в 128M. Этого хватит для знакомства и неспешного погружения в дивный новый мир невидимого интернета. Больше всего памяти потребляет компонент NetDB база данных о других хостах сети I2P. Чем их больше известно, тем выше надёжность и тем выше вероятность, что в час Ч, когда интернет снова сдохнет, Вам таки удастся найти лазейку доступный хост из списка известных. Правда, гарантий никаких

В случае Ubuntu/Debian:

sudo dpkg-reconfigure i2p

Как это сделать для Windows я не знаю и очень надеюсь на комментарии

Когда нельзя открыть порт меньше 1024, но очень хочется, то можно

Очень спорный рецепт. В общем случае, так делать не надо. Но если очень хочется, то можно. Я проделал это для прощупывания возможностей I2P. То есть just for fun

Приключения начались с вопроса так где же java?

which java | xargs file --mime-type/usr/bin/java: inode/symlink

Окей

which java | xargs readlink | xargs file --mime-type/etc/alternatives/java: inode/symlink

Больше симлинков богу симлинков!

which java | xargs readlink | xargs readlink | xargs file --mime-type/usr/lib/jvm/java-11-openjdk-amd64/bin/java: application/x-pie-executable

Следует понимать, что конфигурация у меня может не совпадать с конфигурацией у Вас. Идея проста добавлять в середину секцию xargs readlink до наступления просветления пока file не скажет application/x-pie-executable. Как только java нашлась из получившейся команды удаляем 2 последних слова file --mime-type, например, нажав ^W дважды, и вместо этого добавляем setcap 'cap_net_bind_service=+ep':

which java | xargs readlink | xargs readlink | xargs setcap 'cap_net_bind_service=+ep'

Возможно, потребуется добавить также возможность открытия сырого сокета setcap 'cap_net_raw=+ep':

which java | xargs readlink | xargs readlink | xargs setcap 'cap_net_raw=+ep'

Но в следующий раз я просто разверну docker с nginx

А что ещё там есть?

Очень рекомендую почитатьрусскоязычную wiki и полистать спискиidentiguy

Внезапно web-версия telegram. Правда, я понятия не имею, знает ли про это зеркало администрация telegram. Впрочем, через выходную ноду можно достучатсья и до оригиналаВнезапно web-версия telegram. Правда, я понятия не имею, знает ли про это зеркало администрация telegram. Впрочем, через выходную ноду можно достучатсья и до оригинала

А ещё естьтелеграмовские MTProto прокси. Идея сводится к созданию туннелей на указанные i2p-хосты. Инструкция на сайте

Ещё есть торренты и почта. Ничего из этого я ещё не пробовал использовать

Находилфлибусту иebooks.i2p последний выглядит вообще дорого-богато

Вместо заключения

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

Я ни слова не сказал проi2pd. Проект достоин внимания: он производительнее и при меньшем потреблении ресурсов. Пока что у меня нет экспертизы

Подробнее..

VMware SD-WAN обзор решения

03.04.2021 18:14:06 | Автор: admin

Этим материалом мы начинаем цикл статей о решении VMware SD-WAN. Сегодня поговорим о том, какие рыночные предпосылки сформировали его появление, какие задачи решает SD-WAN и каковы технические особенности решения VMware.

Появление SD-WAN

До облачной революции, когда деревья были большими, а про облака говорили мало и редко, для размещения приложений большинство компаний использовали локальные ЦОДы. Доступ для сотрудников из удаленных офисов предоставлялся через выделенные каналы связи MPLS. При таком подключении большинство пользователей из филиалов прямого пути в большую сеть не имели и выходили за пределы приватной сети через центральный офис, который мог находиться за тысячи километров от филиала и пользователя.

Чуть позже компании, наконец, распробовали облачные технологии. Бизнес стал размещать свои приложения в облаках, а доступ к ним организовывать через интернет, без использования выделенных каналов. Требования к пропускной полосе и скорости обмена информацией постоянно росли. Если со старыми корпоративными приложениями, не относящимися к медиа или ПО реального времени, традиционный подход еще работал, то по мере появления видеохостингов и сервисов видеосвязи, взрывной рост популярности которых пришелся на начало 2010-х, стало очевидно: нужно что-то менять.

Выделенные MPLS-каналы со своей низкой пропускной способностью и высокой стоимостью (за 1 Мбит на MPLS приходилось платить иногда в десятки раз больше, чем за такой же канал в интернет) банально перестали отвечать требованиям рынка.

Казалось бы, почему не перейти на интернет? Это дешево и сердито, а скорость доступа к облакам выше. Ответ прост: в случае с интернетом невозможно гарантировать качество сервиса. Да, MPLS дорогой и неудобный, но провайдеры как минимум на уровне контракта гарантируют качество. А в случае с интернетом обещать, что приложения, физически находящиеся бог знает где, через конкретного провайдера будут хорошо работать, нельзя. Сами сервисы находятся вне зоны ответственности провайдера.

Иными словами, те, кто отвечают за канал связи, не отвечают за приложения, и наоборот. Заказчик оказывается между Сциллой и Харибдой.

Решения SD-WAN долгое время оставались уделом стартапов. В стадию зрелости технология перешла всего несколько лет назад, когда крупные компании начали активно приобретать специализированные проекты. VMware выкупила стартап Velocloud, который делил первое место на рынке с аналогичным проектом Viptela, примерно в то же время купленным Cisco. Еще пару лет заняла консолидация: одни стартапы разорялись не всем удавалось сохранить нужные темпы роста и найти свое место на рынке, наиболее перспективные и успешные переходили под крыло крупных вендоров.

Чтобы нарастить конкурентные преимущества, каждой компании пришлось найти собственную уникальную нишу. Решение Velocloud создавалось для того, чтобы бизнес мог получать надежный и качественный доступ к приложениям независимо от того, где они находятся: в локальном дата-центре или в облаке, доступ в которое осуществляется через интернет. Спойлер: реализовать это удалось благодаря архитектурному компоненту решения SD-WAN Cloud Gateways. Идея состоит в том, что облачные технологии можно использовать и в мире сетевых подключений.

Как работает SD-WAN

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

Этот неудобный подход просуществовал вплоть до появления SDN. Технология программно-определяемых сетей позволила централизовать control plane и management plane, что дало существенный выигрыш в плане управляемости и масштабируемости сети. Стало возможным без труда управлять распределенной сетью из сотен и даже тысяч устройств, выросла скорость внесения изменений, а также появилась возможность более интеллектуальной обработки потоков данных.

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

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

Далее мы подробно рассмотрим все компоненты VMware SD-WAN и поговорим о каждом из них отдельно.

Компоненты решения

VMware SD-WAN Orchestrator

SD-WAN Orchestrator это облачный портал управления, мониторинга и диагностики сети. С его помощью можно буквально в один клик запустить виртуальные сетевые службы в филиале, облаке или в корпоративном ЦОДе. Фактически, это веб-портал управления сетью SD-WAN, который можно получить как SaaS или развернуть в локальном ЦОД.

Архитектура оркестратора позволяет легко масштабировать сеть с нескольких узлов до нескольких тысяч. Управление на основе политик и профилей-шаблонов позволяет за минуты распространять изменения в сети. Этим функционал оркестратора не ограничивается.

  • Мониторинг. Данные о состоянии узлов сети, SLA по каналам, сетевая активность по приложениям и клиентам, а также продвинутая система построения отчетов

  • Zero-Touch Provisioning (ZTP). Активация оконечного устройства в филиале не требует выезда отдельного специалиста на площадку. Весь процесс укладывается в несколько простых шагов. Сотрудник в удаленном офисе подключает к устройству все кабели и включает его. Через интерфейс оркестратора создается новый Edge и высылается email со ссылкой для активации. Там зашиты нужные параметры для настройки WAN-интерфейса оборудования. Сотрудник в филиале, подключившись через провод или WiFi с планшета, переходит по этой ссылке, а устройство получает автоматически связность с оркестратором, вне зависимости от типа подключения к интернету.

  • Диагностика сети. В панели управления можно посмотреть состояние протоколов маршрутизации, портов, таблиц ARP и NAT, запустить Ping или Traceroute и многое другое без необходимости подключения к устройствам через CLI/SSH.

  • Журнал событий. Изменения и уведомления со всех устройств доступны для поиска и просмотра на SD-WAN Orchestrator.

  • Автоматизация через API. SD-WAN Orchestrator предоставляет REST API, примеры использования можно посмотреть на SD-WAN Dev Center.

Посмотрим, как это выглядит.

SD-WAN Dashboard общий вид на всю сеть:

Список филиалов и их расположение на карте:

Статистика по приложениям и клиентам:

Информация о качестве каналов Quality of Experience:

Детальные характеристики каналов:

VMware SD-WAN Gateway

SD-WAN Gateways это сетевые шлюзы, развернутые в высоконадежных ЦОД по всему миру. В первую очередь, они выполняют функцию Control Plane, но в зависимости от задачи могут брать на себя сразу обе плоскости и control plane, и data plane. Эти шлюзы позволяют соединить между собой разрозненные офисы и обеспечивают оптимальный путь от филиала к данным и приложениям в ЦОД и облаках. Потребность в установке мощных концентраторов или устройств координации непосредственно в филиалах отпадает.

На уровне Control Plane обеспечивается и обмен маршрутной информацией между филиалами, так как Gateway выполняет роль рефлектора маршрутов. Филиалы получают обновления маршрутов от Control Plane, благодаря чему настраивать протоколы маршрутизации между устройствами Edge не требуется.

Ещё одна важная роль SD-WAN Gateway помощь в определении характеристик каналов связи. При активации устройства Edge выполняется подключение к Gateway и замер полосы пропускания канала, также автоматически определяется MTU.

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

При этом приложения, с которыми работают пользователи, могут быть развернуты как в облаке провайдера, так и на собственной площадке клиента. Если инфраструктура компании филиалы, офисы распределена географически, каждый офис будет подключаться к ближайшему SD-WAN Gateway.

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

Хороший пример использование облачных сервисов совместной работы, например, Microsoft Office 365, Dropbox, Zoom, Skype for business и других. В месте их фактического расположения установить SD-WAN Edge невозможно,но получить преимущества SD-WAN Overlay (подробнее в разделе о протоколе VCMP) нужно. SD-WAN Gateway выполняет функцию шлюза в большой интернет с балансировкой между каналами, компенсацией ошибок и выбором наиболее оптимального канала для передачи пакетов конкретного приложения.

VMware SD-WAN Edges

VMware SD-WAN Edge это физическое или виртуальное устройство с функциями безопасности. Фактически, это маршрутизатор, который может как заменить уже размещенные в филиалах устройства, так и работать с ними в тандеме. Он поддерживает функции сетевого шлюза, Site-to-Site VPN, DHCP-сервера, NAT и файрвола, а также различные протоколы маршрутизации для интеграции с физической сетью.

SD-WAN Edge в виртуальном исполнении подойдет тем, кто планирует использовать концепцию Software-Defined Branch или обеспечивать доступ к своим приложениям в ЦОД через SD-WAN. Виртуальный Edge в ЦОД подходит как в качестве связующего звена ресурсов ЦОД и удаленных площадок, так и в роли хаба для агрегации и распределения трафика внутри сети SD-WAN.

SD-WAN Edge поддерживает основные варианты резервирования есть возможность объединения в отказоустойчивую пару или подключение по протоколу VRRP.

И если компоненты решения руки, ноги и голова технологии VMware SD-WAN, то его сердце технология DMPO. Именно она и позволяет реализовать уникальные фишки по обработке сетевых пакетов при передаче данных (между филиалами и ЦОД, филиалами и облаками) и обеспечивает высокое качество связи. Поговорим о ней подробнее.

Технология DMPO

Технология DMPO (Dynamic Multi-Path Optimization) позволяет нам за счет гибкого управления трафиком на уровне приложений агрегировать потоки и обеспечивать высокое качество связи. DMPO работает на уровне отдельных пакетов, однако учитывает, к каким приложениям эти пакеты относятся. Транзакционным приложениям, таким как веб-сайты, инструменты передачи файлов, не принципиально, придет пакет вовремя или чуть позже, главное, чтобы он вообще дошел. А приложениям реального времени (стриминговые сервисы, приложения для голосовых вызовов и т.п.) очередность пакетов важна. Из-за мелких неполадок может рассыпаться картинка на экране или собеседник не расслышит слово. Поэтому важно, чтобы SD-WAN устройства понимали, что это за приложение. В этом помогает движок распознавания приложений (Deep Application Recognition), работающий на каждом устройстве SD-WAN Edge.

Приложений существует огромное множество, 3000+ из них есть во встроенной базе DPI VMware SD-WAN. Кроме того, можно добавить и кастомные (самописные) сигнатуры, если вдруг какого-то приложения не хватает. Посмотрим, какие функции выполняет DMPO.

Непрерывный мониторинг качества каналов

Для мониторинга состояния WAN-каналов в реальном времени стандартные сетевые технологии вроде BFD или ICMP Probes не совсем подходят, т.к. тестовые пакеты отличаются от пользовательского трафика (другие классы DSCP, другой размер пакетов), а интервал проб слишком высок, чтобы достоверно и быстро определить ухудшение качества. Например, даже при замерах BFD или ICMP каждую секунду за время между этими замерами у обычного пользователя с ноутбуком передается 200+ пакетов (проверьте сами, сняв дамп трафика). Чтобы зафиксировать уровень потери в 2%, потребуется не менее 50 BFD пакетов (50 с). Если использовать более агрессивные значения, например, 100 мс, все равно потребуется не менее 5 секунд, чтобы обнаружить потери в 2% на канале. За это время тысячи пакетов с пользовательскими данными могут быть потеряны.

Поэтому в решении Velocloud используется собственный протокол инкапсуляции Velocloud Multipath Protocol (VCMP), который добавляет к каждому пакету специальные заголовки, помогающие отследить время его прохождения (Latency, Jitter) и факт доставки. Это позволяет обнаружить ухудшение качества каналов практически мгновенно, а затем перенаправить пакеты на канал с лучшими показателями незаметно для пользователя.

За точное время в сети отвечает Control Plane уже известные нам SD-WAN Gateways. Устройства SD-WAN Edge синхронизируют свое время с центром управления сетью. Таким образом можно гарантировать, что все временные метки будут достоверны. В стандартных сетевых протоколах такие возможности отсутствуют.

Состояние каналов отслеживается даже в том случае, если пользовательского трафика на данный момент нет. Ведь когда этот трафик появится, его нужно сразу же отправить по оптимальному пути. Для этого устройства SD-WAN Edge обмениваются служебными пакетами VCMP, только без User Payload, каждые 100 или 500 мс. Как только появляется пользовательский трафик, система снова начинает отслеживать SLA для каждого пакета.

Динамическая балансировка трафика и агрегация каналов

DMPO позволяет определять, какие приложения используют сеть, при помощи политик манипулировать поведением SD-WAN и настраивать приоритеты.

Решение VMware умеет автоматически (за счет работы overlay-протокола VCMP) выбирать наилучший способ обработки и доставки трафика приложений. К примеру, если конкретному приложению требуется ускорить передачу данных, то есть агрегировать несколько каналов, умное SD-WAN устройство начнет передавать данные сразу по нескольким путям. Для балансировки используются все доступные подключения.

В ряде случаев стандартная балансировка не имеет смысла, они сильно отличаются между собой по характеристикам: на одном задержка 5 мс, на другом 100). Соответственно, балансировать трафик между ними бесполезно. Однако если быстрый канал окажется забит под завязку и на нем скопится большая очередь из пакетов, система определит, что каналы сравнялись по времени доставки пакетов. В этом случае в рассылке пакетов будут задействованы оба канала таким образом, чтобы пакеты по обоим доходили до точки назначение в одно и то же время. На принимающей стороне пакеты выстраиваются в порядке очереди так, чтобы клиенту или серверу за пределами сети SD-WAN не приходилось пересобирать их в требуемой последовательности. Соответственно, еще одна из функций, которую способно обеспечить устройство SD-WAN автоматический реордеринг.

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

Из-за особенностей каналов связи трафик между точками А и В может идти неравномерно: в одну сторону с задержкой 10 мс, обратно 20 мс. В то же самое время канал работает наоборот: туда 20 мс, сюда 10 мс задержки. По сети VMware SD-WAN такая сессия будет передаваться по обоим каналам сразу, в одну сторону по каналу с задержкой 10 мс, и так же обратно по каналу с наилучшими характеристиками.

За счет того, что каждый пакет обрабатывается индивидуально алгоритмами DMPO, система выбирает наилучший путь для каждого пакета автоматически, принимая решения в реальном времени.

Раньше администраторам приходилось вручную определять эту логику, либо настраивать схемы вида: каждые N секунд проверяем, какой канал и в какую сторону работает лучше и перестраиваемся при необходимости. Реализовать такую схему без разрывов пользовательских сессий практически невозможно. Ценность SD-WAN заключается в том, что вся эта запутанная логика делегирована алгоритмам они быстрее и точнее, чем даже самые сложные проверочные скрипты. Логика VMware SD-WAN работает на разных типах сессий и на разных транспортных протоколах, никак не нарушая логику работы TCP/IP.

Технологии корректировки ошибок

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

Получатель: Так, к нам идут пакеты. Первый, второй, третий, пятый Стоп. Почему пятый? Требую выслать мне пакет 4 как можно скорее! Прием!

Отправитель: Посмотрим, к какому приложению относился этот ваш пакет. Ага, вот оно! Высылаю компенсацию, подтвердите получение!

В случае транзакционного приложения устройству-отправителю будет достаточно найти в буфере нужный пакет и повторить отправку так работает технология NACK (Negative Acknowledgement). В устройствах SD-WAN используется серверная память гораздо большего объема, чем в обычных маршрутизаторах. Самая младшая модель имеет на борту 4 Гб, на старших 32 Гб и выше. Это позволяет держать буфер данных и по необходимости досылать потерявшиеся пакеты.

С realtime-приложениями ситуация обстоит иначе. Повторно отправлять пакеты не имеет смысла, важно предотвратить потери в будущем. Поэтому устройство-отправитель включает упреждающую коррекцию ошибок (Forward Error Correction, FEC), и каждый пакет начинает передаваться в двух экземплярах. Таким образом повышается вероятность успешной доставки пакетов, а лишние автоматически отбрасываются на принимающей стороне. На практике это позволяет использовать телефонию и видеоконференции на каналах с потерями до 30-40%.

Под капотом у провайдера

Некоторые компании пытаются внедрять SD-WAN самостоятельно, что приводит к необходимости решать множество не относящихся к сетевым технологиям задач (проектирование и развертывание управляющих компонентов, резервирование, масштабирование и дальнейшая поддержка, защита от атак, обеспечение доступности и т.д.). Согласно мировому опыту, большинство компаний все же выбирают SD-WAN как услугу от облачного провайдера или оператора связи. Давайте посмотрим, в чем плюсы использования SD-WAN от провайдера.

Разделение зон ответственности

Первая задача, с которой столкнется компания при самостоятельном внедрении построение облачной инфраструктуры SD-WAN: деплой контроллеров, виртуальных машин, выделение ресурсов, администрирование и многое другое. Построение такой инфраструктуры повлечет за собой значительные расходы в виде выделения или покупки дополнительных серверов и ПО, а также обеспечения условий Disaster Recovery. Эти сложности и расходы особенно трудно обосновать при постепенном внедрении SD-WAN. Во-вторых, для построения надежной отказоустойчивой сетевой связности требуется детально проработать целевую схему подключения, определить движение потоков данных, настроить политики безопасности.

Когда вы обращаетесь к провайдеру, все эти задачи ложатся на него. Он обеспечивает инфраструктуру, круглосуточный мониторинг, администрирование сети и защищенных распределенных ЦОД, уровень доступности и выполнение SLA. Провайдер поможет выбрать оптимальное оборудование и даст рекомендации по модернизации сети, чтобы она соответствовала всем требованиям качества и надежности. При этом клиенту остается только запросить доступ к облачному порталу управления сетью и создать учетные записи для администраторов. На любые вопросы по использованию услуги и настройке сервисов SD-WAN поможет ответить круглосуточная русскоязычная техническая поддержка.

Оркестратор и сетевые шлюзы находятся в зоне ответственности провайдера и разворачиваются на его инфраструктуре. Заказчику понадобится только установить на своей стороне Edge. Арендовать его можно прямо у провайдера при необходимости он поможет и с установкой.

Распределенная инфраструктура провайдера

Общая инфраструктура ИТ-ГРАД и #CloudMTS насчитывает 10 ЦОД в СНГ и множество точек присутствия по всему миру. Где бы ни находился филиал, он будет подключен к ближайшему SD-WAN Gateway, что позволит минимизировать задержки и оптимизировать доступ к любым приложениям в локальных ЦОД и любых облаках. Наличие распределенной инфраструктуры также позволяет обеспечивать георезервирование для сети SD-WAN любого масштаба.

Инфраструктура ИТ-ГРАД и #CloudMTS на территории РФ

В каждом ЦОД резервируются каналы, обеспечивается высокопроизводительная связность шлюзов SD-WAN с внешним миром. Дата-центры подключены к глобальной опорно-магистральной сети МТС, которая обеспечивает доступ к мировым публичным точкам обмена трафиком DE-CIX (Франкфурт), AMS-IX (Амстердам), HK-IX (Гонконг), LINX (Лондон), Equinix, NY-IX и т.д.

Кроме того, в распоряжении наших заказчиков:

  • PNI (Private Network Interconnect) с гиперскейлерами и крупными генераторами трафика. Среди них Amazon AWS, Microsoft, Google Cloud, Apple, Facebook, Valve, Twitch, Netflix, Twitter и прочие.

  • CDN-сети: Akamai, Google Cash и Google CDN, Cloudflare, Gcore labs, Microsoft и прочие.

Интеграция с IaaS и другими сервисами

Использование SD-WAN позволяет получить надежный доступ к сервисам, расположенными в инфраструктуре облачного провайдера. Какие преимущества это дает:

  • VDI, Skype for Business компенсация ошибок, умная балансировка пакетов между всеми каналами, подключенными к площадке. Использование решения обеспечивает гарантированное качество для сервисов реального времени за счет приоритезации на уровне приложений и компенсации ошибок на каналах.

  • Резервное копирование SD-WAN позволяет наладить максимально быструю и надежную транспортировку бэкапов по сети (с агрегацией каналов и обеспечением отказоустойчивости) по всем доступным каналам до облака.

  • S3 хранилище, облачный диск при использовании сервисов блочного, объектного и файлового хранилищ подключение по SD-WAN позволяет передавать большие файлы на максимальных скоростях. Это достигается за счет отсутствия ретрансмитов при передаче данных и агрегирования каналов связи, подключенных к устройству SD-WAN.

  • GPU Super Cloud высокоскоростная передача больших объемов данных для обработки в облачной среде.

Все чаще наши клиенты для подключения своих офисов к виртуальным дата-центрам ИТ-ГРАД и #CloudMTS вместо выделенных каналов выбирают SD-WAN и интернет-каналы. Клиенты, уже использующие выделенные каналы, применяют SD-WAN для агрегации существующих каналов, многократно повышая производительность и надежность подключения к облаку.

Будем рады пообщаться с вами в комментариях! В следующей статье мы проведем тестирование сервиса и на практике посмотрим, какие преимущества дают технология DMPO и протокол VCMP.

Подробнее..

Перевод Завершен перевод систематизированного обзора литературы по военным SDN-сетям

04.05.2021 08:16:25 | Автор: admin

В марте этого года я анонсировал перевод этого обзора. Сегодня публикую результат, получилось 70 страниц.

Традиционная просьба: прошу сообщать о замеченных огрехах, они наверняка есть, так как документ переводился и верстался в одно лицо. Обзор оформлен в виде pdf-документа, линк для скачивания: https://vk.cc/c1BQwV

Всем приятного чтения!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru