Туннелирование

Недавно меня попросили разобраться в настройке L2 туннеля для моста между двумя удалёнными локальными сетями, и я был поражён, насколько мало удобных решений мне удалось найти. Раньше я не интересовался этой темой и наивно полагал, что любой адекватный VPN-протокол умеет ловить широковещательные пакеты и пересылать их по обычному L3 туннелю. К сожалению, доступных из коробки универсальных решений нет. Есть несколько протоколов и инструментов для них, большинство из которых работает в очень ограниченных условиях или вовсе объявлено deprecated. Самым приятным вариантом я поделюсь дальше.

Почему именно L2?

Этим вопросом я задался в первую очередь: я довольно редко работаю с сетевой периферией, и мне казалось что довольно давно уже всё оборудование умеет ходить по L3. Как бы не так: кому-то нужен доступ к офисным принтерам, кому-то к видеорегистраторам, а кто-то просто хочет зарубиться с другом в LAN-дуэли не выходя из дома, разумеется. Также очень привлекательной выглядит идея общих/сетевых папок в офисе, доступных из дома, особенно в период повальной удалёнки.

При этом среди разработчиков VPN-клиентов L2-бриджи почему-то считаются чем-то вроде странного каприза одного-двух процентов пользователей, который по большому счёту никому не нужен. Совсем иначе обстоят дела в промышленных сетях, где много устаревшего или плохо совместимого оборудования, и концепция L2VPN (представленная кучей других аббревиатур) реализована на уровне сети и оборудования провайдера.

Технологии

Их много, и они все работают со странностями и ограничениями:

• Например, протокол Layer 2 Tunneling Protocol (L2TP) должен, судя по названию, обеспечивать поддержку OSI L2 и в том числе проброс broadcast'a. Но нет, общепринятая связка L2TP + IPsec не позволяет бриджевать сети на уровне L2!
• PPTP стал мемом из-за крупных уязвимостей, сейчас кое-как починен, но к L2 уже не имеет отношения.
• MPLS жутко запутанный промышленный протокол на основе меток. Изучить его сложно, а поднять можно только на специализированном железе или RouterOS (с ограничениями, куда ж без них).
• PPPoE и феерический PPPoEoE тоже работают, но на проприетарных железках. Режим PPPoE вообще есть на многих роутерах, но как его правильно готовить известно по большей части только на фирменном оборудовании типа Cisco.
• EoIP должен быть стать тем самым L2VPN made right, но он тоже работает только на микротиках, что существенно сужает круг применения. Как и PPTP, использует GRE, не проходит через NAT.

И тут я с удивлением обнаружил, что настоящий Ethernet Bridging умеет OpenVPN!

Мы часто пользуемся личным или рабочим VPNом, у многих он вообще включён на постоянной основе для обхода блокировок (хотя эта тенденция идёт на спад после снятия блокировки Telegram). В своих рабочих задачах я тоже постоянно пользуюсь удаленными хостами для разработки, и почти всегда использую OpenVPN. Долгое время я не понимал, зачем нужна связка OpenVPN Access Server + OpenVPN Connect на клиенте. Для моих задач мне всегда хватало классической версии с ручной правкой конфигов, и выделенные админки и GUI казались неуместными в стройном тонком клиенте. Но оказалось, что для настройки бриджа интерфейс гораздо удобнее чем простыни конфигов в терминале, хотя и с ним не всё идеально.

Настройка

Дело в том, что Access Server (AS) выходил как платный и довольно дорогой продукт, поэтому в него старательно напихали всевозможных плюшек, лишь бы купили. Таким образом в веб-админке появился подпункт меню, позволяющий выбрать режим сети (L2 bridging/L3 routing), а через какое-то время тихонько был оттуда выпилен по всё той же причине это никому не нужно. Тем не менее, сам функционал бриджинга и соответствующие скрипты не удаляли и их по-прежнему можно настроить.

Установка

Нам потребуется сервер или виртуальная машина. Образ для неё находится на странице загрузки, а мы будем дальше разбирать кейс с установкой на сервер под Ubuntu 18.04:

