Хочу IPv6! Даешь сразу несколько IPv6 в одни руки!

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

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

Маршрутеризация, маршрутеризация, маршрутеризация.

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

Содержание

Обеспечение отказоустойчивости
Балансировка нагрузки
Определение канала в зависимости от запрашиваемого сайта

Обеспечение отказоустойчивости

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

Балансировка нагрузки

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

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

Однако, как правило, в домашних условиях, IPv6 каналы — виртуальные интерфейсы, которые приходят по одному–единственному физическому каналу (например, по оптике или посредством мобильного модема).

В теории, пакеты передаваемые по сети, могут приходить получателю разными маршрутами по глобальной сети, более того, они могут приходить совсем не в том порядке, в котором они были отправлены. Однако на практике, некоторые особо чувствительные приложения, например, сервисы телеконференций или финансовые приложения, могут оказаться не в восторге оттого, что данные к ним поступают не в том порядке. В том числе по этой причине, различные «сумматоры интернетов» (см. статью про доступ в сеть через сотовых операторов) обязательно используются сервер, собирающий разрозненные пакеты в нужном порядке, и отправляет их далее. Поэтому балансировку лучше делать на основе соединений, а не пакетов. Что требует несколько большей квалификации, чем обладает среднестатистический пользователь. Но и такой вариант тоже не панацея от неожиданностей, поэтому для домашнего и мелкоофисного применения обойдемся без балансировки загрузки, так как она лишена практического применения.

Определение канала в зависимости от запрашиваемого сайта

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

Прописать все маршруты руками

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

Далее, маршруты указываются только с использованием IP-адреса, а не доменного имени. А поскольку речь идет о IPv6, то одно доменное имя может иметь сотни и тысячи IPv6 адресов. А если веб-сайт использует CDN (Content Delivery Network), а кто их не использует, то эти адреса могут меняться время от времени. Один-два сайта, ну ладно, десяток, можно замаршрутизировать в ручном режиме, но вот с большим количеством совладать уже не так просто.

Маршрутизировать на основе разрешения доменного имени

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

На роутере, если он позволяет подобное, что сомнительно, пока в моду окончательно не вошли маршрутизаторы с полноценным железом и операционной системой, или на своем домашнем сервере, что-то особо мощное не требуется, устанавливается DNS-resolver (служба, которая разрешает доменные имена в их IP-адреса), который используется для разрешения доменных имен всеми клиентами в сети. Если обрабатываемое доменное имя присутствует в созданном руками или любым другим способом списке, то определенные IP-адреса используются для последующей маршрутизации в соответствующий канал. Маршруты можно прописывать на этом же сервере (если используется сервер), в этом случае он должен быть выбран в качестве gateway для всех клиентов, или на роутере (он-то как раз таким и является по умолчанию) в том числе удаленно.

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

Маршрутизация в разные интерфейсы на основе доменного имени, выбираемого пользователем

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

В моем хозяйстве порядка 10 различных локаций, каждая из которых имеет Keenetic в качестве корневого маршрутизатора, и по микросерверу под управлением Ubuntu. Все локации соединены в единую маршрутизируемую IPv4/IPv6 сеть с «серыми» сетевыми адресами, созданную посредством VPN Wireguard, и центрального сервера все на той же серверной Ubuntu, но уже не на живом железе, а на VPS. Топология звезда. Keenetic-и тянут объединяющий VPN, а все остальные виртуальные сети и туннели, обрабатываются самим VPS и микросерверами. Такая топология обусловлена тем, что Keenetic не позволяет использовать все требуемое программное обеспечение без использования виртуальной оболочки для его запуска, что существенно сказалось бы на производительности решения.

