Ну ладно, про «полюбил» — это преувеличение. Скорее «смог сосуществовать с».
Как вы все знаете, с 16 апреля 2018 года Роскомнадзор крайне широкими мазками блокирует доступ к ресурсам в сети, добавляя в "Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено" (по тексту — просто реестр) по /10 иногда. В результате граждане Российской Федерации и бизнес страдают, потеряв доступ к необходимым им совершенно легальным ресурсам.
После того, как в комментариях к одной из статей на Хабре я сказал, что готов помочь пострадавшим с настройкой схемы обхода, ко мне обратились несколько человек с просьбой о такой помощи. Когда у них всё заработало, один из них порекомендовал описать методику в статье. Поразмыслив, решил нарушить свое молчание на сайте и попробовать в кои-то веки написать что-то промежуточное между проектом и постом в Facebook, т.е. хабрапост. Результат — перед вами.
Disclaimer
Поскольку публиковать способы обхода блокировок доступа к информации, запрещенной на территории Российской Федерации, не очень законно, целью этой статьи будет рассказать о методе, позволяющем автоматизировать получение доступа к ресурсам, разрешенным на территории Российской Федерации, но из-за чьих-то действий недоступным напрямую через вашего провайдера. А доступ к другим ресурсам, получаемый в результате действий из статьи, является досадным побочным эффектом и целью статьи ни в коем случае не является.
Также, поскольку я по профессии, призванию и жизненному пути прежде всего сетевой архитектор, программирование и линуксы не являются моими сильными сторонами. Поэтому, безусловно, скрипты можно написать лучше, вопросы безопасности в VPS можно проработать глубже и т.д. Ваши предложения будут приняты с благодарностью, если они будут достаточно детальны — с удовольствием добавлю их в текст статьи.
TL;DR
Автоматизируем доступ к ресурсам через существующий у вас туннель, используя копию реестра и протокол BGP. Цель — убрать весь трафик, адресованный заблокированным ресурсам, в туннель. Минимум объяснений, в основном пошаговая инструкция.
Что вам для этого потребуется
К сожалению, этот пост не для каждого. Для того, чтобы воспользоваться этой методикой, вам нужно будет собрать вместе несколько элементов:
- У вас должен быть linux-сервер где-то за пределами поля блокировок. Или хотя бы желание такой сервер завести — благо это сейчас стоит от $9/год, а возможно и меньше. Метод также подходит, если у вас есть отдельный VPN-туннель, тогда сервер может располагаться и внутри поля блокировок.
- Ваш роутер должен быть достаточно умным, чтобы уметь
- любой нравящийся вам VPN-клиент (я предпочитаю OpenVPN, но это может быть PPTP, L2TP, GRE+IPSec и любой другой вариант, создающий туннельный интерфейс);
- протокол BGPv4. Что означает, что для SOHO это может быть Mikrotik или любой роутер с OpenWRT/LEDE/аналогичными кастомными прошивками, позволяющими установить Quagga или Bird. Использование PC-роутера также не возбраняется. В случае энтерпрайза смотрите поддержку BGP в документации к вашему бордер-роутеру.
- Вы должны иметь представление о использовании Linux и сетевых технологиях, в том числе о протоколе BGP. Или хотя бы хотеть получить такое представление. Поскольку объять необъятное в этот раз я не готов, некоторые непонятные для вас моменты вам придется изучить самостоятельно. Впрочем, на конкретные вопросы, конечно же, отвечу в комментариях и вряд ли окажусь единственным отвечающим, так что не стесняйтесь спрашивать.
Что используется в примере
- Копия реестра — из https://github.com/zapret-info/z-i
- VPS — Ubuntu 16.04
- Сервис маршрутизации — bird 1.6.3
- Маршрутизатор — Mikrotik hAP ac
- Рабочие папки — поскольку работаем от рута, бОльшая часть всего будет размещаться в домашней папке рута. Соответственно:
- /root/blacklist — рабочая папка со скриптом компиляции
- /root/z-i — копия реестра с github
- /etc/bird — стандартная папка настроек сервиса bird
- Внешним IP-адресом VPS с сервером маршрутизации и точкой терминации туннеля принимаем 194.165.22.146, ASN 64998; внешним IP-адресом роутера — 81.177.103.94, ASN 64999
- IP адреса внутри туннеля — 172.30.1.1 и 172.30.1.2 соответственно.
Безусловно, вы можете использовать любые другие роутеры, операционные системы и программные продукты, корректируя решение под их логику.
Кратко — логика решения
- Подготовительные действия
- Получаем VPS
- Поднимаем туннель от маршрутизатора к VPS
- Получаем и регулярно обновляем копию реестра
- Устанавливаем и настраиваем сервис маршрутизации
- Создаем на основании реестра список статических маршрутов для сервиса маршрутизации
- Подключаем роутер к сервису и настраиваем отправку всего трафика через туннель.
Собственно решение
Подготовительные действия
На просторах сети есть множество сервисов, предоставляющих VPS за крайне умеренные деньги. Пока я нашел и пользуюсь вариантом за $9/год, но даже если не особо заморачиваться — вариантов за 1E/месяц много на каждом углу. Вопрос выбора VPS лежит далеко за пределами этой статьи, поэтому если кому-то что-то непонятно в этом — спросите в комментариях.
Если вы будете использовать VPS не только для сервиса маршрутизации, но и для терминации на нем туннеля — вам нужно поднять этот туннель и, практически однозначно, настроить NAT для него. В сети большое количество инструкций по этим действиям, здесь я их повторять не буду. Основное требование к такому туннелю — он должен создавать на вашем роутере, поддерживающем туннель в сторону VPS, отдельный интерфейс. Этому требованию соответствует большинство используемых технологий VPN — например, OpenVPN в tun режиме прекрасно подходит.
Получение копии реестра
Как говорил Джабраил, "Тот, кто нам мешает, тот нам поможет". Раз уж РКН создает реестр запрещенных ресурсов, грешно было бы не воспользоваться этим реестром для решения нашей задачи. Копию реестра мы будем получать с github.
Заходим на ваш линукс-сервер, проваливаемся в контекст root'а (sudo su -) и устанавливаем git, если он еще не установлен.
apt install gitПереходим в домашнюю директорию и вытягиваем копию реестра.
cd ~ && git clone --depth=1 https://github.com/zapret-info/z-i Настраиваем обновление по крону (у меня раз в 20 минут, но вы можете выбрать любой интересный вам интервал). Для этого запускаем crontab -e и добавляем в него следующую строку:
*/20 * * * * cd ~/z-i && git pullПодключаем хук, который будет создавать файлы для сервиса маршрутизации после обновления реестра. Для этого создаем файл /root/z-i/.git/hooks/post-merge со следующим содержимым:
#!/usr/bin/env bash
changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"
check_run() {
echo "$changed_files" | grep --quiet "$1" && eval "$2"
}
check_run dump.csv "/root/blacklist/makebgp"и не забываем сделать его исполняемым
chmod +x /root/z-i/.git/hooks/post-mergeСкрипт makebgp, на который ссылается хук, мы создадим чуть позже.
Установка и настройка сервиса маршрутизации
Устанавливаем bird. К сожалению, выложенная в репозиториях Ubuntu на данный момент версия bird по свежести сопоставима с фекалиями археоптерикса, поэтому нам необходимо предварительно добавить в систему официальный PPA разработчиков ПО.
add-apt-repository ppa:cz.nic-labs/bird
apt update
apt install birdПосле этого сразу отключаем bird для IPv6 — в этой инсталляции он для нас не потребуется.
systemctl stop bird6
systemctl disable bird6Ниже приведен минималистичный файл конфигурации сервиса bird (/etc/bird/bird.conf), которого нам вполне хватит (и еще раз напоминаю, что никто не запрещает развивать и дотюнивать идею под ваши собственные потребности)
log syslog all;
router id 172.30.1.1;
protocol kernel {
scan time 60;
import none;
# export all; # Actually insert routes into the kernel routing table
}
protocol device {
scan time 60;
}
protocol direct {
interface "venet*", "tun*"; # Restrict network interfaces it works with
}
protocol static static_bgp {
import all;
include "pfxlist.txt";
#include "iplist.txt";
}
protocol bgp OurRouter {
description "Our Router";
neighbor 81.177.103.94 as 64999;
import none;
export where proto = "static_bgp";
local as 64998;
passive off;
multihop;
}
router id — идентификатор роутера, визуально выглядящий как IPv4-адрес, но им не являющийся. В нашем случае может быть вообще любым 32-битным числом в формате IPv4-адреса, но хорошим тоном является указывать там именно IPv4-адрес вашего устройства (в данном случае VPS).
protocol direct определяет, какие интерфейсы будут работать с процессом маршрутизации. В примере дана пара примеров имен, можно добавлять и другие. Можно и просто удалить строку, в этом случае сервер будет слушать все доступные интерфейсы с IPv4-адресом.
protocol static — наше волшебство, которое подгружает из файлов списки префиксов и ip-адресов (которые на самом деле, конечно, префиксы по /32) для последующего анонса. Откуда появляются эти списки — будет рассмотрено ниже. Обратите внимание, что загрузка ip-адресов по умолчанию закомментирована, причина этого — большой объем выгрузки. Для сравнения, в списке префиксов на момент написания статьи 78 строк, а в списке ip-адресов — 85898. Настоятельно рекомендую запускаться и отлаживаться только на списке префиксов, а включать или не включать в дальнейшем подгрузку ip — решать после экспериментов со своим роутером. Далеко не каждый из них легко переварит 85 тысяч записей в таблице маршрутизации.
protocol bgp, собственно, настраивает bgp-пиринг с вашим роутером. ip-адрес — это адрес внешнего интерфейса роутера (либо адрес интерфейса туннеля со стороны роутера), 64998 и 64999 — номера автономных систем. Их в данном случае можно назначить в виде любых 16-битных чисел, но хорошим тоном является использование номеров AS из приватного диапазона, определенного RFC6996 — 64512-65534 включительно (существует формат 32-битных ASN, но в нашем случае это точно излишество). Описанная конфигурация использует eBGP пиринг, при котором номера автономных систем сервиса маршрутизации и роутера должны различаться.
Как вы можете заметить, сервису нужно знать IP-адрес роутера, поэтому если у вас динамический или немаршрутизируемый private (RFC1918) или shared (RFC6598) адрес, варианта поднимать пиринг на внешнем интерфейсе у вас нет, но внутри туннеля сервис все равно будет работать.
Достаточно прозрачно также, что с одного сервиса вы можете обеспечивать маршрутами несколько разных роутеров — достаточно продублировать настройки для них копированием секции protocol bgp со сменой IP-адреса соседа. Именно поэтому в примере показаны настройки для пиринга вне туннеля, как наиболее универсальные. Убрать их в туннель несложно, поменяв соответственно IP-адреса в настройках.
Обработка реестра для сервиса маршрутизации
Сейчас нам надо, собственно, создать списки префиксов и ip-адресов, которые на предыдущем этапе упомянуты в protocol static. Для этого мы берем файл реестра и делаем из него нужные нам файлы следующим скриптом, размещаемым в /root/blacklist/makebgp
#!/bin/bash
cut -d";" -f1 /root/z-i/dump.csv| tr '|' '\n' | tr -d ' ' > /root/blacklist/tmpaddr.txt
cat /root/blacklist/tmpaddr.txt | grep / | sed 's_.*_route & reject;_' > /etc/bird/pfxlist.txt
cat /root/blacklist/tmpaddr.txt | sort | uniq | grep -Eo "([0-9]{1,3}[\.]){3}[0-9]{1,3}" | sed 's_.*_route &/32 reject;_' > /etc/bird/iplist.txt
/etc/init.d/bird reload
logger 'bgp list compiled'Не забываем сделать его исполняемым
chmod +x /root/blacklist/makebgpТеперь можно запустить его вручную и пронаблюдать появление файлов в /etc/bird.
Вероятнее всего, в этот момент bird у вас не работает, поскольку на предыдущем этапе вы ему предложили поискать файлы, которых еще не было. Поэтому запускаем его и контролируем, что он запустился:
systemctl start bird
birdc show routeВывод второй команды должен показать около 80 записей (это на данный момент, а когда будете настраивать, всё будет зависеть от рьяности РКН в блокировках сетями) вида приблизительно такого:
54.160.0.0/12 unreachable [static_bgp 2018-04-19] * (200)Команда
birdc show protocolпокажет состояние протоколов внутри сервиса. Пока вы не настроили роутер (см. следующий пункт), протокол OurRouter будет в состоянии start (фазы Connect или Active), а после успешного подключения перейдет в состояние up (фаза Established). Например, в моей системе вывод этой команды выглядит следующим образом:
BIRD 1.6.3 ready.
name proto table state since info
kernel1 Kernel master up 2018-04-19
device1 Device master up 2018-04-19
static_bgp Static master up 2018-04-19
direct1 Direct master up 2018-04-19
RXXXXXx1 BGP master up 13:10:22 Established
RXXXXXx2 BGP master up 2018-04-24 Established
RXXXXXx3 BGP master start 2018-04-22 Connect Socket: Connection timed out
RXXXXXx4 BGP master up 2018-04-24 Established
RXXXXXx5 BGP master start 2018-04-24 Passive
Подключение роутера
Все уже, наверное, устали читать эту портянку, но мужайтесь — конец близок. Тем более, что в этом разделе я не смогу дать пошаговую инструкцию — для каждого производителя она будет своя.
Однако могу показать пару примеров. Основная логика — поднять BGP-пиринг и на все получаемые префиксы навесить nexthop, указывающий на наш туннель (если нужно выводить трафик через p2p интерфейс) или ip-адрес некстхопа, если трафик будет уходить в ethernet).
Например, на Mikrotik в RouterOS это решается следующим образом
/routing bgp instance set default as=64999 ignore-as-path-len=yes router-id=172.30.1.2
/routing bgp peer add in-filter=dynamic-in multihop=yes name=VPS remote-address=194.165.22.146 remote-as=64998 ttl=default
/routing filter add action=accept chain=dynamic-in protocol=bgp comment="Set nexthop" set-in-nexthop=172.30.1.1а в Cisco IOS — вот так
router bgp 64999
neighbor 194.165.22.146 remote-as 64998
neighbor 194.165.22.146 route-map BGP_NEXT_HOP in
neighbor 194.165.22.146 ebgp-multihop 250
!
route-map BGP_NEXT_HOP permit 10
set ip next-hop 172.30.1.1В том случае, если один и тот же туннель используется и для BGP-пиринга, и для передачи полезного трафика, выставлять nexthop не обязательно, он выставится правильно средствами протокола. Но если выставите вручную — хуже от этого тоже не будет.
На других платформах вам придется разбираться в конфигурировании самостоятельно, но если возникнут затруднения — пишите в комментариях, попробую помочь.
После того, как у вас поднялась BGP-сессия, прилетели и установились в таблицу маршруты на крупные сети, трафик на адреса из них пошел и счастье близко, вы можете вернуться к сервису bird и попробовать раскомментировать там запись, подключающую список ip-адресов, выполнить после этого
systemctl reload birdи посмотреть, как ваш роутер перенес эти 85 тысяч маршрутов. Будьте готовы отключать и думать, что с этим делать :)
Итого
Чисто теоретически после выполнения вышеописанных действий у вас появился сервис, который автоматически перенаправляет трафик к забаненным в РФ IP-адресам мимо системы фильтрации.
Его, конечно, можно дорабатывать. Например, достаточно легко сделать суммаризацию списка ip-адресов через решения на perl или python. Простой скрипт на perl, делающий это с помощью Net::CIDR::Lite, превращает 85 тысяч префиксов в 60 (не тысяч), но, естественно, перекрывает гораздо бОльший диапазон адресов, чем заблокировано.
Поскольку сервис работает на третьем уровне модели ISO/OSI, он не спасет от блокировок по сайту/странице, если оно резолвится не в тот адрес, который записан в реестре. Но вместе с реестром из github прилетает файл nxdomain.txt, который несколькими штрихами скрипта легко превращается в источник адресов для, например, плагина SwitchyOmega в Chrome.
Необходимо также упомянуть, что решение требует дополнительной заточки, если вы не просто пользователь интернета, но и публикуете какие-то ресурсы от себя (например, на этом подключении работает веб-сайт или почтовый сервер). Средствами роутера необходимо жестко привязать исходящий трафик от этого сервиса в ваш публичный адрес, иначе вы потеряете связность с теми ресурсами, которые покрываются получаемым роутером списком префиксов.
При возникновении вопросов — задавайте, готов отвечать.
UPD. Спасибо navion за дополнительный параметр для git, позволяющий уменьшить объемы скачиваемого.
UPD2. Коллеги, похоже, я совершил ошибку, не добавив в статью инструкцию по настройке туннеля между VPS и роутером. Очень много вопросов вызваны этим.
На всякий случай еще раз отмечу — подразумевается, что перед началом действий по этому руководству вы уже настроили VPN-туннель в нужном вам направлении и проверили его работоспособность (например, завернув туда трафик по дефолту или статикой). Если эта фаза у вас еще не выполнена, выполнять действия из статьи не очень имеет смысл. Пока у меня своего текста на этот счет нет, но если погуглить "настройка сервера OpenVPN" вместе с именем операционной системы, установленной на VPS, и "настройка клиента OpenVPN" с именем вашего маршрутизатора — вероятнее всего, вы найдете некоторое количество статей на этот счет, в том числе и на хабре.
UPD3. Unsacrificed написал код, который делает из dump.csv результирующий файл для bird с опциональной суммаризацией ip-адресов. Поэтому раздел "Обработка реестра для сервиса маршрутизации" можно заменить на вызов его программы. https://habr.com/post/354282/#comment_10782712
Комментарии (193)
firk
26.04.2018 11:50Обычный туннель до какой-нить точки выхода проще и ничем не хуже. Непонятно зачем тут BGP прикрутили.
Furriest Автор
26.04.2018 11:55+3Смысл в том, чтобы отправлять в туннель не весь трафик, а только трафик к заблокированным ресурсам. И не тратить время на постоянное отслеживание «что же еще заблокировал РКН». По BGP и передается информация, что именно заблокировано.
Chugumoto
26.04.2018 12:51а смысл? на микротике создаем список адресов, маркируем трафик что туда идти должен и для этого отмаркированного трафика пакеты кидаем в туннель, а не напрямую… проще же…
achekalin
26.04.2018 14:19Вы точно прочитали пост? А на основании чего маркировать? По API грузить address lists в микротик? BGP здесь выступает как механизм подачи (передачи) списка адресов.
Chugumoto
26.04.2018 15:26-7mikbill.blogspot.ru/2016/05/rkn-mikrotik.html
долго гуглить лень, а самому мне хватает и статического списка адресов…Phil_itch
26.04.2018 19:13+2А ссылку не лень проверить перед «выкладыванием»? Страничка то открывается, а вот файл с нее левый качается.
Chugumoto
26.04.2018 19:27-6лень :-)
но можете и сами погуглить… было что-то еще…
но опять же не уверен, что то, откуда качался список, еще живо…
vilkovsky
27.04.2018 15:12как автору сайта и статьи mikbill.blogspot.ru интересно, что там не то качается? А насчет реализации это не совсем то, так как там список нужно получать законным способом, выгрузкой с ркн. Немного не сходится с тем, чтобы получать список платно для того чтобы обходить. Но если уже получать выгрузку, то скрипт решит проблему нагрузки в момент заливки, так как просто удаление/перезаливка на микротик ставит оборудование в ступор на несколько минут
mohax_kh_ua
26.04.2018 14:41+2Для микротика я так и делал, но здесь представлен способ, который не относится к конкретному вендору. BGP можно поднять и с Cisco, и с linux, и не городить отдельные скрипты с списком статических маршрутов для каждого решения.
Chugumoto
26.04.2018 15:29-2да. но обратите внимание тогда, что это решение таки относится к конкретному «вендору», раз на впс у человека убунта видимо, хотя может и дебиан…
а у меня например за пределами стоит облачная роутерос…Furriest Автор
26.04.2018 15:32Крутить роут-демон можно в любом месте шарика, в том числе и не за пределами. Но да, если в принципе ни одного linux/unix в досягаемости нет — то моё решение не подойдет.
elve
26.04.2018 14:45+1Вы статью читали? А скриптик в ней читали? Информация о том что заблокировано передается через файлик dump.xml. Который надо регулярно скачивать, парсить и закидывать в bird. Спрашивается — а зачем тогда этот bird вообще нужен?
Chugumoto
26.04.2018 15:30ви таки хотите сказать, что тот гитхаб — это гитхаб ркн? нет… а значит может случиться так, что список тот всеравно будет не актуальным…
anprs
27.04.2018 07:54+1Как-то этот и последующие Ваши комменты очень сильно расходятся с disclaimer'ом. Не подтянут? :)
sergeyboev
26.04.2018 14:41Для одного клиента наверное смысла нет, а если запускать десяток, решение тиражируется автоматически
Furriest Автор
26.04.2018 14:42И для одного клиента тоже удобно — не нужно следить, кого ещё РКН заблокировал за последний час. Но каждому своя степень удобства нужна, безусловно.
elve
26.04.2018 12:00+1Статью прочел, но так и не нашел ответа на вопрос — зачем bgp? Какая такая радость от динамической маршрутизации через один единственный канал?
iborzenkov
26.04.2018 12:20Канала два — обычный инет и впн, вот bgp у нас и определяет что в впн пускать.
Аналогично кстати антизапрет поступает — у них приходят пачки маршрутов.
navion
26.04.2018 12:49Чтобы не рисовать страшные роут-мапы на роутере и не пускать весь трафик через VPN.
elve
26.04.2018 14:40Так страшные роут-мапы остаются. В скрипте же все написано.
Furriest Автор
26.04.2018 14:43В скрипте остается один роут-мап, по идее. Смысл — настроить один раз и не следить, что изменилось у РКН.
elve
26.04.2018 14:52+1Каким образом, по вашему мнению, это достигается? Один раз стянули dump.xml, распарсили, выгрузили и больше не трогаем? Так что ли?
Furriest Автор
26.04.2018 14:55+5Нет. Для того у нас и BGP. На сервер вытягиваем новые (и только новые) версии дампа, они автоматически парсятся — и на роутер прилетает актуальный список. На роутере никаких страшных роутмапов, просто «всё, что изучено по bgp, заворачивать в туннель». В этом, собственно, идея и есть — роутер с его не очень-то обычно производительным процессором не надо насиловать постоянными обновлениями настроек, он всегда в одной конфигурации.
elve
26.04.2018 15:38Теперь понятна идея. Держать эти страшные завалы маршрутов не на флешке роутера, а только в оперативке. Спасибо за разъяснение. Так и правда будет оптимальнее.
Но маршруты же все равно прилетают на роутер, если я правильно понимаю конфиг в статье =).
shaivam
27.04.2018 13:48а что мешает без bgp пушить средствами опенвпн динамический список машрутов?
Furriest Автор
27.04.2018 13:50А он пушится не только при подключении? Или при каждом изменении листа разваливать туннель придется?
Если можно пушить на уже подключенный — то да, вполне себе решение. Я всё равно предпочту bgp, потому что там можно играть с принимаемыми префиксами, фильтровать их и посылать в разные некстхопы, но для большинства такой метод с openvpn, конечно, подойдет.
navion
26.04.2018 18:29На ASA не остаются и даже можно включить суммаризацию маршрутов:
router bgp 64999 bgp log-neighbor-changes address-family ipv4 unicast neighbor 192.168.10.100 remote-as 64998 neighbor 192.168.10.100 activate auto-summary no synchronization exit-address-family
Pilat
26.04.2018 12:37Как Вы думаете, имеет ли смысл реализовать другой подход для домашнего компьютера:
- получать список адресов
- просматривать логи соединений с внешними ресурсами
- если было соединение к блокированному адресу, вносить его в iptables и перенаправлять на внешний VPN или Tor
?
Причина делать именно так — нет достаточно мощного роутера или даже нет внешнего VPN (вот у меня они есть/были, но попали под блокировку, и бегать искать новые не хочется).
vampire333
26.04.2018 13:22я на своем zyxel keenetic start подключил впн с приоритетом выше, чем то что дает провайдер.
завернул весь трафик в впн кроме определенных адресов (в онлайн играх увеличивается пинг через впн). Решение простое и не требует спец. навыков. трафик разделил маршрутами, их всего 5.
Однако, если у вас выделенный внешний адрес, то с маршрутами придется попотеть.
achekalin
26.04.2018 14:06Если у вас есть (свой) внешний VPS с OpenVPN сервером на нем, то никто не мешает получать там, на нем, список адресов, и вписывать в файл конфигурации openvpn сервера строчки маршрутизации, которые push-атся на клиентов, и перезагружать конфигу сервера. Таким образом, на локальном компе маршрутизация обновится «сама собой», и маршруты на
проблемныепоказавшиеся подозрительными судам сети и адреса будут вести в туннель.
Это, конечно, если не хочется завернуть в туннель всё, от греха.Pilat
26.04.2018 15:45+1Блокировок 60.000 строк — ни VPS, ни мой сервер, ни скорее всего OpenVPN просто так не понтянут такие объёмы.
achekalin
26.04.2018 15:53Ниже приведенный скрипт по загрузке acl в микротик
Заголовок спойлераcurl -s https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv | cut -d";" -f1 | tr '|' '\n' | grep '/' | tr -d ' ' | sort -k1 -n | sed 's/\(^\)/\/ip firewall address-list add list=rkn address=/g' | ssh admin@MIKROTIK_IPguglez
28.04.2018 11:56+1Как в микротике можно заворачивать в другой туннель все из address list-a?
achekalin
28.04.2018 11:59IP -> Firewall -> Mangle как средство развешивания меток (если соединение идет на адрес из этого адрес-листа, повесить route mark такой-то), а затем в IP -> Routes создать маршрут с нужной меткой роутинга.
Примеров в интере много, на вскидку нашел vasilevkirill.com/MikroTik/1 какой-то такой.
rrpv
27.04.2018 13:51Для передачи маршрутов в конфиге OpenVPN используется опция
route, которая требует "широкий" формат маски в виде 255.255.x.x. Как его получить из "короткого" стандартными утилитами — я не изучал, но в силу специфики томского интернета у меня завалялся готовый скрипт, который когда-то использовался для обратной цели — передать список маршрутов, которые в туннель заворачивать не надо.
Скрипте выложен на Github (https://github.com/rpv-tomsk/iplist). Умеет аггрегировать подсетки, формировать конфиг OpenVPN. Написан на Perl, использует Net::CIDR::Lite.
Судя по дате изменения файла, последний раз он был изменен 7 лет назад, поэтому сильно не пинайте, если будет работать не так, как ожидается. Перед публикацией я его слегка причесал и протестировал.
Итак, как выгрузить список префиксов в OpenVPN:
1) В конфигурации OpenVPN-сервера указываем путь к скрипту, который сформирует файл динамической конфигурации:
client-connect ./client-connect
2) Содержимое скрипта размещаем в файле /etc/openvpn/client-connect :
#!/bin/bash TYPE="$script_type" CCD="$1" if [ "$TYPE" = "client-connect" ]; then cp /etc/openvpn/blacklist $CCD exit 0 fi exit 0
3) В конфигурации OpenVPN-клиента необходимо прописать опцию max-routes:
max-routes 150
Надеюсь, что такого значения будет достаточно.
4) Скачиваем утилиту и формируем файл /etc/openvpn/blacklist с директивами выставления маршрутов на клиенте:
#Взято из статьи cut -d";" -f1 /root/z-i/dump.csv| tr '|' '\n' | tr -d ' ' > /root/blacklist/tmpaddr.txt #Путь к скачанной утилите iplist_ovpn необходимо скорректировать cat /root/blacklist/tmpaddr.txt | grep / | ./iplist_ovpn -vg > /etc/openvpn/blacklist
Перезапускать OpenVPN-сервер после изменения /etc/openvpn/blacklist не требуется.
Маршруты прилетают на клиент только при подключении, поэтому для обновления необходимо переподключение клиента — в этом минус решения, по сравнению с получением маршрутов средствами BGP или другой динамической маршрутизации.
Если что-то не заработает — смотрим в логи, они бывают полезны.symbix
27.04.2018 14:17Как его получить из "короткого" стандартными утилитами
cdr2mask () { # Number of args to shift, 255..255, first non-255 byte, zeroes set -- $(( 5 - ($1 / 8) )) 255 255 255 255 $(( (255 << (8 - ($1 % 8))) & 255 )) 0 0 0 [ $1 -gt 1 ] && shift $1 || shift echo ${1-0}.${2-0}.${3-0}.${4-0} }
(SO)
Vindicar
26.04.2018 13:30+1Если интересует только браузер, то того же эффекта можно добиться гораздо проще через механизм proxy autoconfig. Забираем список блокированных адресов по крону, генерируем скрипт proxy.pac и отдаём любым HTTP-сервером внутрь нашего VPN. В браузере прописываем URL этого файла в соотвествующую настройку.
Однако с учетом того, что Роскомпозор начал ломать вещи типа Google Playmarket, этого может оказаться недостаточно, и потребуются меры посерьёзнее.
Я только не очень понимаю один момент. Необходимость в BGP, как я понял, объясняется тем, что список подсетей формируется на удалённом сервере, а потом пересылается роутеру через этот протокол.
Но раз уж мы говорим про роутеры на OpenWRT, то не проще ли роутеру брать список самостоятельно и загонять его в тот же iptables? На худой конец, поднимите зеркало списка, отдаваемое внутрь VPN, чтобы роутер гарантированно мог его получить при наличии доступа к серверу.Chugumoto
26.04.2018 13:38в статье было про микротиковский хап ац :)
скрипты то и т.д. на нем есть, но не так много…
Dr_Sigmund
29.04.2018 06:18proxy.pac можно положить на локальную машину, а URL задать в виде «file://...»
Vindicar
29.04.2018 12:24Это верно, если локальная машина одна, или если VPN не под полным контролем (например от VPN провайдера).
В противном случае проще озадачить созданием proxy.pac именно сервер.
1. все клиенты смогут этот файл забрать, нет нужды на каждом из них настраивать генерацию.
2. если дамп реестра сам будет заблокирован, VPN сервер сможет его достать (он же вне зоны блокировок).
3. если VPN не поднят, то proxy.pac ничем не поможет. Нужно тестировать, но я подозреваю что если браузер не сможет открыть proxy.pac, он просто переключится на режим без прокси. А вот если файл будет доступен, а прокси — нет, поведение может отличаться.
fdroid
26.04.2018 13:35Интересно. Check list:
Mikrotik — есть
VPS Ubuntu Server 16.04 — есть
Заблокированные безобидные ресурсы типа реп Mono — есть
Вечером попробую реализовать. И вообще — такого рода материалы пора уже сохранять в офлайне и беречь.lorc
26.04.2018 17:42Я просто накидал в микротике статических маршрутов через VPN к тем адресам, которые мне нужны и все. Действительно непонятно зачем BGP, если таким же скриптом можно насоздавать статических маршрутов и не парится с лишними сущностями.
fdroid
26.04.2018 22:59upd: Попробовал — не взлетело, не работает обход, что-то я упускаю, проверял на репо download.mono-project.com/repo/ubuntu/dists/stable-xenial/InRelease, который (позор ркн) теперь доступен только через vpn. Повторил всё один-в-один как в статье (IP, естественно, только свои подставил, но даже ID не менял) — не работает. Сообразил (надеюсь, правильно) открыть tcp 179 порт на микротике. Не помогло. Несколько раз проверил все конфиги — соединение со стороны микротика в статусе active, со стороны VPS — connection refused или что-то в этом роде. Соединение стало estabilished только после того как в микротике поставил галочку Multihop в настройке Peer. Процессор микротика на какое-то время загрузился на 100%, половина оперативной памяти заполнилась, потом CPU пришёл в себя, RAM там и осталась заполненной наполовину. Бинго, подумал я. Но не тут-то было — репо Mono как не открывался так и не открывается. Подключаемся через vpn — открывается со свистом. Epic fail.
Furriest Автор
27.04.2018 12:20Покажите:
1) куда у вас резолвится download.mono-project.com с компьютера (nslookup download.mono-project.com).
2) результат команды /ip route check <и здесь ip, в который резолвится указанный сайт> в терминале Mikrotik.
У меня он резолвится в 152.199.20.1 и этот адрес находится в iplist.txt, поэтому если вы его подключили, убрав описанную в тексте # в include iplist.txt, роутер должен отправлять трафик на него через туннель.
Сам туннель работоспособен, если в него дефолт направить, например?fdroid
27.04.2018 17:081)
C:\Users\fdroid>nslookup download.mono-project.com
TхЁтхЁ: UnKnown #what?!
Address: 192.168.0.1
Не заслуживающий доверия ответ:
Lь : cs9.wpc.v0cdn.net
Addresses: 2606:2800:133:206e:1315:22a5:2006:24fd
152.199.20.1
Aliases: download.mono-project.com
mono-project.azureedge.net
mono-project.ec.azureedge.net
2)
[fdroid@RB951Ui-2HnD] > /ip route check 152.199.20.1
status: ok
interface: wan
nexthop: #тут IP из моей домашней провайдерской подсети, но не мой, указан в Route List -> Nexthops.
В iplist.txt IP присутствует:
route 152.199.20.1/32 reject;
В конфиге лист подключен:
protocol static static_bgp {
import all;
include "pfxlist.txt";
include "iplist.txt";
}
Сам туннель работоспособен, если в него дефолт направить, например?
Как это проверить? Я сварщик ненастоящий, много не понимаю(fdroid
27.04.2018 17:40upd: nexthop IP — это шлюз моего провайдера, он же на скринах везде закрашен. У меня белая статика из того же диапазона.
Furriest Автор
27.04.2018 17:50п.2 означает, что роутер имеет маршрут на этот адрес через wan, а не через туннель.
Есть ли в таблице маршрутизации маршруты, полученные по BGP? (путь в винбоксе — ip — routes и смотреть в левом столбце маленькую букву b, что-то типа DAb).
Если маршрутов нет — возможно, bgp не поднялся. Можно посмотреть на сервере результаты команды birdc sh proto — какое состояние у него. Если он Established — возможно, не установился или неправильно установился фильтр: Routing — Filters, проверить что Action — Accept и Set in nexthop указывает на интерфейс туннеля (можно и на адрес с другой стороны, но в случае туннеля лучше указывать интерфейс).Furriest Автор
27.04.2018 17:51Надо просто переписать фильтр в интерфейс вместо адреса и всё заработает.
fdroid
27.04.2018 19:28Есть ли в таблице маршрутизации маршруты, полученные по BGP? (путь в винбоксе — ip — routes и смотреть в левом столбце маленькую букву b, что-то типа DAb).
да, они все DAb (это же нужно смотреть тот раздел, скрин которого я выше приложил, я правильно понимаю?)
Можно посмотреть на сервере результаты команды birdc sh proto — какое состояние у него.
root@vps:~# birdc show protocol
BIRD 1.6.3 ready.
name proto table state since info
kernel1 Kernel master up 2018-04-26
device1 Device master up 2018-04-26
direct1 Direct master up 2018-04-26
static_bgp Static master up 2018-04-26
OurRouter BGP master up 13:52:59 Established
роверить что Action — Accept и Set in nexthop указывает на интерфейс туннеля
вот так у меня сейчас настроено:
Furriest Автор
27.04.2018 19:54В последнем убрать Set In Nexthop и выставить Set in Nexthop Direct с указанием интерфейса vpn.
fdroid
27.04.2018 20:17с указанием интерфейса vpn.
UPD2. Коллеги, похоже, я совершил ошибку, не добавив в статью инструкцию по настройке туннеля между VPS и роутером. Очень много вопросов вызваны этим.
На всякий случай еще раз отмечу — подразумевается, что перед началом действий по этому руководству вы уже настроили VPN-туннель в нужном вам направлении и проверили его работоспособность (например, завернув туда трафик по дефолту или статикой). Если эта фаза у вас еще не выполнена, выполнять действия из статьи не очень имеет смысл.
VPN-сервер у меня на VPS настроен, но! — я подключаюсь к нему не с роутера, а виндовым клиентом в случае необходимости. Если у меня в голове правильно теперь дважды два четыре складываются, то мне нужно создать на роутере интерфейс с подключением к серверу и уже этот интерфейс явно указывать в Nexthop Direct? Т.е. задумка с BGP не в том, что этот туннель сам по себе является средством обхода, а смысл в том, чтобы через него коннектом к VPN-серверу открывались только те IP, которые роутер получает от bird — я правильно понял этот нюанс?
rogoz
26.04.2018 13:47Как я понимаю, с помощью ipset, ip route, ip rule можно сделать тоже самое, без BGP.
Типа этого github.com/jamesmacwhite/ipset-netgear-r7000-dd-wrt/wiki/Using-ipset-with-dnsmasq-and-iptablesGodless
27.04.2018 11:24в ipset вся таблица не влазит в один сэт, к сожалению. Нужно плодить несколько…
А вот с ip route + ip rule можно поиграться.
вся таблица на рабочке в простой route add занимает около 600М оперативы. (считал на mint 64 на коленке — free, route add, free)Sabubu
28.04.2018 15:39В ipset есть тип hash:net для таких случаев, который позволяет вставлять подсети, если я не путаю.
rogoz
28.04.2018 20:58вся таблица не влазит в один сэт
Type: hash:net
Header: family inet hashsize 32768 maxelem 262144
Size in memory: 1888152
References: 1
Number of entries: 62836
navion
26.04.2018 14:09В git clone лучше добавить --depth=1, чтобы не выкачивать все версии репозитория на сотни мегабайт:
root@proxy:/mnt# git clone https://github.com/zapret-info/z-i.git Cloning into 'z-i'... remote: Counting objects: 31342, done. remote: Compressing objects: 100% (4/4), done. remote: Total 31342 (delta 0), reused 1 (delta 0), pack-reused 31338 Receiving objects: 100% (31342/31342), 746.06 MiB | 5.02 MiB/s, done.
forcam
26.04.2018 14:21Коротко из последних новостей РКН vs Telegram:
1) «Роскомнадзор отказался от попыток веерно заблокировать Telegram» т.е. как я понял, блочить подсетями уже не будут.
2) «Предсказана сумма ущерба от войны России с Telegram» -1 млрд $ для компаний в России, -1 млрд $ для компаний вне России. РКН получило 46 тыс жалоб на блокировки и теперь разгребает все то, что наворотила.
источник: лента ру
з.ы. судя по всему, Telegram эту войну уже выиграл, ибо DPI для РКН перекроет все разумные суммы, а других вариантов тут по всей видимости нет. С учетом того, что в России трафик постоянно растет, DPI предется еще и постоянно расширять по мощностям, что выльется в постоянно возрастающие расходы.
Happy END
Добро, все же, иногда, побеждает.achekalin
26.04.2018 14:51+2А зла и нет. Есть очень конкретные товарищи, которые, чтобы не выглядеть дураками перед теми, кому обещали «сделать», и есть впечатление, что оно не прокатит. Кто-то по шапке получит, наверное.
Но кто сказал, что этот заход — последний? Или что не зарубят весь https вообще, а то и вообще инет, и не введут госпрокси (который будет обслуживать оператор с огромным опытом обеспечения населения новостями и другими объектами — Почта России)?VBKesha
26.04.2018 18:51Или не начнут цензурировать все SMS прилетающие из за бугра(Авторизация телеги вроде как раз по SMS).
decomeron
26.04.2018 15:44+4Это будет новость покруче
Аналитик Mobile Research group Эльдар Муртазин в эфире НСН заявил, что перебои в работе крупных сервисов не были связаны с блокировкой Telegram.
«Никакого запрета на Telegram нет, заблокировать его можно достаточно легко. Просто под этой дымовой завесой в виде борьбы с мессенджером выключают крупные компании — Google, Microsoft, проверяют скорость реакции и прочие вещи. То есть смотрят, насколько быстро эти компании реагируют на блокировки ключевых элементов своей инфраструктуры. Это является как средством нападения, так и средством защиты. Если на нас нападут, мы будем знать, что делать, если мы нападем, мы будем знать, как быстро они смогут починить свои сервисы. Такие знания нужны на случай возможной войны или предвоенной ситуации, особенно когда есть возможность нанесения ущерба с территории третьей страны, например. Известные «русские хакеры» могут поломать все что угодно, как вы понимаете», — добавил он.ildarz
26.04.2018 16:34+9Муртазин вроде относительно неплохо обозревал мобильные телефоны… вот их и обозревал бы дальше. :/ Кто у него на кого напал-то, кроме нападения РКН на собственную страну?
decomeron
26.04.2018 23:32Фишка была совсем не в этом, а в том что он знает известных»русских хакеров»
Которые могут поломать все что угодно. Интересно, откуда?
powerman
27.04.2018 04:27Ну, нельзя же официально признаться, что заблокировать не получилось. Поэтому внезапно выясняется, что тревога была учебная, граната не дефектная а тоже учебная, и в процессе обучения были достигнуты выдающиеся успехи. Осталось только оплатить убытки пострадавшим в процессе, но кто будет этими мелочами заниматься, в то время когда надо праздновать успешное завершение учёбы.
zelenin
26.04.2018 16:33+2ну телеграм может и выиграл, а мы, юзеры?
Furriest Автор
26.04.2018 16:35+1Считаю, что в долгосрочной перспективе любая победа над ограничениями распространения информации — добро для нас, юзеров. Но не навязываю мнения.
zelenin
26.04.2018 16:36+4В долгосрочной перспективе это один эпизод в череде событий.
В краткосрочной мы остались с забаненным инетом.Furriest Автор
26.04.2018 16:40+1В долгосрочной все достижения или потери состоят из таких вот эпизодов. Так что и один эпизод важен.
В краткосрочной — в ковровых блокировках виноват не Телеграм.zelenin
26.04.2018 16:44+3в ковровых блокировках виноват не Телеграм.
я не ищу виноватых. Лишь указал, что пока среди проигравших и мы.
pavel_pimenov
27.04.2018 09:291) «Роскомнадзор отказался от попыток веерно заблокировать Telegram» т.е. как я понял, блочить подсетями уже не будут.
А можно подробнее.
То, что они уже сломали и залочили будут откатывать назад?
или все останется и IP будут раз блокироваться только по жалобе владельца.
у меня один сервер на scaleway попал под такую проблему. :-(
tvi
26.04.2018 14:44+2Дичь какая-то, зачем bgp? На своем роутере прописать маршруты вида ip r a <заблоченная сеть> via 172.30.1.1. Не забыть занатить форвардинг и нат и готово.
Если хотите изящнее — ipset.as_lan
29.04.2018 06:44Абсолютно согласен. у себя написал скрипт, который получает адреса, загоняет в ipset. Далее в iptables это маркируется по match-set dst, а в конце ip rule add fwmark table xxx. Естественно для table xxx машрутом по умолчанию является впска. Правде загонять 8000 адресов в ipset дело не быстрое, но ничего интересней не нашел. Глупо загонять такое количество адресов в таблицу машрутизации. Даже тот же ipset с параметрами по умолчанию не хотел принимать столько адресов. Скрипт запускается кроном раз в сутки.
ZamPo
26.04.2018 14:44+4Спасибо за идею, где брать списки!
Но вот BGP тут, мне кажется, это из пушки по воробьям. Проще взять для шлюза бесплатную маршрутизирующую ОС (мне нравиться VyOS — это форк от популярной когда-то Vyatta), и динамически управлять маршрутизацией через скрипт. Кстати, там сразу снят вопрос, где правильно резолвить «неугодные» имена ресурсов, направляя DNS запросы к гугловским Public DNS строго в туннель.
dormin
26.04.2018 14:45Зачем мне дома миллионы адресов заблокированных РКН. У меня в туннель переадресуется полторы сотни адресов, трафик DNS и одно устройство полностью работает через туннель. Этого вполне хватает на все случаи.
Хотя предложенная схема имеет место для жизни в крупных офисах, где сотни пользователей и бегать за каждым и настраивать блокировки не хочется.
b1den
26.04.2018 14:45+2Буквально вчера проделал тоже самое через wireguard и ip ro add table, заодно прокинув домой ipv6, правда скрипт заполняет таблицу ~8 минут.
worldnomad
26.04.2018 14:45antizapret уважаю. никаких знаний и умений не нужно чтобы его использовать. а это… diy в кубе. надо ведь заботиться о том, чтобы массы обычных людей имели доступ к альтернативной информации, а не сотня-другая гиков. потому что живем-то мы среди массы, они отупеют совсем в закрытом обществе и поубивают тут и нас, и себя.
нужны решения из коробки и с одной кнопкой.
Как говорил Джабраил, «Тот, кто нам мешает, тот нам поможет». Раз уж РКН создает реестр запрещенных ресурсов, грешно было бы не воспользоваться этим реестром для решения нашей задачи. Копию реестра мы будем получать с github.
теперь засекретят по высшему уровню…lostpassword
26.04.2018 16:28Насколько я понимаю, он и сейчас является закрытым. Откуда его берут активисты — интересный вопрос…
Но в целом да, могут и сильнее гайки закрутить. Например, присвоить ему гриф секретности, тогда за несанкционированное распространение вообще уголовка будет. Удобно.Furriest Автор
26.04.2018 16:32Теоретически могут, конечно. Но вероятность не очень высока. Для загрифованной информации сильно растут требования к защищенности ИС. Им и механизм распределения реестра среди провайдеров придется перепиливать, и голову АС «Ревизор». На всё это нужны деньги, а у РЧЦ их нет.
Rampages
27.04.2018 08:48Если ты являешься провайдером или оказываешь услуги провайдера тебе дают ЭЦП, с которой ты должен каждый божий день заходить на сайт и скачивать этот реестр. У нас была ООО, которая раньше оказывала услуги связи в отдаленные деревни, так у неё ни серверов ничего не осталось, а по закону обязаны были каждый день обновлять этот список…
Достать этот список вообще не проблема…
UPD. вот то самое место где можно дергать список при наличии эцп (сертификат в формате PKCS#7)
p.s. ООО являлась оператором связи.worldnomad
28.04.2018 10:54послушайте, я свой коммент написал только по одной причине. я вот читаю хабр и кмк тут многие просто не врубаются, что речь не идёт вовсе о каком-то захватывающем интеллектуальном соревновании с ркн, а (скажем пусть и пафосно, но верно) о выживании. кто кого, и ставки не виртуальные.
поэтому может быть не стоит в эти времена обсуждать какие-то вопросы столь открыто?
заем вооружать дополнительными знанием и информацией силы, которые мешают вам жить, для которых мы враги, которые стремятся или подчинить нас или уничтожить?
ведь с их стороны вопрос стоит только так.
подумайте об этом.Furriest Автор
28.04.2018 11:47+1Вы излишне драматизируете. В текущей ситуации распространение информации гораздо важнее, чем ее сокрытие. Плюс к тому, сотрудники соответствующих органов всё это (где что можно взять) сами давно знают. Просто абсолютное большинство из них делает конкретно то, что требует от них руководство, а закрытия возможности пользоваться обходом блокировок руководство не требует.
worldnomad
28.04.2018 13:31я понимаю вашу точку зрения, но всякий раз я вижу перед собой эти картинки со списком пунктов и там один выделен и возле него написано «сейчас вы находитесь здесь».
многое из того, что есть сейчас, еще совсем недавно казалось невозможным. и к вопросузакрытия возможности пользоваться обходом блокировок руководство не требует.
применимы лишь слова «пока не требуют».
они же варят лягушку, мы же понимаем. а это размеренный, неторопливый и в то же время неостанавимый процесс.
navion
28.04.2018 14:39теперь засекретят по высшему уровню
Пока коллаборационисты не монополизировали доступ в интернет — это вряд ли возможно и глупо развивать «самостоп» раньше времени.
Das_original
26.04.2018 14:45+1Спасибо бро! Только начал искать инструмент для реализации динамической маршрутизации и сразу на полезную статью!
Slot
26.04.2018 14:45Чего уж мелочится одним BGP — прикрутите сверху ещё и MPLS — трахаться так в гамаке и стоя!
Furriest Автор
26.04.2018 14:46Оно серьезно похоже на «трахаться»? Вот эти вот десяток-два команд один раз в жизни?
Henry7
26.04.2018 14:57Если хотите трахать, то попробуйте на сервере развернуть систему управления и через RSHH или API изменять статические маршруты на роутере.
DuMOHsmol
26.04.2018 14:45+2На просторах сети есть множество сервисов, предоставляющих VPS за крайне умеренные деньги. Пока я нашел и пользуюсь вариантом за $9/год
А можете поделиться адресом? Самое дешёвое, что я видел, было за евро в месяц.
Furriest Автор
26.04.2018 15:00Написал в личку, чтобы не заниматься рекламой :)
ABATAPA
26.04.2018 16:54+1Думаю, интересно будет не ему одному… Может, открытым текстом?
Furriest Автор
26.04.2018 17:22+1Ну давайте открытым. Не побьют, надеюсь.
Буду признателен, если сначала зайдете на партнерскую ссылку сервиса http://portal.nfphosting.com/aff.php?aff=405 — вам всё равно, а мне приятно :)
Но так вы там этот VPS не найдете, поскольку он промо, поэтому вот прямая ссылка на его покупку — http://portal.nfphosting.com/cart.php?a=add&pid=53.
Сервис в США, поэтому нужно иметь в виду латентность. Я его до начала прошлой недели использовал в основном для покупки авиабилетов и заказа машин в прокате — иногда очень выгодно приходить с американского IP. Но сейчас резво тянет и OpenVPN, и socks5.TaksShine
27.04.2018 11:23Раз уж разговор зашел = ) На какие направления выгодно покупать под американским IP авиабилеты?
Furriest Автор
27.04.2018 11:40У некоторых агрегаторов доходило до абсурда, что внутрироссийские рейсы были дешевле. Но это давно было. Сейчас какие-то изменения замечал в основном в рейсах в Европу.
TOLK
27.04.2018 14:28латентность
она во всем? :) Заказал 6часов назад, и тишина )Furriest Автор
27.04.2018 14:40Ну так Омерика же, у них ночь :) Проснутся — сделают.
TOLK
27.04.2018 14:53Заметил) Наверное меня всякие линоды и хетснеры автоматизмом(в стандартной конфигурации) избаловали…
ainoneko
28.04.2018 10:42А теперь у них выходной наступил, а не рабочая суббота, как у нас? (Заказал сутки назад — видимо, теперь ждать до понедельника.)
Furriest Автор
28.04.2018 11:51Вот честно скажу, хбз. Когда я заказывал себе — заказ разместил их ночью, их утром уже заработало.
Сейчас смотрю (вижу общее количество заказов из перешедших по партнерке и сколько из них инсталлировано) — 8 запустившихся из 30. Что и почему они делают с остальными — не понимаю. Возможно, это связано с выбором ЦОДа — там же при заказе можно выбрать NY или LA. Мой сервер — в NY.
DjPhoeniX
26.04.2018 18:26На правах не-рекламы: hostodo.com даёт за $10/год, но промо-код на 20% скидку гуглится. Итого $8.
LumberJack
26.04.2018 15:00+2При наличии в хозяйстве микротика «достаточно одной таблэтки»
curl -s https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv | cut -d";" -f1 | tr '|' '\n' | grep '/' | tr -d ' ' | sort -k1 -n | sed 's/\(^\)/\/ip firewall address-list add list=rkn address=/g' | ssh admin@MIKROTIK_IPTaHKucT
26.04.2018 16:19+51) Ваш вариант удаляет «все одиночные адреса» из выгрузки, оставляет только «забанненое по подсетям» (grep '/')
2) этот пайп можно ужать до одного вызова awk:awk -F ';' '{split($1, arr, " | "); for (i in arr) {if (arr[i] ~ /\//) addr[j] = arr[i] ; j++ }} END {PROCINFO["sorted_in"] = "@val_num_asc"; asort(addr) ; for (i in addr){print "/ip firewall address-list add comment=\"Fuck RKN\" list=rkn address="addr[i]}}'
3) Если есть условно 3 микротика и одна VPS, то в вашем варианте адреса нужно пушить в каждый микротик, а в варианте из статьи только один раз в bird на VPS, на конечные микротики маршруты доедут сами через BGP.
4) Ваш вариант только добавляет адреса и не удаляет старые. Метод в статье позволит перестать гнать трафик через тунель в случае если адрес пропал из выгрузки (нее, я понимаю что с практической точки зрения на данный момент это так себе агрумент, но тем не менее).
Sokol666
26.04.2018 15:37Может кому будет интересно. Дома давно думал как избавится от заразы с блокировками, родилось такое наколенное решение. Стоит дома нетбук на Windows качает торренты да работает как сетевой архив, роутер — стандартная поделка от МГТС. Появилась у меня идея траффик на заблокированные ресурсы проксировать. На нетбуке поставил DHCP сервер, прописал в нем адрес откуда отдавать автоконфигурацию прокси, как оказалось сами файлы автоконфигурации уже есть готовые. Простым php скриптом забираю его с сервера и меняю адрес прокси на свой, которым является Tor onion router работающий на том же нетбуке. Все виндовые машинки настроены на автоконфигуоацию прокси, на телефонах путь к wpad надо прописывать вручную в настройках подключения. Пока что не заметил никаких проблем с доступом к чему либо.
Такое вот решение из говна и палок для тех у кого нет микротиков и VPN.
JackFrostDeCuba
26.04.2018 15:55-32Эта возня ради чего? Цензор.нет читать и наркотики в Телеграм покупать?
Furriest Автор
26.04.2018 15:56+9А вы не пробовали не покупать наркотики в Телеграм? Им можно для общения и для бизнеса пользоваться.
Если прочитать статью, перед тем как писать комментарий, можно увидеть, для чего это всё.JackFrostDeCuba
26.04.2018 16:15-27Никогда Телеграмом не пользовался и всех кого знаю никто им не пользуется. Ставте нормальный мессенджер.
Furriest Автор
26.04.2018 16:19+6Судя по этому комментарию, у вас проблемы либо с дефицитом общения, либо с некорректным использованием кванторов всеобщности. Либо вы просто пытаетесь троллить, но тут, как говорил герой Бандераса в «Маске Зорро» — «вы пытаетесь, а она танцует». Очень неумело.
JackFrostDeCuba
26.04.2018 16:37-22Судя по вашему негодованию, свои страхи вы проецируете на оружающих. Во всех нормальных компаниях официальная переписка идет электропочтой, то что забрали цацку в виде Телеграма, может взволновать только парочку хипстеров, педофилов и наркоманов.
Whuthering
26.04.2018 19:21+3всех нормальных компаниях официальная переписка идет электропочтой
Если у вас в компании для переписки используют только электропочту, то это либо ненормальная, либо феноменально отсталая компания, либо крохотная шарага, где все в одной комнате сидят и работают по одному жесткому графику.
Потому что электропочта и instant messaging — это две принципиально разные вещи.
TrllServ
26.04.2018 20:43+2нормальный мессенджер
Мне чисто поржать ©
А нормальный это какой?SilverFerrum
27.04.2018 10:21Реклама скайпаYuriM1983
26.04.2018 16:39+1Нет, Телеграм прекрасно работает и без всего этого.
И вообще, зарегистрировался только для подобных идиотских комментариев?
vmspike
26.04.2018 15:56Возможно для роутера будет не так напряжно маркировать пакеты файерволом (
iptablesсipset) исходя из соединения, а маршрутизировать уже на базе этой маркировки (ip rule). Сам не проверял, но при таком подходе проходить по куче айпишников придётся не для каждого пакета, а только для первого пакета в соединении.Furriest Автор
26.04.2018 16:01Я, конечно, не очень глубоко знаю архитектуру SOHO-устройств, но для более-менее серьезных железок маршрутизация делается в кремнии и практически ничего не стоит, а вот файрвол для маркирования сильно подороже по ресурсам. Равно как и у PC-роутеров сейчас она опускается в кремний сетевых карт.
И здесь, мне кажется, маршрутизация должна стоить дешевле, чем файрвол. Не настолько дешевле, как в тяжелых, но всё же дешевле.
Надо у микротиковедов узнавать.vmspike
26.04.2018 16:08Ну, тут проверять надо. Если роутер загибается от такого обилия маршрутов можно попробовать другое решение. Знаю что частенько бывает, что кастомные прошивки на OpenWrt/LEDE часто не поддерживают тот самый "кремниевый сахар" устройств.
Кстати, большую таблицу маршрутизации тоже можно разбить на более мелкие диапазоны теми же правилами маршрутизации ip rule — тоже может полегчать.
Furriest Автор
26.04.2018 16:48Да, я тоже натыкался на ситуации, когда кастом не включал аппаратные фичи.
В целом можно и просто просуммаризовать iplist — будет в туннели уходить чуть больше чем надо, зато на всё решение 78+60 префиксов. Для этого, правда, по-хорошему надо полностью переписать скрипт генерации листов на том же python, не мешать же его с башем. Надо будет озаботиться.vmspike
26.04.2018 17:01Да, в статье это указано. Если есть желание можно дополнить статью способами оптимизации.
Дополню предыдущий свой коммент:
Если разделить всё IPv4 пространство на 32 диапазона, и добавить для каждого из них правило смотреть свою таблицу маршрутизации, то 85000 маршрутов из большой общей таблицы превращаются в таблицы по 2-3 тысячи маршрутов, порядок уже совсем другой, любой роутер должен сдюжить. Правда не знаю хорошо ли это вливается в концепцию работы BGP в данной статье (не использовал ни разу).
ABATAPA
26.04.2018 16:59> маршрутизация делается в кремнии
Вы путаете с HW NAT. Маршрутизация «в кремнии» не бывает, и делается средствами ядра (и стека ip) Linux.Furriest Автор
26.04.2018 17:13Под «более-менее серьезными железками» я подразумевал аппаратные маршрутизаторы (прежде всего Cisco, где моя экспертиза лежит) и там уже давно маршрутизация живет практически исключительно в кремнии, вылезая на процессор только в редких случаях.
Про PC-роутеры — насколько я себе представлял, DPDK и подобные библиотеки научились опускать маршрутизацию (ну т.е. фактически принятие решение об отправке фрейма на основании dst ip заголовка) в кремний сетевых карт. Но тут не буду настаивать, не моя экспертиза. Если необходимо — могу уточнить у разработчиков, работающих с этой библиотекой.amarao
26.04.2018 17:42+2dpdk и хардварная маршрутизация — разные направления ускорения сети. dpdk делает обработку пакетов процессором очень быстрой (и тупой), а хардварная маршрутизация, как вы сказали, выгружает правила принятия решений в сетевую карту.
navion
26.04.2018 17:31Речь наверное про TCAM или FPGA.
udaltsov
27.04.2018 03:23TCAM применяется не для маршрутизации, в основном для фильтров, где в результате поиска по битовой маске нужно иметь три состояния, match, don't match и don't care. Поэтому так и называется ternary content addressable memory.
sakontwist
26.04.2018 16:56Каюсь, еще пару недель назад настроил на роутере канал до туннельного брокера IPV6. Практически все нужные ресурсы, имеют в своем распоряжении IPV6-адреса. Все, что нужно (в основном ivideon, evernote и сервисы Google), работает без плясок.
Furriest Автор
26.04.2018 16:58+1Да, это тоже способ обхода (у меня тоже не один месяц уже работает через HE), но, к сожалению, IPv6 не настолько распространен, чтобы исключить проблемы доступа. Если IPv6 решил ваши проблемы — это очень хорошо.
amarao
26.04.2018 17:41+2Большая поправка: для такого рода VPN'ов шифрование — совершенно опциональная вещь. Если мы «остальной» трафик доверяем провайдеру как есть, то какой смысл шифровать блокированный?
Так что достаточно просто GRE-туннеля. Без IPSec. Внутри там прекрасно пойдёт SSL-трафик там, где это важно, так что дополнительных рисков это не создаёт.
(Если бы не было блокировки, то трафик бы шёл через провайдера без «сетевого шифрования»).
Всё это актуально до тех пор, пока цензура не начала проверять содержимое GRE, разумеется.Furriest Автор
26.04.2018 17:45Да, частично соглашусь.
Хотя DPI уже вполне себе разбирают транзитные нешифрованные туннели и выдергивают из них DNS-запросы, например. Поскольку некоторые провайдеры используют в том числе и обработку DNS-запросов для целей фильтрации, я бы отказывался от шифрования в туннелях только в случае, если роутеру совсем с ним плохо становится.
rigid
26.04.2018 20:16Автору спасибо!
Настроил с включением отдачи и одиночных маршрутов. Роутер спокойно вывез.
Роутер Mikrotik RB951Ui-2HnD, было свободно ~109Мб RAM, стало свободно ~60Мб. По CPU изменений не вижу. Единственное, CPU проседает в момент просмотра списка маршутов из WinBox.
Для bird Использовал локальный сервачок, который у меня торренты качает и на телек раздает.
В целом такой вариант решения мне очень нравится.
DarkByte
26.04.2018 22:56Вместо плагина для хрома и списка заблокированных доменов можно использовать dnscrypt-proxy, и спрятать весь DNS трафик от глаз провайдера.
Furriest Автор
27.04.2018 03:31Ох, ну это совсем не «вместо». Плагин для хрома и список доменов нужны для того, чтобы обходить блокировки, которые делаются по доменному имени (или полностью, «ограничение доступа к сайту», или частично «ограничение доступа к странице»). В этом случае далеко не факт, что ip из реестра совпадает с реальным ip сайта и поэтому, соответственно, не факт, что трафик в описанном решении пойдет в туннель.
Если же трафик пошел в оператора — тот вылавливает доменное имя не из dns-запросов. Достаточно большое количество оных не подменяет dns, но практически все парсят HTTP GET и TLS SNI. Соответственно, dnscrypt от этого не спасет от слова «совсем».DarkByte
27.04.2018 10:40Так оно применяется с описанным в статье решением. Просто если провайдер подменил ответ DNS, и клиент получил IP провайдерской заглушки, вместо реального адреса сайта, то поздно направлять трафик в обход провайдера. А dnscrypt-proxy позволит получать реальные адреса сайтов и соответственно правильно направлять трафик в обход провайдера.
Furriest Автор
27.04.2018 11:47Если использовать плагин со списком, он не зависит от провайдерского DNS. Потому что это обычное использование http/sock5-прокси для списка доменов, и резолвинг в этом случае тоже делается на стороне прокси, провайдер только адрес прокси и резолвит, если прокси именем, а не ip-адресом прописан.
В случае описанного решения вполне логично просто завернуть dns-трафик в туннель (например, статикой на 8.8.8.8). Шифрования туннеля вполне хватит для защиты dns-запросов от DPI провайдера.
Но если этого не делать — можно и dnscrypt использовать, безусловно. Просто он не заменит плагин для хрома, поскольку плагин нужен в случаях, когда мы не получили ip заблокированного ресурса в таблицу маршрутизации. Условный гугл в реестр был внесен с адресом 4.4.4.4, а нам (компьютеру на клиентской стороне) разрезолвился в 5.5.5.5. И не потому, что провайдер подменил ответ, а потому что у условного гугла 600 адресов в пуле этого адреса.DarkByte
27.04.2018 18:06Но ведь dnscrypt-proxy — это и есть туннель для DNS. Если нам DNS отдал другой адрес (сервис поменял его), и его не будет в таблице маршрутизации, то его и у провайдера тоже не будет в списке заблокированных. Хотя действительно в такой ситуации можно словить блок, но для этого DPI у провайдера должен проверять URL адрес во всех запросах, а не только в тех, которые идут к IP из реестра. В целом, на всякий случай, надо иметь введу запасные варианты обхода блокировки.
Furriest Автор
27.04.2018 18:11Беда в том, что провайдер должен блокировать сайты по имени вне зависимости от ip, который указан в листе. Поэтому провайдеры либо гонят весь поток http/https реквестов в dpi, либо иным способом обеспечивают попадание именно такого трафика в фильтрацию.
DarkByte
27.04.2018 18:15Тогда понятно. Видимо мой провайдер пока не раскошелился на DPI, поэтому он блокирует домены только по DNS (и по своему, и подменяя ответы чужих), и сервера по IP, при этом не разбирая, к какому домену на этом адресе идёт запрос. Поэтому очень много лишних сайтов попадает под блокировку.
TaHKucT
27.04.2018 01:29+1Например, достаточно легко сделать суммаризацию списка ip-адресов через решения на perl или python. Простой скрипт на perl, делающий это с помощью Net::CIDR::Lite, превращает 85 тысяч префиксов в 60 (не тысяч), но, естественно, перекрывает гораздо бОльший диапазон адресов, чем заблокировано.
Вот этот момент я немножечко не понял.
Я набросал скрипт на перле:
curl -s https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv | perl -MSocket -F'\s|;|\|' -nlae 'BEGIN{$mask = 24 ;for($i=0;$i<$mask;$i++){$bm=($bm<<1)+1}$bm=$bm<<(32-$mask)}for(@F){next if !(/^((25[0-5]?|2[0-4]?\d|[01]?\d\d?)\.){3}(25[0-5]?|2[0-4]?\d?|[01]?\d\d?)$/);$h{unpack("N",inet_aton($_))&$bm}+=1}END{for(keys %h){print inet_ntoa(pack("N",$_))."/$mask"}}'
Поиграл значением переменной mask в теле и получил такие значения:
СпойлерДлина префикса | Колво маршрутов
32 | 85929
31 | 70875
30 | 57153
29 | 46442
28 | 38231
27 | 31421
26 | 25805
25 | 21129
24 | 17616
23 | 14353
22 | 11645
21 | 9495
20 | 7740
19 | 6251
18 | 5056
17 | 4053
16 | 3204
15 | 2543
14 | 1947
13 | 1465
12 | 1069
11 | 750
10 | 505
9 | 329
8 | 189
7 | 103
6 | 56
5 | 28
4 | 14
3 | 7
2 | 4
1 | 2
0 | 1
Furriest Автор
27.04.2018 03:45Вот тут я совсем не настоящий сварщик, у меня есть скрипт на perl не моего авторства, который используется для агрегации префиксов после bgpq3. Кормил ему список адресов — получал ~60 строк на выходе. Глубоко в полученном результате не копался ввиду отсутствия необходимости. Совершенно не исключаю, что где-то ошибка, надо этот будет этот момент проработать поглубже, когда будет время.
TaHKucT
27.04.2018 04:24А покажите ваш скрипт… ну или хотя бы результат его работы на актуальном dump.csv
Furriest Автор
27.04.2018 04:47#!/usr/bin/perl use Net::CIDR::Lite; my $cidr = Net::CIDR::Lite->new; while (<STDIN>) { chomp; $cidr->add("$1") if (/^\s*(\d+\.\d+\.\d+\.\d+\/\d+)\s*$/); $cidr->add_range("$1-$2") if (/^\s*(\d+\.\d+\.\d+\.\d+)\s*-\s*(\d+\.\d+\.\d+\.\d+)\s*.*$/); } print "$_\n" for $cidr->list;
Но повторюсь — на консистентность результат не проверял.TaHKucT
27.04.2018 05:27+1"$cidr->add("$1") if (/^\s*(\d+\.\d+\.\d+\.\d+\/\d+)\s*$/)" — в этой строке выбираются только входящие строки в формате «ip/mask», но не просто «ip». То есть условный «192.168.0.5/24» в итоговую выборку попадет, а условный «192.168.1.1» будет просто откинут без всякого суммирования.
Если переписать скрипт вот так(что бы одиночные ip без маски тоже обрабатывались):
#!/usr/bin/perl use Net::CIDR::Lite; my $cidr = Net::CIDR::Lite->new; while (<STDIN>) { chomp; $cidr->add("$1") if (/^\s*(\d+\.\d+\.\d+\.\d+\/\d+)\s*$/); $cidr->add_ip("$1") if (/^\s*(\d+\.\d+\.\d+\.\d+)\s*$/); $cidr->add_range("$1-$2") if (/^\s*(\d+\.\d+\.\d+\.\d+)\s*-\s*(\d+\.\d+\.\d+\.\d+)\s*.*$/); } print "$_\n" for $cidr->list;
То результат станет порядка 62к адресов, из которых подавляющая часть с масками /29, /30, /31 и /32, а всех остальных меньше 200 штук.Furriest Автор
27.04.2018 12:33Спасибо :) Мой перл близок к нулю, да.
Попробую использовать вашу версию скрипта для суммаризации, всё же 62к лучше, чем 85к.
Ну и да, есть повод отряхнуть пыль с мозга, вспомнить питон и переписать все скрипты в решении на нём, добавив суммаризацию.
Sabubu
27.04.2018 04:12А не подойдет вариант загрузить все заблокированные адреса в ipset (с исп-м hash:net) и с помощью iptables роутить пакеты куда надо? Насколько я понимаю, ipset как раз оптимизирован для работы с большим количеством IP. Если роутер или компьютер поддерживает ipset, конечно.
powerman
27.04.2018 04:49Это вариант чёрного списка. Мне больше нравится вариант белого списка — он проще и очевиднее. У меня есть белый список того, что идёт в инет напрямую:
- торренты (из-за трафика, которым не хочется грузить vpn)
- i2p (по приколу)
- ssh (чтобы уменьшить задержки, если бы игрался — здесь были бы игровые сервера)
- smtp (домашний почтовик дело принципа, не смотря на все препятствия)
- сайт провайдера (иногда они пускают в личный кабинет только из своей сети)
- собственно, сам vpn сервер
Всё остальное идёт через vpn. Отныне, и навеки веков. Аминь.
Самое смешное, что в моём случае дело даже не в РКН — у нас зачем-то решили заблокировать Яндекс. А бегать за ними и перенастраивать каждый раз как они решат ещё что-то поломать в интернете — нет, спасибо. Если им надоело просматривать мой трафик, могли так и сказать — зачем толсто намекать блокировками? В России, конечно, забавнее — одновременно вводят сохранение всего трафика страны на пол года, и тут же переводят большую часть населения на VPN. Умом, как обычно, не понять.
Furriest Автор
27.04.2018 05:02Вполне возможный вариант. Лично для меня в VPN есть две проблемы — рост латентности (а если VPN в США — то очень существенный рост латентности) и потенциальная фрагментация, поэтому я стараюсь заворачивать в VPN только то, что нельзя туда не заворачивать.
Однако ваш вариант для многих подойдет.
Яндекс, по секрету скажу, сегодня ночью и в России заблокировать решили, вместе с VK и OK :) Правда, от Яндекса только один адрес и быстро исправились.powerman
27.04.2018 05:17Э… а зачем брать VPN в США? Что до излишней фрагментации, то это надо ещё постараться так сеть настроить — по-моему в наши дни с настройками MTU по умолчанию место для заголовков туннеля обычно оставляют все, но могу ошибаться. В общем, обе проблемы сначала надо себе самостоятельно создать, и только потом получится от них пострадать всласть.
Furriest Автор
27.04.2018 05:39Я тут упоминал уже, кажется — изначально VPS (и VPN/proxy на нем) я заводил для того, чтобы экономить на авиабилетах и аренде машины, для этого он именно в США и нужен.
Да и в целом я нахожусь ровно в середине России, все международные каналы идут в Москву, поэтому выход за пределы поля блокировок резко увеличивает латентность, даже если в Эстонии приземлиться.
С MTU — есть мы говорим про 100 Mbps, то на операторских сетях для физлиц там практически всегда 1500 в сторону абонента и даже baby giant крайне маловероятен. Ибо у операторского коммутатора главное достоинство — дешевизна порта, а «все эти мту-шмту» не повышают оплачиваемый спрос. Хотя это, конечно, на основании только собственного опыта — у меня за последние годы было с десяток российских ISP, где я что-то внедрял или траблшутил. В каких-то других операторах и особенно вне РФ всё может быть по-другому.
В любом случае, у меня на домашнем подключении точно 1500 и если PMTUD не отработает — на туннеле будет фрагментация со всеми вытекающими.
powerman
27.04.2018 05:33Что до увеличения задержек в принципе:
- google.com, VPN 45ms, напрямую 42ms
- ya.ru, VPN 75ms, напрямую … ой, забыл что его у нас блокируют.
- habr.com, VPN 58ms, напрямую 11ms (вау, 4 хопа!)
- github.com, VPN 123ms, напрямую 131ms (das ist fantastisch!)
Единственный момент — без VPN задержки более стабильные, а с VPN задержка колеблется в каких-то пределах, не критично, но тем не менее. Но в целом — это вообще не проблема, до тех пор пока речь не заходит о доступе к игровому серверу, находящемуся в своём городе, через VPN в другой стране.
Furriest Автор
27.04.2018 05:50«Что делать будем… Завидовать будем» (С) Сталин из анекдота
google.com 93/313/46
ya.ru 93/313/51
habr.com 87/199/38
github.com 180/172/176
Эстония/США/директ, соответственно.
Но тут, как писал выше, география сильно роляет.
scruff
27.04.2018 10:51Может я что-то упустил, но нужен ли на VPS-серваке публичный IP-адрес или достаточно серого 172.20.Х.Х?
TaHKucT
27.04.2018 11:17В статье не рассматривается никакой конкретной VPN-технологии. Единственное требование: что бы на двух устройствах были совместимые VPN-сервер и VPN-клиент.
Наличии реального ipv4 в данном случае совершенно не обязательно, но ваш VPN-клиент должен уметь соединяться с вашим VPN-сервером, для этого может быть использован реальный ipv4 адрес на одном из концов (либо на vps, либо «дома»), проброс необходимых портов, реальный ipv6 адрес или что-то типа того, главное что бы ваши сервер и клиент смогли соединиться.
vilgood
28.04.2018 06:00А можете добавить в статью описание настройки случая, где вместо VPS уже стоит маршрутизатор ROS, и туннель между ними уже поднят?
Уже имеется VPS с CHR и к нему подключены клиенты VPN.
Интересует базовая настройка BGP, без автоматического обновления подсетей на «сервере».Furriest Автор
28.04.2018 07:46В смысле случай с двумя Mikrotik, при этом на первом есть какой-то список сетей и его надо проанонсировать на клиентов по BGP? Обеспечивать коннективити между клиентами через туннели не надо?
Там всё более чем элементарно, запустить на каждом BGP (лучше, наверное, даже iBGP — т.е. на всех маршрутизаторах один и тот же номер AS) и поскольку на центральном маршруты получены не по BGP — настроить редистрибьюцию от него в BGP. Если маршруты прописаны статикой, то настройки приблизительно будут выглядеть так.
на центральном:
/routing bgp instance set default as=64999 ignore-as-path-len=yes redistribute-static=yes router-id=ip CHR
/routing bgp peer add name=Client1 remote-address=ip 1 клиента внутри туннеля remote-as=64999 ttl=default
/routing bgp peer add name=Client2 remote-address=ip 2 клиента внутри туннеля remote-as=64999 ttl=default
и т.д.
на клиентах:
/routing bgp instance set default as=64999 ignore-as-path-len=yes redistribute-static=yes router-id=ip клиента
/routing bgp peer add name=CHR remote-address=ip CHR внутри туннеля remote-as=64999 ttl=default
И даже фильтры, как в статье, прописывать не надо — всё и так сойдется. Обратите внимание, что BGP-пиринг в этом случае строится внутри туннелей, на внутренних адресах.
Если я неправильно понял задачу и надо решить именно задачу обмена трафиком между клиентами — тогда лучше перейти на eBGP (т.е. поменять номера AS на разные) и добавить в настройку пиров на CHR (/routing bgp peer add) команду nexthop-choice=force-self.
Хотя в конкретно этом случае, возможно, удобнее будет пушить сети в сторону клиентов через механизмы OpenVPN, если у вас OpenVPN. Тут в комментариях несколько раз описывали варианты.
Опишите, чего хочется добиться, чуть подробнее — смогу подсказать более полно.vilgood
29.04.2018 11:20Да, именно так и надо. Сейчас несколько роутеров через CHR пускают трафик, маркируя его в mangle.
Сам список dst-address-list загружается с сервера на каждый роутер по SSH
Список составляется в ручном режиме, добавляются крупные сети или адреса необходимых ресурсов. Но в последнее время слишком много стало блокироваться, хотел бы оптимизировать
Avoozl
28.04.2018 19:35Развернул у себя на микротике, но для этого на роутере пришлось, во-первых, включить Multihop в настройках Peer, как уже было написано в комментарии выше, а во-вторых, в настройках фильтра выбрать только протокол BGP — без этого дефолтный маршрут 0.0.0.0/0 тоже направлялся на VPN. Никто не знает, почему так происходит и почему этот момент не описан в инструкциях?
Furriest Автор
29.04.2018 06:38Видимо, вы получаете дефолт тоже динамически. Поправка логичная, я ее добавил вчера в текст, после того как мне прислали ее в личку.
А про multihop со стороны клиента я банально забыл, сейчас допишу.
taurusbusy
28.04.2018 20:04Огромная благодарность автору! Очень полезная и интересная статья.
Можете показать примерный конфиг bird, который работает на PC-роутере со стороны «клиента», и который не только принимает актуальные маршруты с VPS, но и анонсирует две серых сетки (пусть это будут 172.16.16.0/24 и 10.0.2.0/24)?
Спасибо за ваш труд.Furriest Автор
29.04.2018 06:34Можно вообще полностью повторить конфиг сервера, который опубликован в статье, а в pfxlist.txt положить ваши серые сети.
Изменения, которые потребуется сделать на обоих роутерах (и на VPS, и на PC): это поменять в protocol bgp строку import none; на import all; и раскомментировать export all; в protocol kernel.
Первое действие позволяет принимать по bgp получаемые префиксы, а второе — инсталлировать полученные маршруты в таблицу маршрутизации операционной системы.
Если эти серые сети появляются на pc-роутере динамически (например, как connected или по какому-либо протоколу динамической маршрутизации), можно научить bird редистрибьютить их оттуда и тогда он будет их анонсировать, только когда они реально есть. Но для такой схемы надо уже погружаться в архитектуру вашей сети, а вариант с bgp вручную будет работать вне зависимости от ее параметров.
В вашем случае лучше строить iBGP (т.е. чтобы номера AS с двух сторон совпадали) внутри туннеля (т.е. на адресах туннеля).
Andrico
29.04.2018 06:20Вброшу фэнтезийный вариант, но имхо роутеронезависимый: во внутреннем сегменте живёт полноценная Raspberry Pi (с Ethernet на борту) или аналог, выполняющий роль default gateway для устройств домашней сети. На нём кодится логика, описанная в тексте Furriest — незаблокированное уходит на условный «старый длинк», заблокированное — в tun на RPi. Или такая реализация кажется слишком сложной? просто в хозяйстве болтается пара малин, а кинетик слишком стар, чтобы штатно уметь openvpn.
Furriest Автор
29.04.2018 07:05В этой схеме у вас малинка будет полноценным router-on-stick для домашней сети. Весь бы трафик локалки через малинку я пускать не рискнул (транзитный поток торрента хотя бы на 100Mbps превратит малину в тыкву), но благодаря icmp redirect домашние устройства быстро научатся отправлять трафик, который должен уходить «на старый длинк» сразу на него, поэтому схема вполне может сработать. Попробуйте.
Вижу риски в том, что icmp redirect cache у устройств может быть разный и по объему, и по времени хранения. Поэтому надо смотреть, с какой периодичностью трафик будет перескакивать назад на малинку (а для вас это будет проявляться в всплесках латентности — и если вы играете в онлайн-игры, то может испортить вам всю малину).
Я бы на вашем месте посмотрел, нет ли для кинетика поддержки «хоть какого-нибудь» протокола динамической маршрутизации (не обязательно bgp, можно IGP — т.е. ospf или rip). И потом поднял туннель и bgp-пиринг с малинки, но выливал эти префиксы в кинетик по этому внутреннему протоколу. Тогда дефолтом в домашней сети остается кинетик и он уже шлет редиректы, когда клиенты должны уйти в туннель. Поскольку адресов в туннеле несравнимо меньше, чем в интернете, клиенты не очень пострадают.
Но да, эта схема подразумевает, что вы обходитесь туннелем только для сетей. 80к (или даже 60к после суммаризации) префиксов отдельных заблокированных ip-адресов в IGP свернут крышу даже провайдерским маршрутизаторам, не то, что домашнему кинетику.
Unsacrificed
29.04.2018 06:20+1Полезная статья, спасибо.
Для себя правда уже написал программку для парсинга файла со списком ip/сетей, может кому-то пригодится: github.
Кроме, собственно, парсинга также нормализует и производит суммаризацию (настраиваемо).
Вот так можно получить готовый файл для Bird (и IP и сети в одном выходном файле):network-list-parser-linux-amd64.bin -src-file dump.csv -dst-file list.txt -prefix "route " -suffix " reject;"
skand888
29.04.2018 06:20Подход отличны! Осталось найти VPS, IP которого сам не окажется заблокированным. Что не просто — если нам удалось за несколько минут запустить машинку за $5, то же самое может сделать и Телеграмм по соседству в той же /10 подсети.
Furriest Автор
29.04.2018 06:24Как по-моему — вероятность того, что ваш VPS заблокируют из-за того, что на соседней VPS запущен Телеграм, не очень высока. РКН, конечно, отслеживает часть адресов, куда пытается подключиться клиент, но это не очень большая часть.
К тому же, кто-то большой уже надавал им по попе за массовые блокировки и в последние дни они добавляют в лист в основном /32.skand
29.04.2018 09:56Нет, VPS специально вряд ли заблокируют. Но все началось то не с желания по преступному LinkedIn полазить, а с того, что слишком много ни в чем не повинных ресурсов оказались заблокированы просто так, им не повезло с соседями. Если РКН перестанет такие блокировать — то и проблемы нет.
Но если не перестанет — в таких условиях VPS будет работать примерно так же, как и средний легальный сервис в облаке — он попадет под блокировку с такой же вероятностью. Плюс, конечно, что вы его контролируете и можете переехать в другое облако/IP.
Но полноценным решением был бы роутинг через что-то более стойкое к блокировкам — например, через TOR.Furriest Автор
29.04.2018 10:38Тут всегда вопрос в балансе. TOR — это, безусловно, высокая выживаемость, но очень низкая скорость, катастрофические задержки и джиттер. Как следствие, заворачивать вообще весь трафик на какое-то адресное пространство в TOR-туннели можно тогда, когда нет более эффективной альтернативы. В TOR хорошо заворачивать подходящие для него сервисы, т.е. на 7 уровне модели, а не на 3.
Универсального решения, к сожалению, нет — всегда надо подбирать решение под конкретную ситуацию. Пока что обход блокировок неплохо работает через прокси для 7 уровня и через маршрутизацию в туннели для 3 уровня. Возможно, следующим интересным вариантом станет туннелирование через native ipv6 у тех клиентов, которым провайдер дает ipv6. А может и не станет, поглядим.
achekalin
Все руки не доходили сделать, спасибо!