apt update && apt -y install ca-certificates wget net-tools gnupgwget -qO - https://as-repository.openvpn.net/as-repo-public.gpg | apt-key add -echo "deb http://as-repository.openvpn.net/as/debian bionic main">/etc/apt/sources.list.d/openvpn-as-repo.listapt update && apt -y install openvpn-as

После установки сервер поднимется самостоятельно, вы увидите такое сообщение:

+++++++++++++++++++++++++++++++++++++++++++++++Access Server 2.8.4 has been successfully installed in /usr/local/openvpn_asConfiguration log file has been written to /usr/local/openvpn_as/init.logAccess Server Web UIs are available here:Admin  UI: https://185.209.31.165:943/adminClient UI: https://185.209.31.165:943/+++++++++++++++++++++++++++++++++++++++++++++++

Сразу нужно указать пароль для админской учётки:

passwd openvpn

Затем можно открывать админку в браузере (на :943/admin, как указано выше), логиниться под пользователем openvpn с указанным паролем и настраивать сервер.



AS бесплатна для использования двумя пользователями, дальше можно добавлять только за $18/месяц за одного пользователя, так что лучше сразу спроектировать свои процессы под использование туннеля двумя клиентами.

Возвращаем бриджинг

cd /usr/local/openvpn_as/scripts./sacli --key "von.general.osi_layer" --value "2" ConfigPut./sacli start

Если всё прошло успешно, в выведенном json'е будет такое:

{ "errors": {}, "last_restarted": "Thu Jul  2 00:07:37 2020", "service_status": {   "api": "on",   "auth": "on",   "bridge": "on",        ...    }}

В админке статус OSI Layer: 3 (routing/NAT) поменяется на 2 (bridging)

NB: в последних версиях может оставаться информация о L3 при включённом bridge. Почему не разбирался, безопасные в этом плане версии около 2.4

Собственно на этом ноу-хау заканчивается, дальше вам нужно просто настроить под себя сервер, завести второго пользователя через тот же веб-интерфейс и залогиниться на пользовательскую страницу на 943 порту (без /admin). Там будут ссылки на скачивание клиентов OpenVPN Connect под все платформы с запечённым конфигом для подключения (кроме мобильных приложений, там придется вбить адрес вручную, а дальше всё само установится).



После успешного подключения и бриджевания клиентов, будет доступен L2-туннель с TCP/UDP трафиком. Клиенты могут выступать натом для внутренней сети, это всё тоже настраивается в админке.

В современных сетях с виртуализацией и автоматизацией широкое применение получило туннелирование трафика. Однако, туннелирование ориентировано на построение сети и обеспечение надежной передачи данных, а вопросы информационной безопасности и мониторинга обычно остаются за скобками. Проблема невидимости туннелированного трафика для систем информационной безопасности давно известная проблема уже в 2011 году было опубликовано RFC 6169 Security Concerns with IP Tunneling, указывающее на потенциальные риски применения туннелей. Непосредственно средства DPI не отстают от инфраструктуры и уже давно разбирают туннели и смотрят пользовательский трафик (когда это в целом технически возможно), однако, остается узкое место передача данных из инфраструктуры на эти системы.

Туннелирование и передача трафика в системы мониторинга и информаицонной безопасности

GTP, GRE, L2TP, PPPoE, VXLAN и другие аббревиатуры туннелей знакомы любому сетевому инженеру. Туннелирование трафика позволяет:

• Обеспечить управление потоками данных за счёт построения сети на 3 уровне модели OSI
• Связывать удаленные офисы в единую сеть с общими ресурсами
• Упрощать администрирование сети за счёт разделения на уровень инфраструктуры и уровень пользователей
• Строить единые сети на базе различных технологий
• Обеспечивать мобильность пользователей (мобильные сети, миграция виртуальных машин в дата-центрах)

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

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

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

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

Чаще всего применяется комбинация из пассивных оптических ответвителей и брокеров сетевых пакетов.



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

Фильтрация и классификация туннелированного трафика