Для демонстрационных целей представим, что у нас есть всего две локации: East Coast и West Coast. В каждой стоит по Keenetic в качестве корневого маршрутизатора. В обеих локациях имеется свой микросервер. И в East Cost и в West Coast есть пользователи, предпочитающие навещать религиозные сайты католической и православной направленности. East Coast повезло больше, провайдер интернет предоставляется не только доступ к IPv4 сети, с серым, разумеется, адресом, но и выделяет стандартную /64 IPv6 сеть с белыми адресами. У обитателей West Coast есть доступ от провайдера только к IPv4 сети с серой адресацией. Все локации объединены посредством Wireguard VPN и VPS-сервера в единую сеть. На VPS и на двух кинетиках интерфейс wg0, в нем бегает только IPv4 серая адресация, отличная от адресации сетей в East и West Coast локациях.

Keenetic до сих пор не умеет пускать IPv6 через Wireguard интерфейсы. Для IPv4 настроена полная маршрутизация: с любого устройства из любой локации, зная сетевой IPv4 адрес, можно подключиться к любому устройству из другой локации. Keenetic-ки и VPS выступают в роли мостов между сетями. Помимо wg0 на микросерверах в локациях подняты еще два Wireguard соединения через VPS. Это wg-gray, маршрутизируемый IPv6 интерфейс, но с серой адресацией, применяются те же принципы NAT, что и в IPv4 сетях. На VPS настроена трансляция адресного пространства IPv6 адресов на адрес IPv6 с интерфейса epn24c2 VPS. В принципе, пользователям East-Coast сервис, осуществляемый посредством wg-gray не так уж и необходим, так как у них есть доступ к маршрутизируемой IPv6 сети с белыми адресами, получаемой от провайдера. Но, я за однообразие во всех локациях. Помимо wg-gray на всех микросерверах присутствует интерфейс wg-ipv6 раздающий маршрутизируемые диапазоны /64 белых адресов IPv6, полученных из /48 сети на VPS, по локальным сетям обеих локаций. Я намеренно не привожу адреса на интерфейсах и локациях, дабы не путать читателя, а там, где будет необходимость использовать адреса, буду давать комментарии. Все это богатство изображено на диаграмме ниже для более простого понимания:

Вымышленная сетевая диаграмма двух локаций

Итак, у нас на всех микросерверах, на всех клиентах и на VPS присутствует по несколько IPv6 адресов, а у обитателей East Coast их аж три (белый от провайдера, серый с VPS и еще один белый с VPS). Осталось только научиться их правильным образом использовать с религиозными целями. Для этого придется решиться несколько технических проблем.

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

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

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

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

Настройка Proxy в ОС WIndows 11

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

Где запускать Proxy?

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

Схема расположения прокси и работа маршрутов

На диаграмме выше приведена схема, согласно которой пользователь, выбирая в браузере порт, на котором работает прокси (в диаграмме доступно два порта 11910 и 11920), попадает либо в мир православного IPv6 интернета, либо в мир католического IPv6 интернета, как бы это дико ни звучало, хотя в реальности необходимо еще добавить отдельные порты для выхода правоверных и всех прочих течений конфессий согласованной, но разделенной по религиозному принципу, реальности.

Для реализации этой схемы необходимо где-то установить и запустить этот proxy с доступами на разных портах. Только вот где? Ответ тут довольно простой, прокси можно установить в любом месте сети, но там, где есть выход к необходимому количеству IPv6 каналов. Другими словами, прокси можно установить на VPS, можно установить на любом из микросерверов, можно установить даже на клиентских компьютерах. От места установки будут зависеть небольшие технические нюансы, но на общую схему они не повлияют.

Немного прикинув в уме, я решил установить proxy на VPS-сервере, т. к. все равно он является основным источником дополнительных IPv6 подключений для локаций, он доступен из всех локаций через интерфейс wg0 (соединение всех локаций через Wireguard на основе IPv4 сети с серой адресацией).

Маршрутизация на VPS

Но прежде чем устанавливать прокси, необходимо для начала запустить в рабочем режиме работоспособность двух каналов с IPv6 на VPS-сервере (enp24c1 и enp24c2). Интерфейс enp24c1 используется как основной, он заявлен, в том числе как gateway с метрикой 1. Другими словами, весь трафик по умолчанию отправляется именно через этот интерфейс. Интерфейс enp24c2 тоже заявлен как gateway, но уже с метрикой 1024. Посмотреть маршрутизацию можно посредством команды ip -6 route show. Это означает, что если по каким-то причинам enp24c1 станет недоступным, то трафик будет передаваться серез интерфейс с большей метрикой, чем у выбывшего из строя. А это, в свою очередь, означает, что трафик отправляемый в интерфейс enp24c2 будет уходить через интерфейс enp24c1. Чего нам совсем не хочется, т. к. задача состоит в распределении трафика между этими двумя интерфейсами.

