Comments 73
Солидный труд, спасибо! Единственное что резануло - фраза "нельзя же быть таким отсталым, с домашним сервером и без докера". Докер вполне может быть банально не нужен.
Но, честно говоря, я могу представить мало ситуаций, где докер совсем ничего не принесет. Ну разве что в ситуации «на сервере стоит ровно один nginx и более ничего».
В любых других ситуациях докер — это разделение разных сущностей, отделение пользовательского конфига от бинарников и файлов сервера, гарантированно воспроизводимая сборка (если фиксировать версии). Это уже плюсы, ради которых стоит попробовать перейти с парадигмы «пять серверов пытаются ужиться в одной системе». Можно, конечно, заводить виртуалки под каждый сервер и использовать ансибл, это тоже даст воспроизводимость, но это немного оверхед, что по ресурсам, что по месту на диске, как по мне.
Вот, например, стандартный VDS стандартного IT-шика: там, обычно nginx/apache/lhttpd + python/php/node + OpenVPN/WG и все — смысл там ставить докер?
Разве что если на нем хостить публичный сайт, чтобы если root-а получат, не вылезли из гостевой оси… ну такое.
Ошибаюсь?
В докере же каждое приложение выполняется в своем окружении, со своими библиотеками и даже системными файлами, и они принципиально не могут друг другу помешать, записать что-то не туда или забрать чужой порт.
Мне нравится, что докер делает из приложений черный ящик — вы выдаете ему папку для конфигурации (у меня, например, /mnt/user/appdata/app_name), выдаете папку для данных, если их много, указываете сопоставление порт контейнера-порт хоста, и все, в идеальном случае вас не волнует, как там приложение запускается и как работает, как оно устанавливается, какие там скрипты автозапуска, чем оно в процессе установки нагадит в систему, какие пакеты поставит, насколько они будут совместимы с вашими и так далее, об этом заботятся меинтейнеры докер-образа. Иногда приходится что-то править, но не сравнить с тем, какой геморрой приходить через месяца два-три и пытаться вспомнить, что там на сервере стоит и где какие конфиги лежат, если запускать это без докера.
Плюс, очень-очень упрощается миграция. Смигрировать десяток серверов на новую на другой железный сервер — сложно, потому что надо отделить конфиги приложений от конфигов системы, найти где каждое приложение хранит свои файлы и БД, скопировать куда-то, поставить все этой на новом, поразбирать глюки и так далее.
Нет, если вы ежедневно админите этот сервер и это ваша основная работа, вы все и так помните. Но я, во-первых, очень ленивый, а во-вторых, мне очень не хочется уделять
Докеры мигрировать одно удовольствие — вот папка конфига, вот папка данных, они описаны в параметрах самого докера, их нельзя забыть, их нельзя не записать, без них он не будет нормально работать. Папки скопировали, файлы docker-compose перенести, запустили, там за десять минут скачались образы, запустились, старые конфиги и данные подхватили. Конфиги и данные еще и весят немного, не сравнить с 40гб образами виртуалок.
Но на домашнем VDS приложений обычно совсем не много и они гомогенные — те им вполне достаточно того, что стоит в системе.
Если же пользоваться 3rd-party решениями — типа owncloud и тд — вот тогда да — есть смысл точно, чтобы не маяться с зависимостями чужими.
Кстати про миграцию — может потому что я больше программист, чем админ — я никогда не настраиваю сервак вручную — у меня есть bash-скрипт, в котором я прописал все нужные сервисы и их конфигурации. У меня оно на Debian-е, и для того, чтобы развернуть мне сервак на новом месте, мне нужна голая система, баш и мой скрипт — я его запускаю он сам ставит пакеты, сам конфиугрирует их и сервисы, прописывает что нужно в iptables/config-ах. Да, конечно, если что-то сильно изменили — конфиг нужно будет подправить, но я стараюсь писать его так, чтобы он как можно меньше использовал спец. пакетов, а старался использовать стандартные утилиты и на моей памяти было всего один раз, когда был какой-то конфликт, связанный с обновленным пакетом. По мне — так тоже выход, причем без оверхэда. И при этом не нужно заморачиваться с конфигурацией внешней и внутренней сети докера, а самое главное — оно будет работать на vds с гораздо меньшими требованиями по памяти и цпу, что очень сильно влияет на его цену.
у меня есть bash-скрипт, в котором я прописал все нужные сервисы и их конфигурации.
Ну вот это как раз такая замена ansible, который тоже вариант. Еще один вариант это nixOS, в которой все пакеты и их настройки описываются в конфиге. Но в целом да, с таким подходом докер не так нужен.
И при этом не нужно заморачиваться с конфигурацией внешней и внутренней сети докера, а самое главное — оно будет работать на vds с гораздо меньшими требованиями по памяти и цпу, что очень сильно влияет на его цену.
Хз, я как-то не заморачиваюсь никогда с конфигурацией сети докера, просто порты выбросить и все. Оверхеда у докера тоже очень мало, там же процессы выполняются все равно на хосте, без виртуализации.
Большинство проблем зависимостей скриптовых языков решены через venv и подобные схемы - package.json для ноды и т.п.
Контейнеры полезны с бинарными приложениями с большим деревом зависимостей. Да и то, как мне кажется, проще собрать их статически, если возможно.
У PHP разработчиков часто ситуация, когда свой проект 8+, 7+ на работе и какой-нибудь 5.6 древний легаси там же. И соответственно им разные версии БД, кэш и т.д.
Ну например я с недавних пор приобщился к LXD и мне с ним гораздо удобнее, чем с концепцией контейнер-под-приложение.
Да и сам docker лучше заменить на podman всё-таки. Podman тормозит меньше.
У меня в этой логике всё некоторое время уже и работает. Только WG между серверами и роутерами, а клиенты с ПК и мобильными по OpenVPN (к нему авторизация через LDAP прикручивается без сторонних решений); локальных сетей и за российским, и за зарубежным серверами, и за роутерами, несколько; ну и маршрутизация через Россию по умолчанию, а заблокированные и пр. - через зарубеж.
Вот только всё это прекрасно, пока клиенты в одной стране. А когда они в разных, а если ещё и между ними активно перемещаются... Получается, что из, скажем, Турции весь трафик идёт в Россию, а на заблокированные в России сайты - потом ещё и в Нидерланды. Тормоза. И родные турецкие сайты массово не работают (тут дискриминировать по IP любят ещё больше). А, да, в Турции тоже кое-что заблокировано, но при этом перечня конкретных IP, как у нас, нет...
И вот тут уже надо подключать фантазию, как это сделать минимальными усилиями с максимальным удобством. Либо заводить по серверу в каждой интересующей стране, на каждом настраивать свою маршрутизацию и переключаться между ними (вручную или автоматически, последнее - отдельная задачка). Либо-таки маршруты передавать клиенту, набор оных определять в зависимости от его геолокации, а по умолчанию трафик в VPN не заворачивать (для увеличения скорости доступа и работоспособности местных сайтов даже там, где у нас своего сервера нет). Вот только и VPN-протоколов, приспособленных к передаче сотен тысяч маршрутов, не наблюдается, и клиентским устройствам от такой таблицы маршрутизации может поплохеть. Ладно компьютеры, можно себе представить реализацию, но мобильные...
А, да, в Турции тоже кое-что заблокировано, но при этом перечня конкретных IP, как у нас, нет...
Так тоже можно достать турецкие IP, вроде отдает: stat.ripe.net/data/country-resource-list/data.json?resource=tr
И все кроме них отправлять в туннель.
Я бы просто сделал локальный сервер в каждой стране, все равно локальный трафик через него отправлять, и переключал бы туннель когда из страны в страну перемещался, это проще всего, и не очень часто придется делать.
А на самом деле, похожие решения есть у Tailscale — там туннель устанавливается автоматически в зависимости от пинга и скорости до сервера. Но вот маршрутизацию придется там делать самостоятельно.
А еще есть WARP с кучей серверов в каждой стране, и там тоже внутри можно как-то сделать подсети, и блокировки он в целом обходит (хотя подозреваю в большей степени за счет DNS), и российские ресурсы в нем работают.
Но всегда можно форкнуть WG-клиент и дописать туда выбор маршрута в зависимости от местоположения.
Турецкие IP, как и любой другой страны, достать можно, провайдеров GeoIP-данных достаточно. А вот перечень заблокированных в Турции IP (которые, находясь в Турции, надо гонять через условные Нидерланды) я не нашёл. Есть сервис проверки, заблокирован ли IP в Турции - можно в фоне проверять все IP, к которым обращаются клиенты, на наличие в нём, и потихоньку формировать самому... но, блин, сколько на это всё времени надо...
Идея маршрутизации на клиенте хороша тем, что даже если его занесёт в страну, где сервера нет (ну захотел один сотрудник пару месяцев поработать с Бали - что теперь, срочно сервер в Индонезии поднимать?), VPN доступу к локальным сайтам не помешает. Но тут реализация потребует ещё бóльших заморочек...
Настроил WG в качестве резервного VPN-канала в дополнение к OpenVPN еще в 2019 году. Честно говоря, особых преимуществ по сравнению с OpenVPN не увидел - имхо, WG получил гораздо больше хайпа, чем он заслуживает; скорее всего, по причине "одобрямса" со стороны Торвальдса и других разработчиков Linux, отметивших элегантность решения, чистоту кода и нераздутый функционал (что вполне естественно, учитывая возраст WG).
Однако что тогда, что сейчас, WG, как по мне, остается слишком примитивным (я имею ввиду, из коробки, без обвязки сторонним или самописным ПО). Если сравнивать с тем же bloated OpenVPN, я отметил для себя как минимум такие недостатки:
Невозможность запушить конфиг от сервера к клиенту (в WG типа нет парадигмы "клиент - сервер", а все члены VPN демократично являются равнозначными "пирами"), что особенно критично, если клиент удаленный, и WG является единственным каналом связи с ним.
Одна из самых критичных для меня проблем - при изменении IP эндпойнта "серверного" пира "клиентский" пир не переподлючается к новому адресу (а для меня это критично, так как сервер находится за серым динамическим IP и dyndns-сервисом), и вообще ни коим образом не пытается обеспечить хоть какую-то гарантию связности сети (к слову, OpenVPN отрабатывает этот момент как боженька). При этом в Линуксе хотя бы есть стандартный скрипт wg_reresolve-dns.sh (который у меня почему-то срабатывает через раз, и из-за этого я потерял доступ к нескольким удаленным машинам, к которым не имею физического доступа), а в винде - добро пожаловать в мир самописных скриптов на Powershell. Причем на гитхабе уже несколько лет висит PR с решением для виндового клиента, но воз и ныне там.
Лютое неудобство управления парком клиентов, если ты не админ локалхоста, а хотя бы обладаешь десятком удаленных в разных местах машин. У пиров нет "человеческих" имен, все соединения маркируются только публичными ключами, поэтому приходится либо вести реестр соответствия ключей клиентам, либо назначать т.н. vanity keys, когда программа перебором подбирает публичный ключ таким образом, чтобы первые n символов ключа соответствовали понятному админу референсу (sErv..., cliEnT1...). Перебор больше четырех символов case-sensitive такого референса не на игровых машинах с GPU - это больно. Плюс я так и не понял, как настроить логирование подключений - думаю, его просто нет, а это очень печально.
Спорный момент, но всё же: отстутствует сжатие VPN-трафика. Да, я в курсе, что это небезопасно, что это можно организовать на другом уровне OSI, но всё же. OpenVPN на одном из моих дохлых каналов работает в несколько раз быстрее WG именно из-за сжатия трафика.
В общем, мое мнение: это решение пока не доросло до использования в сириуз бизнес в своем vanillla-виде. Слишком мало функционала в угоду компактности и элегантности кодовой базы.
А если надо наоборот - весь трафик пустить через РФ, а "санкционный" - через другую страну? Т.е. только некоторые ip (сайты) пустить через external. Как в таком случае изменятся команды?
За статью огромное спасибо. Желаю, чтобы все умели писать так же понятно.
А если надо наоборот — весь трафик пустить через РФ, а «санкционный» — через другую страну? Т.е. только некоторые ip (сайты) пустить через external. Как в таком случае изменятся команды?
1)Убрать маршрут 0.0.0.0/0 в wg-internal.conf у ноды external — так весь трафик пойдет через рф.
2)В update_ru_routes.sh сделать что-то вроде ip route add $target_ip via 10.20.30.2 dev wg-internal — так добавленные маршруты отправят трафик в external
3)Заполнить таблицу маршрутов любым удобным способом из списка санкционки, а не из списка российских подсетей, как сейчас.
Решение не проверял.
Считаем, что на обоих серверах у нас Debian 11.
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.forwarding=1" >> /etc/sysctl.conf
Уважаемый автор журнала Хакер уверен что это действительно нужно?
Традиционное начало любой настройки сервера как маршрутизатора. По крайней мере, было, когда я занимался сетями. Что-то изменилось за последние 10 лет?
во всех других инструкциях обычно пишут так:
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
что из этого правильнее?
Это два разных способа сказать ядру одно и тоже. Первый обычно используется в скриптах, второй в конфиге sysctl и применяется при старте. Но никто не запрещает использовать любой способ в любом случае.
Ну и плюс у обоих ключей есть есть ipv6 и ipv4 версии. У вас там один ключ на ipv6, а второй на ipv4.
goodbyedpi-0.2.2
Вот это не решает проблему?
Задолбаетесь вычленять пулы для маршрутов, ибо ничто не вечно под луной. VDS, VPN, socks, два браузера (один смотрит в socks).
С полгода назад, настроил дома WireGuard до 3$ европейского сервера, а вопрос с блокировкий рещил через BGP + antifilter (не сочтите за рекламу). Результатом доволен, все что надо идет через VPN, кому надо (привет NUM) полностью идет через VPN ну и т.д.
P.S. Делал на Keenetic
Столкнулся с тем, что некоторые сайты сидят за CloudFlare и на нём настраивают ограничения для каких-то стран. В итоге, я знаю два сайта, которые сидят в одной подсети CloudFlare, но один доступен только из России, другой же из России недоступен.
тут только что-то по типу antizapret делать (с хитрым днс — у них кстати скрипты тоже открыты)
если чужие серверы использовать ок то теоретически ControlD бы подошел (тоже игры с днс но можно например сказать что *.habr.com — через Парагвай а остальное не трогать) а практически там проблема в том что заголовки https не шифруются а ECH пока никто (включая ControlD) не поддерживает.
Тема пакета qrencode в списке нужных не раскрыта ). А ведь это тоже весьма прикольный способ сбросить настройки в мобильник.
На самом деле, по существу - для настройки wg достаточно доки и демки-гифки с их оф. сайта. Она прямо по существу - и укорачивать некуда, и удлинять незачем.
Для "ходить куда-то зарубеж" wg не лучше и не хуже других; там обычно задержки такие, что произвольным VPN уже сильно не испортишь. А вот именно как локальное решение - подключиться к рабочему месту у себя же в городе, у того же провайдера - т.е. собственно то, почему он и назван VPN - очень даже. Когда хочется и сканером посканировать, и принтером попечатать, и в домашнюю папочку сходить через старый добрый smb или nfs, и не думать при этом "а, это же несекурно!"
По маршрутам выглядит неудобно, я организовал другую логику
в телеграмм пишу домен.
телеграм бот микротика получает домен.
Ищет в своих DNS записях все поддомены.
Смотрит IP указанных доменов
Отправляет трафик до получившихся IP через VPN.
Пока наткнулся только на 1 недостаток: необходимо использовать DNS сервер на микротике, иначе у него не будет DNS записей.
телеграм бот микротика получает домен.
Ищет в своих DNS записях все поддомены.
Смотрит IP указанных доменов
Сломается, если за доменом будут адреса меняться, надо будет каждый раз добавлять.
Ну и плюс, запускаю я какое-то приложение, а оно не работает. Откуда я знаю, на какой именно домен оно там ломится? Инстаграм какой-нибудь, например. Точно ли это api.instagram.com, а не какой-нибудь facebook.uni-api.amazonaws.com?
Не надо каждый раз добавлять, он сам ведёт список ассоциация домен-IP. Думаю из DNS записей берёт.
На счёт приложений. Мне обычно через браузер надо получить доступ, а там через f12 можно посмотреть куда ломится. Если это не браузер:
1 раз смотрел на форуме список IP серверов
1 раз спрашивал домены в саппорте.
1 раз заворачивал весь трафик от устройства в VPN.
Все основные для меня статьи по VPN или обходу - всегда с хабра.
Только столкнулся с таким - на приложения тема с маршрутами не влияет. Да и на сайты тоже. Смог завести ту же амедиатеку и КиноПоиск только после того, как добавил скрипт загрузки сегмента ру.
Вылавливание адресов и подсетей по предложенным инструкциям не особо помогло, видимо, где-то в другом месте проверка идёт.
Что интересно, на SmartTV с настроенной подобным образом системой Кинопоиск открылся.
И, кстати, не могу разобраться ещё с тем, по какой причине и что уже юзает 53 порт на чистом debian только с настройкой из статьи. И поэтому не могу настроить dnsmasq
Ну, точнее да. Я через ss смотрел.
Но комментарий ваш как будто ирония, потому что что-то очевидное :)
Сорян, сейчас для меня не очень 😉
Да, просто нужно было загуглить. И всё окей. Благодарю вас за статью)
Но вот с онлайн-кинотеатрами буду думать. У них много подсетей, а все скриптом добавлять — смысл впн для меня теряется.
Есть разные возможные причины такого поведения. В программе может использоваться свой DNS (например, DoH-резолвер). Свой собственный DNS, опрашивающий другую страну, отдает адреса, любезно предоставленные местным балансировщиком нагрузки из местного (для DNS) сегмента интернета. Или просто так получилось, что часть адресов сервиса оказались по одну сторону туннеля, а часть — по другую.
При этом основное подключение клиента идет с одного адреса, а часть подключений — через VPN с другого (либо наоборот) и сервер разрывает соединения с «неправильного» адреса.
Кстати, это главная проблема реализации подхода исключительно на сетевом уровне L3, игнорируя L4 и далее вплоть до L7. Решение — разбирать и маркировать весь трафик самостоятельно по правилам на разных уровнях, для чего нужно городить по сути свой DPI-сервер или покупать оборудование, которое могут позволить себе не все провайдеры.
Здравствуйте. Оказалось все прозаичнее. Кинул в роутере подключение клиента с данной схемой на резервное подключение (LTE-модем), поймал пакеты, идущие на данный клиент при запуске и работе в приложении при отключенном VPN, глянул WireShark-ом адреса. В большинстве приложений все ок, 2-3 адреса (либо проверка, либо непосредственно сам сервис). С Кинопоиском сложнее — там куча адресов, но по факту тоже 2-3 адреса — и все работает. Но они, похоже, меняются и придется кидать подсеть.
Я просто не хочу весь РУ-сегмент кидать в роуты. В таком случае, зачем тогда VPN.
А вот с Амедиатекой все сложнее. Поймал адреса, добавил в роуты через себя — все равно видит включенный VPN. Либо приложение видит локально на устройстве включенный VPN, либо я не знаю, что-то из перечисленного вами выше.
Но почему не shadowsocks? Wireguard хорош когда нужно весь трафик завернуть или по подсетям, но если это нужно для нескольких приложений или сайтов то он не лучший вариант. Сам использую Wireguard для объединения сети на даче с домашней.
Тот же клиент Shadowsock позволяет в android завернуть только нужные приложения. В Win,Lin,Mac я к примеру использую SwitchyOmega плагин для браузера + Shadowsocks как Socket5 Proxy. Туда идёт трафик только блокированных ресурсов. Разворачивается ShadowSock элементарно.
@vvzvladЕще раз приветствую. Схема как часы работает, прям красиво.
Но вот возник такой вопрос и думаю, возможна ли ее реализация без перелопачивания всей схемы.
Можно ли в данную схему включить второго провайдера? Локальный сервер это конечно хорошо, но если падает провайдер, то вся схема ложится. В external прописывается адрес:порт локального сервера, но если это другой провайдер, то будет и другая сеть.
Просто хочется понять, реализуемо ли такое? Конечно, я пока не говорю о том, что этим вторым провом хочу замастырить LTE-модем с пока еще неизвестной схемой вместо статического IP.
Есть вариант с балансировкой на cloudflare — у них есть DNS, который может переключаться в зависимости от доступности того или иного адреса. Т.е. доступен первый провайдер — домен internal смотрит на его IP, недоступен — DNS начинает отдавать другой IP, второго провайдера. Но вон выше z0mb1e_kgd говорит, что при этом переключаться WG сам не будет, его придется дернуть выкл-вкл вручную.
Я бы на вашем месте, учитывая LTE-модем в качестве бекап-канала, попробовал прикрутить схему с частичным форвардингом к tailscale. Там есть минусы, но mesh работает хорошо.
почитал про tailscale — попробую покопать в эту сторону. Так-то у меня QMI-модем, без web-морды. С отдельным меню самого на самом Keenetic
Смотрите, а не проще ли в моей ситуации тупо склонировать виртуалку (я юзаю это на Proxmox) (очевидно, на внешнем это будет еще один клиент и создать профили для клиентов на телефон, например) и на роутере пустить ее через модем ну и tailscale-ом ее поймать? Конечно, это не автоматизация, но тоже вариант же. В не наглядной настройке я теряюсь, поэтому ищу и другие варианты
Хорошая статья. Но
Таким образом, страшная команда превращается в такую:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Сначала мы получаем, как и выше, сетевой интерфейс маршрута по умолчанию:
root@:~# ip route | awk '/default/ { print $5 }'
enp1s0
интерфейс поменялся с eth0 на enp1s0 ?
И дальше вытаскиваем оттуда адрес, в данном случае 192.168.88.70.
Команда становится такой:
ip rule add from 95.93.219.123 table main
адрес поменялся с 192.168.88.70 на 95.93.219.123 ?
Отличная статья, спасибо!
Всё запустил и всё работает. Только вот есть вопрос:
У меня не получается завести сайты типа ржд, мосру и подобные коммунальные. Делал по аналогии со сбермаркетом, нашел, что сайты на подсетях ростелекома (https://asnlookup.com/asn/AS12389/), пробовал точечно подсети сайта прописывать и даже весь список, который не грепался скриптом тоже дописывал. Сайты не открываются =(
Что можно сделать, чтобы заходил на тот же РЖД? В качестве internal у меня сервер на Яндекс.Облаке. Вроде там руайпишники должно отдавать.
Сейчас попробовал на mos.ru, все ок.
nslookup mos.ru [17:52:46]
Server: 10.20.30.1
Address: 10.20.30.1#53
Non-authoritative answer:
Name: mos.ru
Address: 212.11.155.165
vvzvladMBP14.local (10.20.30.3) -> 212.11.155.165 (212.11.155.165) 2022-12-12T14:40:20+0300
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. adguard.lc 18.6% 236 30.2 23.6 3.3 185.4 34.5
2. dobbi.lc 0.4% 236 4.3 16.9 3.2 181.6 26.5
3. broadband-46-188-5-1.2com.net 0.0% 236 123.3 32.7 3.6 171.5 41.3
4. juni-vl-431-m10.setel.ru 0.0% 236 27.5 33.7 4.3 187.6 43.7
5. setel-gw.fiord.net 0.0% 236 9.0 28.3 4.4 183.1 38.0
6. msk-m9-b1-ae6.fiord.net 0.0% 236 6.6 26.4 4.4 207.1 38.8
7. comcor.ru 0.4% 236 11.1 33.4 4.5 212.3 46.4
8. cher-x2-ptx-cher.comcor.ru 0.0% 236 8.5 35.5 6.5 203.6 41.3
9. 213.171.35.89 0.0% 236 14.1 53.0 7.7 204.7 58.2
10. 10.45.9.18 0.0% 235 89.1 46.7 6.4 187.8 48.8
11. 212.11.155.165 0.9% 235 7.9 28.7 5.9 177.2 33.9
Все же мне кажется, что проблема в серверах Яндекса. Странно, что на госуслуги, сбер и подобные пускает. Вот что показывает прям с сервера запрос.
sofs@wireguard-internal-ru:~$ nslookup mos.ru
Server: 10.1.2.2
Address: 10.1.2.2#53
Non-authoritative answer:
Name: mos.ru
Address: 94.79.51.13
sofs@wireguard-internal-ru:~$ traceroute mos.ru
traceroute to mos.ru (94.79.51.12), 30 hops max, 60 byte packets
1 * * *
2 100.64.0.74 (100.64.0.74) 0.265 ms 100.64.0.63 (100.64.0.63) 0.249 ms 100.64.0.72 (100.64.0.72) 0.255 ms
3 * * *
4 78.25.67.142 (78.25.67.142) 5.462 ms 5.310 ms 5.435 ms
5 83.169.204.180 (83.169.204.180) 4.864 ms 4.987 ms 83.169.204.178 (83.169.204.178) 4.971 ms
6 83.169.204.115 (83.169.204.115) 3.852 ms * 83.169.204.119 (83.169.204.119) 4.092 ms
7 83.169.204.119 (83.169.204.119) 4.782 ms 83.169.204.115 (83.169.204.115) 4.365 ms 4.454 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Разобрался. Несмотря на то, что поддержка Я.Облака говорит, что все айпишники российские, это не так. А еще нельзя самому выбрать айпишник, выдают рандомно из диапазона публичных IP-адресов. Первоначально мой сервер находился в подсети 158.160.0.0/16, отсюда не дает доступа к некоторым русайтам (ржд, мосру и некоторым ЖКХ), опытным путем выяснил, что в подсети 51.250.0.0/17 всё работает.
Неточно, но кажется подсеть 158.160.0.0/16 для ru-central1-a зоны доступности, а 51.250.0.0/17 мне выпал, когда сменил зону на ru-central1-c.
Вдруг кому будет полезно.
Хороший гайд! Сам давно пользуюсь Wireguard и тоже делал для собственных нужд схему с частичным обходом блокировок для определённых ресурсов. Я начинал с похожего подхода, но пришёл по итогу к другой схеме.
На мой взгляд, проблема с тем, что необходимо оперировать именно IP-адресами - принципиальная. Выглядит всё, без погружения в детали и ежедневного использования очень чисто и красиво, но, рано или поздно, от поддержки такого решения либо очень устаёшь, либо всё равно приходится гнать через туннель всё.
Вот, например, я получил необходимые адреса через nslookup, и забил их в ipset который будет перенаправляться в туннель. Во-первых, адреса могут поменяться, и для этого требуется периодически обновлять список адресов/подсетей, заморачиваться с cron или другими планировщиками, настраивать софт и.т.д. Если этого не делать, то в какой-то момент ресурс перестанет открываться и придётся снова лезть в конфиги и перенастраивать, забивать новые адреса и т.д. Во-вторых, nslookup не даёт информации о том, куда именно будут ходить запросы, на какие поддомены или third-party ресурсы. Поэтому, приходится руками заходить в браузер, выцеплять отдельные домены, проверять их через nslookup и прописывать в список адресов, и все эти адреса тоже могут меняться, как и поддомены, а могут ещё и добавляться новые.
Должен отметить что wireguard клиенты у меня работают на роутере с очень ограниченным объёмом памяти, а не на полноценном компьютере, и поэтому, возможно, такое решение для меня предпочтительнее, потому что перезагружать базу geo-ip, перенастраивать policy based routing получается намного менее удобно, и можно легко упиреться в нехватку памяти. Получается необходимо базу обновлять на компьютере и руками загружать на роутер - это снова лишние заботы.
В конечном счёте я пришёл к более топорной, но, тем не менее, самой удобной для меня схеме: роутер держит постоянное соединение с несколькими wireguard серверами, и на роутере под каждый из них созданы отдельные сетевые интерфейсы. Весь трафик попадающий в эти интерфейсы уходит в соответствующий туннель. На роутере также подняты прокси сервера, трафик с которых перенаправляется на сетевые интерфейсы, с которых уже улетает в туннель. На своём ноутбуке я пользуюсь Firefox и его профилями. Под каждый профиль у меня забиты настройки прокси указывающие на нужный прокси сервер. В профиле по умолчанию настроек прокси нет. Лаунчеры запускающие окно Firefox с нужным профилем выставлены в общий список программ.
Получается, у меня на компьютере есть как бы разные "гео-браузеры". Если мне необходимо выйти в сеть с текущего адреса - я просто открываю обычный Firefox. Если я хочу посмотреть инстаграм и прочие ресурсы "загнивающего запада", то открываю FirefoxEU - сессию браузера с профилем, в котором через прокси весь трафик отправляется в wireguard туннель на роутере. Необходимых профилей с разными выходными адресами можно создать сколько потребуется под свои нужды. Таким образом, абсолютно весь трафик в отдельном открытом окне браузера улетает в туннель, но всё остальное работает как обычно. Не требуется постоянно обновлять списки IP-адресов, бояться утечки или что-то перенастраивать. Самое главное, на мой взгляд - это true unix way. Отдельные звенья цепи взаимозаменяемы - wireguard туннель можно заменить на ssh-туннель или что угодно ещё не меняя настроек на клиентах. DNS также можно шифровать чем душа возжелает - DNSCrypt, Dot, DoH - всё настраивается в одной точке и удобно взаимозаменяется. Опять же - можно поменять точку прокси и сделать всё это на выделенном сервере вместо роутера. На мой взгляд так получается удобнее.
Во-первых, адреса могут поменяться, и для этого требуется периодически обновлять список адресов/подсетей, заморачиваться с cron или другими планировщиками, настраивать софт и.т.д.
Ну так именно это и сделано: список подсетей обновляется по крону.
На своём ноутбуке я пользуюсь Firefox и его профилями. Под каждый профиль у меня забиты настройки прокси указывающие на нужный прокси сервер.
Совершенно не решает проблемы, например, с приложениями типа твиттера, инстаграма, стравы и так далее. ¯\_(ツ)_/¯ В браузере и так есть пара удобных расширения обхода блокировок.
На мой взгляд так получается удобнее.
Удобнее — это когда действий лишних по переключению окна браузера не надо производить, как по мне.
Все написано ОК, но с помощью "магии маршрутов" (с) это можно сделать совершенно с любым VPN и конкретно Wireguard тут абсолютно не при чем. Как уже выше писали, проблема не в том чтобы пустить траффик на определенные IP или сети мимо туннеля, а чтобы список этих IP (того же Сберонлайна) составить и поддерживать.
Мне лично видится только такое решение, как разжиться отдельным хостом с российским IP (можно VPS, можно отдельный личный комп) не подключенный к VPN, поставить туда Squid (или другой прокси) и написать PAC-скрипт, чтобы весь HHTP(s) на определенные URL пускать через него. Возможно, подойдет и локальная виртуалка с "Bridged Adapter" для VirtualBox или "External Virtual Switch" для Hyper-V, но тут я не уверен, надо пробовать. Если руки до этого дойдут, то отпишусь.
И, кстати, еще ("за что купил, за то и продаю"), я слышал, что есть прецеденты, когда люди пытались из-за границы зайти в Сберонлайн через российский VPN, и их не просто отшивало, а напрочь блокировало им и аккаунт Сберонлайна и даже все их пластиковые карточки. Уж не знаю, как Сбер их определял, но, возможно, с этим стоит тоже быть осторожнее.
с помощью «магии маршрутов» (с) это можно сделать совершенно с любым VPN и конкретно Wireguard тут абсолютно не при чем
А что, кто-то говорил, что для этого обязателен Wireguard?
Ну, чтобы не вносить сумятицу, можно было бы две статьи тиснуть:
Как обходить РКН с помощью Wireguard.
Как обходить свой собственный Wireguard с помощью таблицы маршрутизации :D
Кстати проверил на виртуалке (VirtualBox, Ubuntu Server 22.04 с "bridged" подключением к сети). Траффик с виртуалки идет мимо VPN, что и требуется. Теперь просто поставлю на ней Squid и буду на "плохие" сайты ходить через него. Можно или отдельный браузер выделить для этого, прописав там кастомный прокси, можно, как я писал выше, PAC написать. C PAC, правда, есть еще проблема с которой уже сталкивался - ни Edge, ни Chrome не берут его просто с диска как "file://bla-bla-bla", поэтому для них надо еще его откуда-нибудь отдавать по http(s).
Мне нравится элегантность решения в том, что для "конечного пользователя" весь обход блокировок и блокировка рекламы выглядит просто как... подключился к сети. Все. Ни "специальных браузеров", ни виртуалбокосов с отдельной маршрутизацией, ни pac-скриптов, ни ползунков "поднять VPN!", просто подключился к сети и все... Как результат - не нужно настраивать маме новый телефон\планшет (она у меня их любит покупать просто потому что захотелось), ни ноут ребенку... И жене после очередного убийства винды - нужно просто переустановить винду)) У меня не айтишная семья... Реализовал что-то подобное в 2014 году на базе BGP от Антизапрет и Микротика... Сейчас думаю нужно становиться на модно-молодежную стезю и пересобрать схему именно по принципу "ру-сегмент в провайдера, остальное в впн"
спасибо за статью!
печаль в том, что испробовав двух хостеров с серверами в России (ishosting и ruvds), многие сервисы всё-равно говорят, что "у вас включён vpn" (кинопоиск, тот же сбермаркет, ozon) и соответствующие последствия этого
в итоге, вариант рабочий скорее только если internal-сервер таки это твой домашний сервер
Спасибо, шикарная статья, особенно порадовал источник географии ip адресов и скрипт его обработки, ну и конечно прогресс-бар :)
Я на андроиде пока живу с ikev4. СильныйЛебедь позволяет выбрать какие приложения пускать через vpn. Но на заметку взял. Благодарен!
Укрощаем одноглазого змея. Разбираемся с WireGuard и делаем свой умный VPN