Без возможности анализа брокером сетевых пакетов вложенных заголовков туннелированных пакетов бессмысленно говорить об оптимизации средств DPI. Фильтрация и классификация, позволяющие снизить нагрузку на системы DPI и уменьшить их количество, должны работать именно по полям пользовательского трафика (вложенных заголовков). Иначе отделить IP-адреса конкретных пользователей, требуемые протоколы или шифрованный трафик невозможно по внешним полям это будет просто туннель. Попытка очистить трафик на системы DPI от нецелевого по внешним полям только создаст дыру в безопасности целевой трафик проскользнет мимо информационной безопасности и мониторинга в туннеле.



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

Балансировка туннелированного трафика

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



Возьмём 2 сессии (AB-ВА и CD-DC) и передадим их через туннелированные каналы T1, T2 и T3. Допустим, речь идёт об абонентах мобильного оператора, гуляющих между базовыми станциями. Пакеты этих сессий окажутся в разных туннелях и при попадании туннелированного трафика на брокер сетевых пакетов есть 2 варианта их балансировки с сохранением целостности сессий:

1. Балансировка по внешним заголовкам. Фактически брокер сетевых пакетов при этом разделит разные туннели между системами DPI: Т1 и Т3 в DPI 1, а Т2 в DPI 2. При этом пакеты запросов (AB) информационного потока AB-BA, инкапсулированные в туннели Т1 и Т2 для обеспечения мобильности абонента, оказываются в разных системах DPI, а пакеты ответов (BA) в туннелях Т2 и Т3, соответственно, попадут в DPI 1 и DPI 2. Аналогичная ситуация произойдет и с информационным потоком CD-DC. Большинство систем DPI для корректной работы требуют все данные информационного обмена. Декапсулируя трафик, каждая из систем DPI увидит обрывки информационного обмена, посчитает его не требующим обработки (как несостоявшегося) или обработает некорректно. Данная балансировка может быть интересна для мониторинга состояния отдельных участков инфраструктуры (когда в систему анализа на самом деле должны прийти именно все пакеты заданного туннеля), но для этого обычно используется фильтрация.
2. Балансировка по вложенным заголовкам. Брокер сетевых пакетов для балансировки игнорирует внешние заголовки и распределяет пакеты между системами DPI с сохранением целостности сессий AB-BA и CD-DC. При этом для мониторинга состояния отдельных участков инфраструктуры можно настроить фильтрацию по внешним заголовкам. Таким образом каждое средство DPI получит цельный поток информационного обмена пользователей, а средства мониторинга все пакеты заданного туннеля.

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



То есть, если сессии AB и CD по 10 Гбит/с каждая инкапсулированы в туннель T1, то получается 20 Гбит/с трафика (которые могут передаваться по интерфейсу 40GbE/100GbE или через агрегированные каналы LAG 10GbE). После копирования и попадания данного потока в брокер сетевых пакетов возникает необходимость разбалансировать этот трафик на несколько систем DPI по интерфейсам 10 GbE. Сделать это с сохранением целостности сессий используя внешние заголовки невозможно поток превысит пропускную способность выходного интерфейса и пакеты начнут теряться.

Балансировка по вложенным заголовкам обеспечивает возможность разделить поток на более мелкие без ущерба для целостности информационного обмена и качества работы систем DPI.

Балансировка фрагментированного туннелированного трафика

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



Когда на вход туннелирующего устройства приходит пакет с размером равным MTU, то после добавления туннельных заголовков пакет начинает MTU превышать (на количество байт туннельного заголовка) и делится на фрагменты. Причём вложенный заголовок содержится только в первом фрагменте. В результате два пакета одной сессии (AB1 и AB2), попавшие в разные туннели (T1 с заголовком XY и T2 с заголовком XZ) превращаются в четыре пакета:

• с внешним заголовком XY и вложенным заголовком AB
• с внешним заголовком XY без признаков туннелирования
• с внешним заголовком XZ и вложенным заголовком AB
• с внешним заголовком XZ без признаков туннелирования

В данном случае без функции отслеживания фрагментов выбор будет между нарушением целостности информационного потока из-за распределения разных туннелей между разными системами DPI и нарушением целостности информационного потока из-за распределения разных фрагментов между разными системами DPI. Отслеживание фрагментов с балансировкой по вложенным заголовкам обеспечивает сохранение целостности даже в таких случаях.