Для исправления ситуации нужно настроить маршрутизацию. Но, обычная маршрутизация, к которой все привыкли, например, ip route add 1.1.1.1 via 1.2.2.2, строится на основе адресации получателя. Она нам не подходит, т. к. мы заранее не знаем, какой адрес необходимо отправить в данный, конкретный интерфейс. В нашем случае требуется использовать маршрутизацию на основе адресации отправителя. В операционных системах семейства Linux помимо обычной маршрутизации можно использовать так называемую Policy Based Routing, т. е. маршрутизацию, основанную на правилах. Ничего сложного в ней нет, если постараться понять принципы, которые довольно неплохо изложены в статье в «Блоге любителя экспериментов». А реализуются они на основе команд утилиты ip.

Напомню, что на VPS есть интерфейс enp24c2 на котором работает маршрутизируемая сеть IPv6, которая раздается в wg-ipv6 и доступна во всех локациях, а также интерфейс enp24c1 на основе которого стоится раздача серых IPv6 адресов для локаций через wg-gray. Придется сделать так, чтобы все пакеты IPv6 из wg-ipv6 маршрутизировались в enp24c2, так как сейчас, пока доступен enp24c, весь IPv6 трафик отправляется через него. Весь остальной IPv6 трафик будет уходить через enp24c1 (будет использоваться правило gateway с метрикой 1).

Итак, для этих целей применяем следующий подход:

Создаем таблицу маршрутизации, назовем ее, например, my_t и дадим ей номер 123. Номер таблицы лучше сделать меньше номеров таблиц main и default. Таблицу можно создать руками в файле /etc/iproute2/rt_tables. По аналогии с тем, что там уже записано.
Добавляем правило по которому пакеты будут фильтроваться и обрабатываться маршрутами, указанными в таблице my_t. Делается довольно просто при помощи следующей команды ip -6 rule add from 2001:470:a35a::/48 lookup my_t. Сдесь указывается, что все пакеты с любым адресом из диапазона 2001:470:a35a::/48 должны обрабатываться маршрутами из таблицы my_t. А диапазон адресов 2001:470:a35a::/48, это как раз тот диапазон, что маршрутизируется через wg-ipv6.
Добавляем маршрут в таблицу my_t. Команда ip route add default via 2001:470:a376::1 dev enp24c2 table my_t. Это командой мы устанавливаем gateway с адресом 2001:470:a376::1 (этот адрес фактически является gateway для интерфейса enp24c2). Т.е. маршрут по умолчанию, для всех пакетов с source адерсом (это мы установили в команде фильтрации) из диапазона 2001:470:a35a::/48 , при этом указываем, что пакеты должны отправляться через интерфейс enp24c2. А маршрут добавляется в таблицу my_t.

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

Несколько замечаний:

Вместо указания адреса from 2001:xxxxxxx можно использовать другой квалификатор, привязывающийся не непосредственно к IP-адресу или диапазону, а к интерфейсу. В этом случае часть команды будет выглядеть как iif wg-ipv6. Однако по неизвестной причине данный вариант у меня не заработал. Интересно, конечно, почему, но искать причину я не стал.
В большинстве команд с ip я использую параметр -6, который прямо указывает на необходимость работы непосредственно с протоколом IPv6. Не во всех случаях это необходимо, но в некоторых обязательно.
Таблицу 123 можно создать единожды, а добавлять правило фильтрации для таблицы my_t и соответствующую маршрутизацию можно при поднятии интерфейса Wireguard wg-ipv6. Делается это при помощи команды PostUp в описании секции [Interface] конфигурационного файла wg-ipv6.conf Wireguard, не забывая при этом про последующее удаление настроек через PostDown:

PostUp = ip -6 rule add from 2001:470:a35a::/48 lookup he_6; ip route add default via 2001:470:a376::1 dev enp24c2 table my_t
PostDown = ip -6 rule delete from 2001:470:a35a::/48 lookup he_6; ip route delete default via 2001:470:a376::1 dev enp24c2 table my_t

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

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

ip -6 rule show — для отображения всех правил фильтрации для протокола IPv6.
ip -6 route show table my_t — для отображения всех маршрутов для протокола IPv6 и таблицы маршрутизации my_t.
ip -6 route flush cache — для сброса кэша маршрутов протокола IPv6, бывает полезно на загруженных узлах для облегчения принятия новых настроек.

Пожалуй, что самая сложная часть настроек на этом пункте и закончена.

Что использовать в качестве Proxy?

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

Более развернутый ответ зависит от предпочтений пользователей и определения технических требований. Для подключения между браузером и прокси могут использовать различные протоколы. Наиболее популярный «движок» для создания браузеров Chromium, поддерживает следующие варианты подключений к Proxy:

Direct — прямое подключение через псевдопрокси. Все запросы отправляются напрямую целевому веб-серверу.
HTTP — наиболее популярный вариант подключения на текущий момент. Данные между браузером и прокси не шифруются, доменное имя передается открытым текстом, даже если через HTTP-прокси устанавливается защищенное соединение (https). Поддерживает аутентификацию.
HTTPS — более продвинутый вариант HTTP, применяется шифрование канала между браузером и прокси. В случае если прокси поддерживает http/2 протокол, то попутно снимается еще и ограничение на максимум 32 одновременно запрашиваемых ресурса.
SOCKS4 — протокол, изначально разрабатываемый для подключения к прокси, не поддерживает аутентификацию. При работе с Socks4 или Socks5 разрешение доменного имени в его адрес осуществляется на стороне прокси–сервера. Для Socks4 доступно разрешение только IPv4 адресов. Официально представлен общественности в 1992 году (в этом же году в свет вышел х/ф «Бешеные псы» К. Тарантино).
SOCKS5 — дальнейшее развитие Socks4, поддерживается аутентификация (но она не поддерживается, намерено отключена, в браузерах на основе Chromium), поддерживается IPv6. Но как и в Socks4 обрабатываются только TCP-соединения. UDP-пакеты, необходимые для полноценной работоспособности http/3 протокола, не поддерживаются (по стандарту UPD должно бегать по Socks5, но только не в Chromium). Спецификация протокола вышла в 1996 году («Храброе сердце» М. Гибсона). Кстати, SOCKS5 можно создать и при помощи ssh -D.
QUIC — работает на основе UDP, быстр, в остальном работает так же, как и HTTPS собрат. В настоящее время находится на стадии разработки.

Соответственно, имеет смысл использовать либо SOCKS5 без аутентификации, либо HTTPS с аутентификацией. А поскольку Proxy в моей конфигурации устанавливается внутри серой сети, снаружи его не видно, то вполне можно обойтись без аутентификации, рассчитывая, что все пользователи вменяемые, и не будут злоупотреблять соединениями.

Итак, после краткого поиска по сети, мне удалось найти для Linux аж несколько вариантов Proxy для серверной стороны:

3proxy — старый игрок на рынке Proxy серверов. Но крайне унылая и путанная документация отбивает всякую охоту с ним связываться. Хотя сервер вполне уверенно работает.

Dante — SOCKS сервер, разрабатываемый Inferno Nettverk с Норвегии. Имеет смысл рассматривать только, если в качестве протокола взаимодействия между браузером и прокси будет SOCKSv5.

Gost — легковесный сервис на Go для манипуляции пакетами. Поддерживает SOCKS, HTTP, HTTPS, обещают поддержать еще и QUIC, когда спецификации будут доступны. Написан на языке Go, имеет открытый проект на GitHub и разрабатывается, вероятнее всего, китайскими разработчиками.

Privoxy — может работать в качестве HTTP или HTTPS прокси–сервера без функций кэширования, но зато с возможной фильтрацией контента с целью очистки от рекламного мусора в веб-страницах.