Столкнувшиеся с указанными проблемами в большой части трафика понимают их и решают. Как обычно хуже всего, когда проблема касается менее 10% трафика она может быть незаметна и создается иллюзия, что всё в безопасности. А под безопасностью туннель.

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

Основа исследования

В 1959 году американский ученый Ричард Фейнман (1918-1988) высказал теорию о том, что когда-то мы сможем создавать молекулярные моторы. Кому-то эта идея на то время могла показаться безумной, но скептическое отношение к науке еще никогда никого не останавливало.

Основной механизм молекулярных моторов это вращение, за что их еще именуют молекулярными роторами. В 1999 году Т. Росс Келли и его коллеги опубликовали доклад (Unidirectional rotary motion in a molecular system), в котором описывалось ротационное движение молекулярной системы посредством химических процессов.


Профессор органической химии Бостонского колледжа Т. Росс Келли.

Система состоит из трехлопастного триптиценового ротора и геликена и может выполнять однонаправленное вращение на 120. Чтобы выполнить это вращение, системе необходимо пройти 5 этапов.


Молекулярный ротор Келли (схема 5-этапного вращения).

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

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

В том же 1999 году в университете Гронингена (Нидерланды) под руководством Бена Феринга был создан еще один молекулярный мотор (Light-driven monodirectional molecular rotor). Их вариант мог вращаться на 360 градусов и состоял из бис-хелицина, соединенного двойной аксиальной связью и имеющий два стереоцентра.


Молекулярный ротор Феринга (схема 4-этапного вращения).

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

В 2008 году в университете штата Иллинойс (США) Петр Крал с коллегами разработали молекулярный мотор, движение которого осуществляется за счет резонансного или нерезонансного туннелирования электронов (Nanoscale Rotary Motors Driven by Electron Tunneling).


Молекулярный мотор Крала (схема вращения за счет туннелирования электронов).

Туннелирование электронов обеспечивает мотор энергией, необходимой ему для движения. Сам мотор состоит из 3 (или 6) лопастей, образованных на основе полимеризированного ицеана. В качестве оси мотора используется углеродная нанотрубка.

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

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

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

Ученые решили использовать эту концепцию, но слегка изменив ее. В качестве хирального статора* было решено использовать поверхность нецентросимметричных кристаллов PdGa (Pd палладий, Ga галлий).

Статор* неподвижная часть мотора, взаимодействующая с ротором (подвижная часть мотора).

Это ослабляет геометрические ограничения на молекулу ротора и позволяет реализовать направленное движение даже для простых и симметричных молекул, таких как C₂H₂.

На Pd₃ молекулы ацетилена адсорбируются поверх тримеров Pd. Во время STM-визуализации при 5 К они выглядят как гантели с разнесением между лепестками около 3 в трех симметрично эквивалентных ориентациях, повернутых на 120 (1E-1G), между которыми они переключаются квазимгновенно (1C и 1D).


Изображение 1

Молекулы ацетилена прочно закреплены на тримере и обычно диссоциируют* перед тем, как их вытаскивают из тримера с помощью иглы микроскопа.

Диссоциация* распад сложных химических соединений на составляющие компоненты.

Ученые наблюдали за процессом вращения, записывая временной ряд туннельного тока I_T(t) при фиксированном положении иглы (1H).

I_T(t) на графике 1H, записанный в течение t = 100 с, демонстрирует последовательности циклических скачков между тремя уровнями ( .RA RB BC RA ) с n_CCW= 23 и n_CW= 0 (CCW против часовой стрелки, CW по часовой стрелке). Это приводит к частоте f = n_CCW + n_CW / t = 0.23 Гц и идеальной направленности dir = 100% (n_CCW-n_CW) / (n_CCW + n_CW) = 100%.

СМТ снимки показывают, что в движении мотора преобладает направление против часовой стрелки.


Изображение 2

Анализ параметрической зависимости частоты вращения (2A-2C) показывает, что этот молекулярный двигатель работает в двух различных режимах: режим туннелирования (TR), где его частота вращения T не зависит от температуры (T < 15 K), напряжения смещения ( |V_G| < 30 мВ) и тока (I_T < 200 пА); классический режим (CR), где частота вращения зависит от этих параметров.

Экспериментальные данные (изображение 1) были записаны в режиме TR, однако ученые решили сначала рассмотреть именно классический режим, где вращения C₂H₂ могут избирательно подпитываться от тепловых или электрических возбуждений.

Для начала была найдена температурная зависимость частоты вращения при низком смещении (2А), чтобы следовать характеристике Аррениуса* (сплошная линия на 2А): (T) = _T + _Аexp (- E_B / k_BT), где _T = 4.5 Гц, _А = 10 8.72.0 Гц, E_B = 27.57.1 мэВ.

Уравнение Аррениуса* устанавливает зависимость константы скорости химической реакции от температуры.

Выше 30 мВ частота увеличивается экспоненциально с VG, независимо от полярности (2B и 2C). В тех же условиях, но при постоянном напряжении смещения, степенная зависимость* ( Iⁿ_T при n 1; 2D) идентифицирует электронно-стимулированное вращение как одноэлектронный процесс. Зависимость частоты и направленности вращения от параметров T, V_G и I_T хорошо воспроизводится кинетической моделью Ланжевена (сплошные линии на 2B и 2C).

Степенной закон* относительное изменение одной величины приводит к пропорциональному относительному изменению другой величины.

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

Для этого было измерено 6400 временных рядов с постоянной высотой наконечника z_T(t) на 80х80 сетке из равноудаленных точек 1х1 нм² в окрестности отдельных молекул ацетилена в режиме туннелирования (2E). К счастью, анализ показал, что игла микроскопа никак не влияет на однонаправленное вращение молекулы.

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

Кроме того, как видно на 2G, нет явной зависимости T от положения иглы. Потому можно предположить, что все три вращательные конфигурации C₂H₂ будут энергетически эквивалентными. Три вращательных состояния становятся энергетически невырожденными, только если игла поднесена слишком близко к подложке.

Оценив 1792 событий вращения (n_CCW= 1771 и n_CW = 21) в режиме туннелирования, была определена направленность dir 96.7% с достоверностью 2. Сопоставив результаты моделирования и экспериментов удалось определить вращение C₂H₂, описать которое можно как вращающийся ротор, центр масс которого движется по окружности с радиусом r = 0.5 0.1 и моментом инерции I_C2H2 = 5.62 х 10^-46 кгм² (2Н).


Изображение 3

Установив степень влияния иглы микроскопа на вращение системы, ученые приступили к детальному рассмотрению зависимости вращения от параметров системы (3A-3D). Температурная зависимость показывает быстрое падение направленности, когда термически активированные вращения начинают вносить значительный вклад. Сплошная линия на 3А предполагает, что _T имеет 98%-ную направленность, тогда как термически активированные скачки, описываемые уравнением Аррениуса, являются чисто случайными.

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

При T = 5 K уменьшение направленности также наблюдается для напряжений смещения V_G выше 35 мэВ (3B). Однако, в отличие от тепловых вращений, те, которые вызваны неупругим туннелированием электронов (IET), становятся ненаправленными постепенно. Это отчетливо наблюдается в режиме, когда сосуществуют тепловые и IET-вращения. Как показано на 3C, независимая от напряжения направленность (10% при T = 19 K и |V_G| < 30 мВ) может быть значительно увеличена при более высокой |VG| из-за дополнительных направленных вращений IET. Однако это увеличение эффективно только в узком диапазоне напряжений, за пределами которого (в большую сторону) направленность быстро уменьшается.

В отличие от этого, I_T-зависимость направленности для фиксированного напряжения является слабой (3D), где небольшое уменьшение направленности с увеличением тока объясняется обнаружением двух быстро последовательных вращений против часовой стрелки как одного ошибочного непрерывного вращения. (сплошные линии на 3D). Из этого следует, что направленность остается выше 95% при |V_G| < 40 мВ даже при высоком токе.

Для моделирования кинетики происходящих событий в данной системе было решено использовать концепцию смещенного броуновского движения*, предложенную в исследовании Астумяна (The Physics and Physical Chemistry of Molecular Machines) и Хэнджи (Artificial Brownian motors: Controlling transport on the nanoscale).

Броуновское движение* беспорядочное движение частиц твердого вещества, вызванное тепловым движением частиц жидкости или газа.