Tun2Socks — легковесный сервис на Go для проксирования всего из всего и во все. Разрабатывается неким Джейсоном Лю из канадского Торонто. Из основного поддерживает HTTP и SOCKS. HTTPS, к сожалению, не поддерживается (так, по крайней мере, следует из документации). Для своей работы требует создание туннельного интерфейса и определение маршрутизации в туннель.

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

Скачать и установить GOST. Вообще, разработан установочный скрипт, но он у меня по каким-то причинам не сработал, поэтому установка осуществляется руками. Скачивается архив с GitHub https://github.com/go-gost/gost/releases, распаковывается и единственный исполняемый файл складывается в любое удобное место. У меня это место оказалось в /usr/bin/, поэтому я могу вызывать gost из любого места системы без указания полного пути.
Запустить GOST на исполнение. Параметры можно определить в виде конфигурационных файлов двух типов, но проще все указать прямо в командной строке: gost -L socks5://10.32.33.1:11910?interface=wg-gray -L socks5://10.32.33.1:11920?interface=wg-ipv6.

И на этом можно успокоиться и пойти пить чай. Но дам пояснения, как и что тут запараметризировано. В одной командной строке задается сразу два правила начинающихся с -L (от Listening), для каждого из правил определены:

протокол на котором принимать входящие сообщения, в нашем случае это Socks5;
IP-адрес, на котором принимать входящие сообщения, это 10.32.32.1 адрес VPS-сервера на интерфейсе wg0;
порт, на котором принимать соединения, тут их два 11910 для православных пакетов и 11920 для католических, чтобы это и не значило;
параметр интерфейса назначения, в который будет отправлен полученный пакет, соответственно wg-gray и wg-ipv6.

Следует заметить, что wg-gray и wg-ipv6 сконфигурированы в Wireguard только как IPv6 интерфейсы, в настройках указан только IPv6 адрес или диапазон. Поэтому все IPv4 пакеты, приходящие в эти интерфейсы, будут отбрасываться. Вместо интерфейса можно указать IP-адрес или несколько IP-адресов (пакет будет отправлен в первый доступный).

Для автоматического запуска GOST с нужными параметрами можно создать сервис посредством Systemd. Создаем файл gost.service в /etc/systemd/system, наполняем его следующим содержимым:

[Unit]
Description=GOST IPv6 Religious Balancer
After=network.target wg-quick@wg0.service
Wants=network.target

[Service]
User=agnostic
Group=believers
Type=simple
ExecStart=/usr/bin/gost -L socks5://10.32.33.1:11910?interface=wg-gray -L socks5://10.32.33.1:11920?interface=wg-ipv6
restart=always

[Install]
WantedBy=multi-user.target

Получается, что сервис загружается, после того как будет загружен сетевой интерфейс и запущен сервис Wireguard с интерфейсом wg0. Gost запускается от неадминистративного пользователя agnostic, принадлежащего группе believers, это возможно, так как мы занимаем порты свыше 1024, которые доступны для использования обычным пользователям системы.

Обновляем все определения сервисов (альтернативно перезагружаемся) systemctl daemon-reload. Затем активируем посредством systemctl enable gost и запускаем сервис systemctl start gost.

Таким образом, при помощи всего одной команды, был настроен доступ в разные IPv6 интерфейсы на основе Socks5 протокола. Как настроить HTTPS подключение при помощи Gost, домашнее задание для любознательного читателя.

Нагрузка на сервер по данным htop

На скриншоте выше можно убедиться, что одной командой было создано несколько процессов Gost, точнее 9 штук. Они потребляют 1.6% памяти и примерно 0.0% процессора, по данным htop. По моему мониторингу, общая средняя загрузка памяти на VPS, после запуска Gost изменилась с 2.00% до 2.08%. Другими словами, нагрузка на VPS от применения Gost едва заметна, впрочем, как и от множества Wireguard тоннелей и трафика по ним.

Чем и как отлаживать полученную схему?

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