В полученной модели IET-индуцированного вращения предполагается статический и периодический, но асимметричный потенциал U() ( = [0.2] с периодичностью /3) с асимметрией потенциала (R_asym, вставка на 3Е).

Одно IET события достаточно для мгновенного возбуждения молекулы из ее основного состояния, а ее траектория (t) получается из динамики Ланжевена: I = (U() / ) , где I момент инерции, а коэффициент вязкой диссипации.

В зависимости от R_asym и , две разные минимальные кинетические энергии E_L и E_R требуются для преодоления барьера слева (т.е. для движения по часовой стрелке) и справа (т.е. для движения против часовой стрелки) соответственно. Эти энергии являются основой для описания частоты и направленности с помощью использованной кинетической модели.

Сравнение кинетической модели и результатов экспериментов (2С и 3С) позволяет определить зависящие от температуры E_L(T) и E_R(T) (3E). В результате было установлено, что R_asym равен 1.25 < R_asym < 1.5, предполагая, что E_B = 25 мэВ.

Уменьшение диссипации с 1.6 х 10^-33 кгм²/с при 5 К до 1.1 х 10^-33 кгм²/с при 20 К можно объяснить менее эффективным связыванием молекулы с подложкой при повышении температуры.


Изображение 4

На графике 4А показаны последовательности I_T(t) для C₂H₂, C₂DH и C₂D₂, где отчетливо видно отношения _T (по отношению к C₂H₂) 1:0.56(11):0.24(5) (C₂H₂:C₂DH:C₂D₂), которые наблюдались при использовании разных игл микроскопа.

Это явное относительное уменьшение _T контрастирует со сравнительно небольшим относительным изменением момента инерции 1:1.08:1.2 и, следовательно, показательно для квантового туннелирования.

Рассмотрение I_T(t) последовательности C₂DH с нарушенной C2 симметрией показывает, что вращение протекает через шесть, а не три уровня тока (4B). Это является доказательством того, что для полного вращения ацетилена действительно требуется шесть вращений против часовой стрелки на 60. Сравнение экспериментальных и смоделированных значений _T показало идеальное совпадение (4D).

Квантовые туннельные вращения, сопутствующие высокой направленности в 97.7%, позволяют оценить изменение энтропии одиночного туннельного вращения по экспериментально полученным вероятностям вращения против часовой стрелки и по часовой стрелке, определяемым как S = k_Bln (p_pCCW / p_CW) k_Bln (100/1) 0.4 мэВ/К.

Это означает, что направленное вращение в режиме туннелирования должно быть неравновесным процессом с диссипацией энергии Q > 2 мэВ при 5 К и Q > 6 мэВ при 15 К на вращение.

Максимальная мощность рассеяния составила 100 мэВ/с на каждый ротор, а частота туннелирования составила максимум 10 Гц. Однако микроскоп, необходимый для наблюдений, локально рассеивает около 3 х 10⁶ мэВ / с даже при самых низких настройках туннельного тока. Несмотря на столь экстремальные настройки, наблюдается постоянная частота вращения со стабильно высокой направленностью.

В заключение ученые отмечают, что высоконаправленное вращение C₂H₂ на хиральных поверхностях PdGa{111}Pd₃ демонстрирует богатую феноменологию, наиболее заметно характеризующуюся беспрецедентно высокой направленностью и малым размером мотора.

Ротор (C₂H₂) и статор (кластер Pd₃-Ga₆-Pd₃) состоят всего лишь из 16 атомов, образуя однонаправленный шестизначный циклический молекулярный двигатель (4В), который непрерывно работает, получая энергию исключительно от одиночных электронов.

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

Эпилог

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

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

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

Немного рекламы

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Что мы говорим богу IPv6?


Верно, и богу шифрования сегодня скажем то же.

Здесь будет о нешифрованном IPv4 туннеле, но не о тёплом ламповом, а о модерновом светодиодном. А ещё тут мелькают сырые сокеты, и идёт работа с пакетами в пространстве пользователя.

Есть N протоколов туннелирования на любой вкус и цвет:

• стильный, модный, молодёжный WireGuard
• мультифункциональные, как швейцарские ножи, OpenVPN и SSH
• старый и не злой GRE
• максимально простой, шустрый, совсем не шифрованный IPIP
• активно развивающийся GENEVE
• множество других.

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

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

Исследуя различные протоколы туннелирования внимание моего внутреннего перфекциониста раз за разом привлекал IPIP из-за его минимальных накладных расходов. Но у него есть полтора существенных недостатка для моих задач:

• он требует публичные IP на обеих сторонах,
• и никакой тебе аутентификации.

Поэтому перфекционист загонялся обратно в тёмный угол черепной коробки, или где он там сидит.

И вот как-то раз читая статьи по нативно поддерживаемым туннелям в Linux наткнулся на FOU (Foo-over-UDP), т.е. что-попало, завёрнутое в UDP. Пока из чего-попало поддерживаются только IPIP и GUE (Generic UDP Encapsulation).

Вот она серебряная пуля! Мне и простого IPIP за глаза. думал я.

На деле пуля оказалась не до конца серебряной. Инкапсуляция в UDP решает первую проблему к клиентам за NAT-ом можно подключаться снаружи используя заранее установленное соединение, но тут половинка следующего недостатка IPIP расцветает в новом свете за видимыми публичными IP и портом клиента может скрываться кто угодно из приватной сети (в чистом IPIP этой проблемы нет).

Для решения этой полуторной проблемы и родилась утилита ipipou. В ней реализован самопальный механизм аутентификации удалённого хоста, при этом не нарушая работы ядрёного FOU, который будет шустро и эффективно обрабатывать пакеты в пространстве ядра.

Не нужон твой скрипт!

Ок, если тебе известны публичные порт и IP клиента (например за ним все свои, куда попало не ходют, NAT пытается мапить порты 1-в-1), можешь создать IPIP-over-FOU туннель следующими командами, без всяких скриптов.

на сервере:

# Подгрузить модуль ядра FOUmodprobe fou# Создать IPIP туннель с инкапсуляцией в FOU.# Модуль ipip подгрузится автоматически.ip link add name ipipou0 type ipip \    remote 198.51.100.2 local 203.0.113.1 \    encap fou encap-sport 10000 encap-dport 20001 \    mode ipip dev eth0# Добавить порт на котором будет слушать FOU для этого туннеляip fou add port 10000 ipproto 4 local 203.0.113.1 dev eth0# Назначить IP адрес туннелюip address add 172.28.0.0 peer 172.28.0.1 dev ipipou0# Поднять туннельip link set ipipou0 up

на клиенте:

modprobe fouip link add name ipipou1 type ipip \    remote 203.0.113.1 local 192.168.0.2 \    encap fou encap-sport 10001 encap-dport 10000 encap-csum \    mode ipip dev eth0# Опции local, peer, peer_port, dev могут не поддерживаться старыми ядрами, можно их опустить.# peer и peer_port используются для создания соединения сразу при создании FOU-listener-а.ip fou add port 10001 ipproto 4 local 192.168.0.2 peer 203.0.113.1 peer_port 10000 dev eth0ip address add 172.28.0.1 peer 172.28.0.0 dev ipipou1ip link set ipipou1 up

где

• ipipou* имя локального туннельного сетевого интерфейса
• 203.0.113.1 публичный IP сервера
• 198.51.100.2 публичный IP клиента
• 192.168.0.2 IP клиента, назначенный интерфейсу eth0
• 10001 локальный порт клиента для FOU
• 20001 публичный порт клиента для FOU
• 10000 публичный порт сервера для FOU
• encap-csum опция для добавления контрольной суммы UDP в инкапсулированные UDP пакеты; можно заменить на noencap-csum, чтоб не считать, целостность и так контролируется внешним слоем инкапсуляции (пока пакет находится внутри туннеля)
• eth0 локальный интерфейс к которому будет привязан ipip туннель
• 172.28.0.1 IP туннельного интерфейса клиента (приватный)
• 172.28.0.0 IP туннельного интерфейса сервера (приватный)

Пока живо UDP-соединение, туннель будет в работоспособном состоянии, а как порвётся то, как повезёт если IP: порт клиента останутся прежними будет жить, изменятся порвётся.

Вертать всё взад проще всего выгрузив модули ядра: modprobe -r fou ipip