Одна из основных команд — это проверка доступности узла с использованием команды ping. Для проверки доступности по протоколу IPv6 применяется ключ -6. А чтобы направить пакеты в конкретный интерфейс необходимо добавить ключ -I, а после него указать либо наименование интерфейса, либо адрес, принадлежащий этому интерфейсу на этом компьютере. Пожалуй, самый надежный инструмент.

По одной только доступности нельзя судить о том, по какому маршруту пакеты с данными добираются до узла назначения. Для изучения вопроса нужны команды семейства traceroute. Стандартная утилита тоже умеет в IPv6, если указать ключ -6, а при помощи ключа -i и последующего указания имени сетевого устройства или интерфейса на компьютере можно попытаться отправить пакет не через основное направление. При помощи ключа -g и последующим указанием IP-адреса можно указать gateway для отправки пакета. Однако утилита у меня отказывается работать с некоторыми типами интерфейсов, например, Wireguard.

Поэтому ей найдена замена в виде traceroute6, работающей не только с IPv6, но и с IPv4. Ключи у нее используются те же, что и у обычного трассировщика, но работает с любыми интерфейсами. А если не работает, то вместо интерфейса можно применить исходный адрес, который указывается с ключом -s.

Кроме стандартных утилит иногда бывает полезно убедиться, с какого адреса пришел пакет на удаленный хост, как отработала маршрутизация. В браузере это можно увидеть во множестве сервисов, предоставляющих информацию о соединении, например, IPv6 Test или Интернетометр от Яндекса. Но и из командной строки можно узнать адрес источника через сервис ipify. Для IPv6 необходимо вызвать командой curl -s https://api64.ipify.org?format=json. Возвращается адрес, с которого пришел запрос.

Что использовать в качестве переключателя Proxy и нужен ли он вообще?

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

Самый простой способ, он же самый безопасный, но не самый удобный, создать несколько профилей в одном браузере и настроить каждый из профилей на свой прокси (один профиль оставить вообще без прокси). Но увы, в браузерах на основе Chromium есть возможность руками настроить только системный Proxy и нельзя его настроить разным для различных профилей. А вот в Firefox можно, выбрав в том числе и вариант Socks5. Как бы то ни было во, всех современных браузерах есть возможность изменять настройки прокси через устанавливаемые плагины.

И именно тут возникает огромный вопрос, а какой именно плагин стоит использовать, чтобы это было безопасно? В современном мире считается плохим тоном не использовать https-протокол для доступа к веб-сайтам и прочим ресурсам. Особенно если сайт подразумевает авторизацию или идентификацию пользователя. Все данные в https передаются в зашифрованном виде, поэтому, даже если злоумышленник предоставивший публичный прокси и перехватит пакеты, он с ними особо ничего не сделает. Единственный способ добраться до содержимого пакетов — подменить сертификат конечного сайта на свой, провести расшифровку пакетов на прокси, потом все зашифровать обратно. Но в этом случае сам пользователь и его браузер должны проявить внимательность и прекратить доступ к ресурсу, если увидят проблему с подменой сертификата шифрования.

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

Приведу пример, не отходя далеко от кассы. Одно время для подключения к католическим ресурсам применялся довольно удобный плагин FriGate с многочисленными ответвлениями и версиями. В один прекрасный момент я с удивлением обнаружил, что мой браузер начал показывать мне рекламу. После недолгого разбирательства нашелся виновник — плагин FriGate. Он мне нравился, поэтому пришлось взять исходный код плагина, а он доступен в системной директории браузера в открытом виде, и вычистить из него все вредоносные участки кода ответственные за показ рекламы. По результатам очистки пришлось сформировать свой плагин, который и использовался еще некоторое время по мере необходимости. Но авторы FriGate не остановились на достигнутом и несколько позже разработчики Яндекс.Браузера обнаружили в новых версиях плагина еще более ужасающие вещи наподобие скрытого проигрывания видеорекламы и возможности выполнения произвольного кода в браузере пользователя. Под раздачу попали плагины не только FriGate, но и многие другие популярные плагины с миллионными аудиториями.

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