Даже если аутентификация не требуется публичные IP и порт клиента не всегда известны и часто непредсказуемы или изменчивы (в зависимости от типа NAT). Если опустить encap-dport на стороне сервера, туннель не заработает, не настолько он умный, чтоб брать удалённый порт соединения. В этом случае ipipou тоже может помочь, ну или WireGuard и иже с ним тебе в помощь.

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

Клиент (что обычно за NAT-ом) поднимает туннель (как в примере выше), и шлёт пакет с аутентификацией на сервер, чтобы тот настроил туннель со своей стороны. В зависимости от настроек это может быть пустой пакет (просто чтобы сервер увидел публичные IP: порт соединения), или с данными по которым сервер сможет идентифицировать клиента. Данные могут быть простой парольной фразой открытым текстом (в голову приходит аналогия с HTTP Basic Auth) или подписанные приватным ключом специально оформленные данные (по аналогии с HTTP Digest Auth только посильнее, см. функцию client_auth в коде).

На сервере (сторона с публичным IP) при запуске ipipou создаёт обработчик очереди nfqueue и настраивает netfilter так, чтоб нужные пакеты направлялись куда следует: пакеты инициализирующие соединение в очередь nfqueue, а [почти] все остальные прямиком в listener FOU.

Кто не в теме, nfqueue (или NetfilterQueue) это такая специальная штука для дилетантов, не умеющих разрабатывать модули ядра, которая средствами netfilter (nftables/iptables) позволяет перенаправлять сетевые пакеты в пространство пользователя и обрабатывать их там примитивными подручными средствами: модифицировать (опционально) и отдавать обратно ядру, или отбрасывать.

Для некоторых языков программирования есть биндинги для работы с nfqueue, для bash не нашлось (хех, не удивительно), пришлось использовать python: ipipou использует NetfilterQueue.

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

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

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

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

У обычного IPIP-over-FOU есть ещё одна проблема при работе с NAT нельзя создать два IPIP туннеля инкапсулированных в UDP с одинаковыми IP, ибо модули FOU и IPIP достаточно изолированы друг от друга. Т.е. пара клиентов за одним публичным IP не сможет одновременно подключиться к одному серверу таким способом. В будущем, возможно, её решат на уровне ядра, но это не точно. А пока проблемы NAT-а можно решить NAT-ом если случается так, что пара IP адресов уже занята другим туннелем, ipipou сделает NAT с публичного на альтернативный приватный IP, вуаля! можно создавать туннели пока порты не закончатся.

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

Если у кого есть идеи, как это исправить оставляя основную часть трафика в ядре, не стесняйтесь высказывайтесь.

К слову сказать инкапсуляция в UDP очень хорошо себя зарекомендовала. По сравнению с инкапсуляцией поверх IP она гораздо стабильнее и чаще быстрее несмотря на дополнительные накладные расходы на заголовок UDP. Это связано с тем, что в Интернете бльшая часть хостов сносно работает только с тремя наиболее популярными протоколами: TCP, UDP, ICMP. Ощутимая часть может вообще отбрасывать всё остальное, или обрабатывать медленнее, ибо оптимизирована только под эти три.

Например, поэтому QUICK, на базе которого создан HTTP/3, создавался именно поверх UDP, а не поверх IP.

Ну да хватит слов, пора посмотреть как это работает в реальном мире.

Батл

Для эмуляции реального мира используется iperf3. По степени приближённости к реальности это примерно как эмуляция реального мира в Майнкрафте, но пока сойдёт.

В состязании участвуют:

• эталонный основной канал
• герой этой статьи ipipou
• OpenVPN с аутентификацией, но без шифрования
• OpenVPN в режиме всё включено
• WireGuard без PresharedKey, с MTU=1440 (ибо IPv4-only)

Результаты

канал на 20 Mbps





канал на 1 оптимистичный Gbps





Во всех случаях ipipou довольно близок по показателям к базовому каналу, и это прекрасно!

Нешифрованный туннель openvpn повёл себя довольно странно в обоих случаях.

Если кто соберётся потестить, будет интересно услышать отзывы.

Да пребудет с нами IPv6 и NetPrickle!