FoxyProxy

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

Интерфейс настроек FoxyProxy

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

SwitchyOmega

Изначально разрабатывался для браузеров на основе Chromium, но существует версия и для Firefox. Исходный код плагина присутствует на GitHub, хотя давно и не изменялся, добавить плагин в браузер лучше через маркетплейс конкретного браузера.

Интерфейс настроек SwitchyOmega

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

SmartProxy

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

Интерфейс настроек StmartProxy

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

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

Какие недостатки у приведенного способа?

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

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

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

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

Если уехать с ноутбуком в Муром или, например, Фэрбанкс, то доступа к системе уже не будет, т.к. прокси висят на внутреннем адресе wg0. Придется подключаться сначала через Wireguard в сеть на основе интерфейсов wg0 и только после этого появится доступ к прокси. Выносить прокси на интерфейс полностью доступный извне, я бы не советовал, т.к. многие провайдеры VPS очень не приветствуют подобные действия.

Несколько IPv6 роутеров в одной локальной сети, что предпринимать?

Сети IPv6 вполне допускают наличие сразу нескольких маршрутизаторов IPv6 в рамках одной сети. И что в таком случае делать счастливым пользователям в East Coast локации? Ведь у них IPv6 доступен от провайдера, плюс доступен серый IPv6 через интерфейс wg-gray на микросервере, оттуда же может быть доступен и еще один вариант белого IPv6 через интерфейс wg-ipv6. Как в таком случае будет работать динамическая маршрутизация?

Роутерами в пределах сегмента становятся интерфейсы объявленными таковыми через механизм Route Advisement (RA), в Linux и на маршрутизаторах Keenetic за RA отвечает сервис radvd.

В параметрах настройки radvd есть ключ, отвечающий за приоритет анонсируемого маршрутизатора. Параметр AdvDefaultPreference может принимать значения low, medium или high. По умолчанию трафик IPv6 будет маршрутизироваться на маршрутизатор IPv6 имеющий приоритет high, если такового нет, то medium, если и таковой отсутствует, то будут использован маршрутизатор с приоритетом low. В Keenetic приоритет настраивается через командную строку следующей командой ipv6 subnet <name> priority {low|mid|high}. По умолчанию используется приоритет mid.

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

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

interface eth0
{
    AdvSendAdvert on;
    prefix 2001:db8:0:1::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
    };
    clients
    {
        fe80::21f:16ff:fe06:3aab;
        fe80::21d:72ff:fe96:aaff;
    };
};

В приведенном примере анонсируется маршрутизатор на интерфейсе eth0 с подсетью 2001:db8:0:1::/64 но только для двух клиентов с Link-Local адресами fe80::21f:16ff:fe06:3aab и fe80::21d:72ff:fe96:aaff. Вариант интересный, но опять не подходит для нашего случая, так как хотелось бы светский трафик гнать минуя все схемы с Proxy.

Работа в среде Multi-Home

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

IPv6 был создан в 1996 году, но до сих пор в Keenetic через веб-интерфейс нельзя настроить статическую IPv6 маршрутизацию. Поэтому для ее настройки придется нырять в CLI и применять команду ipv6 route ( ‹prefix› | default) ( ‹interface› [‹gateway›] | ‹gateway›) для добавления маршрута. Если добавить no перед командой, то маршрут будет удален. А для просмотра маршрута необходимо перейти в контекст show и применить команду ipv6 route. После изменения маршрутов, традиционно не стоит забывать сохранить изменения.

Следует обратить внимание, что если IPv6 соединение через Keenetic получается посредством использования команды ipv6 pass through ISP Home, которая означает, что раздачей IPv6 занимается роутер за Keenetic, то настраивать маршрутизацию на Keenetic будет бессмысленно, так как его интерфейс IPv6 будет отключен. Аналогично на некоторых Keenetic маршрутизация для IPv6 выглядит следующим образом ipv6 route ( ‹prefix› | default) ( ‹interface› ), в таком случае пакеты можно перенаправлять только до конкретного интерфейса на самом Keenetic.

Многобукфф

Vladislav's personal blog site