Comments 303
долго гуглить лень, а самому мне хватает и статического списка адресов…
но можете и сами погуглить… было что-то еще…
но опять же не уверен, что то, откуда качался список, еще живо…
а у меня например за пределами стоит облачная роутерос…
Ну с префиксами то ладно, все автоматизируется и работает. Но как быть с обычными IP адресами? После оптимизации списка всех IP адресов у меня получилось порядка 62 тысяч префиксов размером /24../32. Только вот при попытке залить их в обычный домашний микротик (951й) он просто встал колом.
Тут я думаю только какой-нибудь CCR осилит это...
Посмотрите вариант в конце комментариев, он дает 13к префиксов и это уже вполне себе перевариваемо.
Канала два — обычный инет и впн, вот bgp у нас и определяет что в впн пускать.
Аналогично кстати антизапрет поступает — у них приходят пачки маршрутов.
Но маршруты же все равно прилетают на роутер, если я правильно понимаю конфиг в статье =).
Если можно пушить на уже подключенный — то да, вполне себе решение. Я всё равно предпочту bgp, потому что там можно играть с принимаемыми префиксами, фильтровать их и посылать в разные некстхопы, но для большинства такой метод с openvpn, конечно, подойдет.
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
Как Вы думаете, имеет ли смысл реализовать другой подход для домашнего компьютера:
- получать список адресов
- просматривать логи соединений с внешними ресурсами
- если было соединение к блокированному адресу, вносить его в iptables и перенаправлять на внешний VPN или Tor
?
Причина делать именно так — нет достаточно мощного роутера или даже нет внешнего VPN (вот у меня они есть/были, но попали под блокировку, и бегать искать новые не хочется).
завернул весь трафик в впн кроме определенных адресов (в онлайн играх увеличивается пинг через впн). Решение простое и не требует спец. навыков. трафик разделил маршрутами, их всего 5.
Однако, если у вас выделенный внешний адрес, то с маршрутами придется попотеть.
Это, конечно, если не хочется завернуть в туннель всё, от греха.
Блокировок 60.000 строк — ни VPS, ни мой сервер, ни скорее всего OpenVPN просто так не понтянут такие объёмы.
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_IP
выбирает только крупные сети, так вот их вполне себе немного, у меня 78 набегает:
/ip firewall address-list add list=rkn address=13.125.0.0/16
/ip firewall address-list add list=rkn address=13.230.0.0/15
/ip firewall address-list add list=rkn address=13.56.0.0/14
/ip firewall address-list add list=rkn address=18.130.0.0/16
/ip firewall address-list add list=rkn address=18.144.0.0/16
/ip firewall address-list add list=rkn address=18.184.0.0/15
/ip firewall address-list add list=rkn address=18.194.0.0/15
/ip firewall address-list add list=rkn address=18.196.0.0/15
/ip firewall address-list add list=rkn address=18.204.0.0/14
/ip firewall address-list add list=rkn address=18.218.0.0/16
/ip firewall address-list add list=rkn address=18.236.0.0/15
/ip firewall address-list add list=rkn address=23.251.128.0/19
/ip firewall address-list add list=rkn address=34.192.0.0/10
/ip firewall address-list add list=rkn address=34.240.0.0/13
/ip firewall address-list add list=rkn address=34.248.0.0/13
/ip firewall address-list add list=rkn address=35.156.0.0/14
/ip firewall address-list add list=rkn address=35.160.0.0/13
/ip firewall address-list add list=rkn address=35.176.0.0/15
/ip firewall address-list add list=rkn address=35.178.0.0/15
/ip firewall address-list add list=rkn address=35.180.0.0/16
/ip firewall address-list add list=rkn address=35.184.0.0/13
/ip firewall address-list add list=rkn address=35.192.0.0/12
/ip firewall address-list add list=rkn address=35.208.0.0/12
/ip firewall address-list add list=rkn address=35.224.0.0/12
/ip firewall address-list add list=rkn address=45.76.82.0/23
/ip firewall address-list add list=rkn address=46.101.128.0/17
/ip firewall address-list add list=rkn address=47.91.64.0/19
/ip firewall address-list add list=rkn address=51.136.0.0/15
/ip firewall address-list add list=rkn address=51.15.0.0/16
/ip firewall address-list add list=rkn address=52.192.0.0/11
/ip firewall address-list add list=rkn address=52.32.0.0/16
/ip firewall address-list add list=rkn address=52.56.0.0/16
/ip firewall address-list add list=rkn address=52.57.0.0/16
/ip firewall address-list add list=rkn address=52.58.0.0/15
/ip firewall address-list add list=rkn address=52.64.0.0/12
/ip firewall address-list add list=rkn address=54.144.0.0/12
/ip firewall address-list add list=rkn address=54.160.0.0/12
/ip firewall address-list add list=rkn address=54.212.0.0/15
/ip firewall address-list add list=rkn address=54.228.0.0/15
/ip firewall address-list add list=rkn address=54.64.0.0/13
/ip firewall address-list add list=rkn address=64.137.0.0/17
/ip firewall address-list add list=rkn address=68.171.224.0/19
/ip firewall address-list add list=rkn address=74.82.64.0/19
/ip firewall address-list add list=rkn address=91.108.12.0/22
/ip firewall address-list add list=rkn address=91.108.16.0/22
/ip firewall address-list add list=rkn address=91.108.4.0/22
/ip firewall address-list add list=rkn address=91.108.56.0/22
/ip firewall address-list add list=rkn address=91.108.8.0/22
/ip firewall address-list add list=rkn address=91.121.0.0/16
/ip firewall address-list add list=rkn address=94.177.224.0/21
/ip firewall address-list add list=rkn address=98.158.176.0/20
/ip firewall address-list add list=rkn address=103.246.200.0/22
/ip firewall address-list add list=rkn address=109.239.140.0/24
/ip firewall address-list add list=rkn address=128.199.0.0/16
/ip firewall address-list add list=rkn address=139.59.0.0/16
/ip firewall address-list add list=rkn address=149.154.160.0/22
/ip firewall address-list add list=rkn address=149.154.164.0/22
/ip firewall address-list add list=rkn address=149.154.168.0/22
/ip firewall address-list add list=rkn address=149.154.172.0/22
/ip firewall address-list add list=rkn address=159.122.128.0/18
/ip firewall address-list add list=rkn address=159.203.0.0/16
/ip firewall address-list add list=rkn address=159.65.0.0/16
/ip firewall address-list add list=rkn address=159.89.0.0/16
/ip firewall address-list add list=rkn address=165.227.0.0/16
/ip firewall address-list add list=rkn address=167.99.0.0/16
/ip firewall address-list add list=rkn address=174.104.0.0/15
/ip firewall address-list add list=rkn address=174.138.0.0/17
/ip firewall address-list add list=rkn address=176.67.169.0/24
/ip firewall address-list add list=rkn address=178.239.88.0/21
/ip firewall address-list add list=rkn address=178.63.0.0/16
/ip firewall address-list add list=rkn address=185.166.212.0/23
/ip firewall address-list add list=rkn address=185.229.227.0/24
/ip firewall address-list add list=rkn address=188.166.0.0/17
/ip firewall address-list add list=rkn address=195.154.0.0/17
/ip firewall address-list add list=rkn address=203.104.128.0/20
/ip firewall address-list add list=rkn address=203.104.144.0/21
/ip firewall address-list add list=rkn address=203.104.152.0/22
/ip firewall address-list add list=rkn address=206.189.0.0/16
Довести до формата, подходящего OpenVPN, совсем не сложно будет.
Как в микротике можно заворачивать в другой туннель все из address list-a?
Примеров в интере много, на вскидку нашел vasilevkirill.com/MikroTik/1 какой-то такой.
Для передачи маршрутов в конфиге 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 или другой динамической маршрутизации.
Если что-то не заработает — смотрим в логи, они бывают полезны.
Однако с учетом того, что Роскомпозор начал ломать вещи типа Google Playmarket, этого может оказаться недостаточно, и потребуются меры посерьёзнее.
Я только не очень понимаю один момент. Необходимость в BGP, как я понял, объясняется тем, что список подсетей формируется на удалённом сервере, а потом пересылается роутеру через этот протокол.
Но раз уж мы говорим про роутеры на OpenWRT, то не проще ли роутеру брать список самостоятельно и загонять его в тот же iptables? На худой конец, поднимите зеркало списка, отдаваемое внутрь VPN, чтобы роутер гарантированно мог его получить при наличии доступа к серверу.
скрипты то и т.д. на нем есть, но не так много…
В противном случае проще озадачить созданием proxy.pac именно сервер.
1. все клиенты смогут этот файл забрать, нет нужды на каждом из них настраивать генерацию.
2. если дамп реестра сам будет заблокирован, VPN сервер сможет его достать (он же вне зоны блокировок).
3. если VPN не поднят, то proxy.pac ничем не поможет. Нужно тестировать, но я подозреваю что если браузер не сможет открыть proxy.pac, он просто переключится на режим без прокси. А вот если файл будет доступен, а прокси — нет, поведение может отличаться.
Все статические маршруты могут не поместиться в скудном объеме NAND Mikrotik или, в случае изменения выгрузки, которая может произойти в каждую минуту, стать либо сильно избыточным, либо наоборот сильно недостаточным.
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, роутер должен отправлять трафик на него через туннель.
Сам туннель работоспособен, если в него дефолт направить, например?
Есть ли в таблице маршрутизации маршруты, полученные по BGP? (путь в винбоксе — ip — routes и смотреть в левом столбце маленькую букву b, что-то типа DAb).
Если маршрутов нет — возможно, bgp не поднялся. Можно посмотреть на сервере результаты команды birdc sh proto — какое состояние у него. Если он Established — возможно, не установился или неправильно установился фильтр: Routing — Filters, проверить что Action — Accept и Set in nexthop указывает на интерфейс туннеля (можно и на адрес с другой стороны, но в случае туннеля лучше указывать интерфейс).
Аналогичная проблема, что и у Вас — подскажите, как решили?
У меня возникла та же ситуация, что и у Вас на скриншотах (в разделе nexthop мой адрес туннеля в состоянии recursive на внешний интерфейс). В /routing filters выставил в параметре «Set in Nexthop Direct» свой интерфейс туннеля — лучше не стало, та же ситуация с recursive
В случае, если после выполнения всех команд на Микротик из раздела «Подключение роутера», вы видите картину, аналогичную Комраду fdroid (в nexthop, recursive на ваш внешний адрес), то необходимо вместо параметра set-in-nexthop=172.30.1.1 использовать параметр set-in-nexthop-direct=`интерфейс_туннеля`.
И тут была моя ошибка — данный параметр следует вводить в консоли, а не через Web-интерфейс, поскольку через Web не применяются изменения (по крайней мере на прошивке 6.42.1)
Типа этого github.com/jamesmacwhite/ipset-netgear-r7000-dd-wrt/wiki/Using-ipset-with-dnsmasq-and-iptables
А вот с ip route + ip rule можно поиграться.
вся таблица на рабочке в простой route add занимает около 600М оперативы. (считал на mint 64 на коленке — free, route add, free)
вся таблица не влазит в один сэт
Type: hash:net
Header: family inet hashsize 32768 maxelem 262144
Size in memory: 1888152
References: 1
Number of entries: 62836
Практически для всех типов списков, реализованных в ipset, существует общее ограничение на максимальный размер: 65536 записей.
У вас ~63к записей. Я пытался залить неотимизированный список в 80к.
Или я где-то не прав?
И еще, а дальше что с этим сэтом делать? нужно же его заворачивать в маршрут, а это не для iptables, а для подсистемы маршрутизации…
Name: zapret
Type: hash:net
Revision: 6
Header: family inet hashsize 32768 maxelem 262144
Size in memory: 2192536
References: 2
Number of entries: 84672
-N MARK_ZAPRET
-A PREROUTING -m set --match-set zapret dst -m conntrack --ctstate RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A PREROUTING -m set --match-set zapret dst -m conntrack --ctstate NEW -j MARK_ZAPRET
-A MARK_ZAPRET -j MARK --set-xmark 0x2/0xffffffff
-A MARK_ZAPRET -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
ip ru
0: from all lookup local
32763: from all fwmark 0x2 lookup 200
ip ro show ta 200
default via 10.0.0.1 dev vps_tun
Секрет успеха в ipset create zapret hash:net maxelem 262144.
maxelem
This parameter is valid for the create command of all hash type sets. It does define the maximal number of elements which can be stored in the set, default 65536.
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.
Но кто сказал, что этот заход — последний? Или что не зарубят весь https вообще, а то и вообще инет, и не введут госпрокси (который будет обслуживать оператор с огромным опытом обеспечения населения новостями и другими объектами — Почта России)?
Аналитик Mobile Research group Эльдар Муртазин в эфире НСН заявил, что перебои в работе крупных сервисов не были связаны с блокировкой Telegram.
«Никакого запрета на Telegram нет, заблокировать его можно достаточно легко. Просто под этой дымовой завесой в виде борьбы с мессенджером выключают крупные компании — Google, Microsoft, проверяют скорость реакции и прочие вещи. То есть смотрят, насколько быстро эти компании реагируют на блокировки ключевых элементов своей инфраструктуры. Это является как средством нападения, так и средством защиты. Если на нас нападут, мы будем знать, что делать, если мы нападем, мы будем знать, как быстро они смогут починить свои сервисы. Такие знания нужны на случай возможной войны или предвоенной ситуации, особенно когда есть возможность нанесения ущерба с территории третьей страны, например. Известные «русские хакеры» могут поломать все что угодно, как вы понимаете», — добавил он.
Муртазин вроде относительно неплохо обозревал мобильные телефоны… вот их и обозревал бы дальше. :/ Кто у него на кого напал-то, кроме нападения РКН на собственную страну?
Которые могут поломать все что угодно. Интересно, откуда?
Прошу заметить, не просто аналитик, а ведущий мобильный аналитик!
Ну, нельзя же официально признаться, что заблокировать не получилось. Поэтому внезапно выясняется, что тревога была учебная, граната не дефектная а тоже учебная, и в процессе обучения были достигнуты выдающиеся успехи. Осталось только оплатить убытки пострадавшим в процессе, но кто будет этими мелочами заниматься, в то время когда надо праздновать успешное завершение учёбы.
Может быть бабушки на лавочке и разнесли бы эту новость, но они просто не в курсе кто такой Муртазин.
А те, кто знают что такое телега — они, чаще всего, знают кто такой Муртазин и насколько продажны его аналитические заключения. Даже в сфере мобильных телефонов. Но фотки в обзораз были хорошие )
ну телеграм может и выиграл, а мы, юзеры?
В долгосрочной перспективе это один эпизод в череде событий.
В краткосрочной мы остались с забаненным инетом.
В краткосрочной — в ковровых блокировках виноват не Телеграм.
В краткосрочной мы перестали отключать VPN :-)
1) «Роскомнадзор отказался от попыток веерно заблокировать Telegram» т.е. как я понял, блочить подсетями уже не будут.
А можно подробнее.
То, что они уже сломали и залочили будут откатывать назад?
или все останется и IP будут раз блокироваться только по жалобе владельца.
у меня один сервер на scaleway попал под такую проблему. :-(
Если хотите изящнее — ipset.
Глупо загонять такое количество адресов в таблицу машрутизации.Наоборот непонятно, зачем городить дополнительные сущности в виде iptables, ipset и ip_rules, если у нас уже есть dst, которые достаточно добавить в дефолтную таблицу маршрутизации.
Откдуда взято предположение, что jenkins hash ipset'а будет производительние и экономичнее чем модифицированный LPC-trie для обработки одинакового количества ipv4 адресов/подсетей (неплохое описание и тесты, да и на хабре писали)? Т.е. если ядерная маршрутизация не справится, то с iptables+ipset+ip_rules лучше не будет. Другое дело, что надо смотреть версию ядра, раньше hash использовался для таблицы маршрутизации и некоторые оптимизации позже появились.
Можно пойти ещё на шаг дальше.
При изменениях не перегеренить всю таблицу, а воспользоваться возможностями самого гита и вытащить только изменения относительно HEAD. Удалить старые, добавить новые.
Если хотя бы раз в день делать, каждый набор изменений — скрипт размером в килобайт-полтора.
Способов много можно придумать, у каждого будут свои плюсы и минусы в конкретной ситуации.
Но вот BGP тут, мне кажется, это из пушки по воробьям. Проще взять для шлюза бесплатную маршрутизирующую ОС (мне нравиться VyOS — это форк от популярной когда-то Vyatta), и динамически управлять маршрутизацией через скрипт. Кстати, там сразу снят вопрос, где правильно резолвить «неугодные» имена ресурсов, направляя DNS запросы к гугловским Public DNS строго в туннель.
Хотя предложенная схема имеет место для жизни в крупных офисах, где сотни пользователей и бегать за каждым и настраивать блокировки не хочется.
нужны решения из коробки и с одной кнопкой.
Как говорил Джабраил, «Тот, кто нам мешает, тот нам поможет». Раз уж РКН создает реестр запрещенных ресурсов, грешно было бы не воспользоваться этим реестром для решения нашей задачи. Копию реестра мы будем получать с github.
теперь засекретят по высшему уровню…
Насколько я понимаю, он и сейчас является закрытым. Откуда его берут активисты — интересный вопрос…
Но в целом да, могут и сильнее гайки закрутить. Например, присвоить ему гриф секретности, тогда за несанкционированное распространение вообще уголовка будет. Удобно.
Достать этот список вообще не проблема…
UPD. вот то самое место где можно дергать список при наличии эцп (сертификат в формате PKCS#7)
p.s. ООО являлась оператором связи.
поэтому может быть не стоит в эти времена обсуждать какие-то вопросы столь открыто?
заем вооружать дополнительными знанием и информацией силы, которые мешают вам жить, для которых мы враги, которые стремятся или подчинить нас или уничтожить?
ведь с их стороны вопрос стоит только так.
подумайте об этом.
многое из того, что есть сейчас, еще совсем недавно казалось невозможным. и к вопросу
закрытия возможности пользоваться обходом блокировок руководство не требует.применимы лишь слова «пока не требуют».
они же варят лягушку, мы же понимаем. а это размеренный, неторопливый и в то же время неостанавимый процесс.
теперь засекретят по высшему уровню
Пока коллаборационисты не монополизировали доступ в интернет — это вряд ли возможно и глупо развивать «самостоп» раньше времени.
На просторах сети есть множество сервисов, предоставляющих VPS за крайне умеренные деньги. Пока я нашел и пользуюсь вариантом за $9/год
А можете поделиться адресом? Самое дешёвое, что я видел, было за евро в месяц.
Буду признателен, если сначала зайдете на партнерскую ссылку сервиса http://portal.nfphosting.com/aff.php?aff=405 — вам всё равно, а мне приятно :)
Но так вы там этот VPS не найдете, поскольку он промо, поэтому вот прямая ссылка на его покупку — http://portal.nfphosting.com/cart.php?a=add&pid=53.
Сервис в США, поэтому нужно иметь в виду латентность. Я его до начала прошлой недели использовал в основном для покупки авиабилетов и заказа машин в прокате — иногда очень выгодно приходить с американского IP. Но сейчас резво тянет и OpenVPN, и socks5.
латентность
она во всем? :) Заказал 6часов назад, и тишина )
Вчера так уж и быть статус поставили на заказе — «выполняется»…
У меня за «периметром» десяток серверов, я просто хотел протестить, тест удался )
Сейчас смотрю (вижу общее количество заказов из перешедших по партнерке и сколько из них инсталлировано) — 8 запустившихся из 30. Что и почему они делают с остальными — не понимаю. Возможно, это связано с выбором ЦОДа — там же при заказе можно выбрать NY или LA. Мой сервер — в NY.
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) Ваш вариант только добавляет адреса и не удаляет старые. Метод в статье позволит перестать гнать трафик через тунель в случае если адрес пропал из выгрузки (нее, я понимаю что с практической точки зрения на данный момент это так себе агрумент, но тем не менее).
Может кому будет интересно. Дома давно думал как избавится от заразы с блокировками, родилось такое наколенное решение. Стоит дома нетбук на Windows качает торренты да работает как сетевой архив, роутер — стандартная поделка от МГТС. Появилась у меня идея траффик на заблокированные ресурсы проксировать. На нетбуке поставил DHCP сервер, прописал в нем адрес откуда отдавать автоконфигурацию прокси, как оказалось сами файлы автоконфигурации уже есть готовые. Простым php скриптом забираю его с сервера и меняю адрес прокси на свой, которым является Tor onion router работающий на том же нетбуке. Все виндовые машинки настроены на автоконфигуоацию прокси, на телефонах путь к wpad надо прописывать вручную в настройках подключения. Пока что не заметил никаких проблем с доступом к чему либо.
Такое вот решение из говна и палок для тех у кого нет микротиков и VPN.
Если прочитать статью, перед тем как писать комментарий, можно увидеть, для чего это всё.
нормальный мессенджерМне чисто поржать ©
А нормальный это какой?
И вообще, зарегистрировался только для подобных идиотских комментариев?
Возможно для роутера будет не так напряжно маркировать пакеты файерволом (iptables
с ipset
) исходя из соединения, а маршрутизировать уже на базе этой маркировки (ip rule
). Сам не проверял, но при таком подходе проходить по куче айпишников придётся не для каждого пакета, а только для первого пакета в соединении.
И здесь, мне кажется, маршрутизация должна стоить дешевле, чем файрвол. Не настолько дешевле, как в тяжелых, но всё же дешевле.
Надо у микротиковедов узнавать.
Ну, тут проверять надо. Если роутер загибается от такого обилия маршрутов можно попробовать другое решение. Знаю что частенько бывает, что кастомные прошивки на OpenWrt/LEDE часто не поддерживают тот самый "кремниевый сахар" устройств.
Кстати, большую таблицу маршрутизации тоже можно разбить на более мелкие диапазоны теми же правилами маршрутизации ip rule — тоже может полегчать.
В целом можно и просто просуммаризовать iplist — будет в туннели уходить чуть больше чем надо, зато на всё решение 78+60 префиксов. Для этого, правда, по-хорошему надо полностью переписать скрипт генерации листов на том же python, не мешать же его с башем. Надо будет озаботиться.
Да, в статье это указано. Если есть желание можно дополнить статью способами оптимизации.
Дополню предыдущий свой коммент:
Если разделить всё IPv4 пространство на 32 диапазона, и добавить для каждого из них правило смотреть свою таблицу маршрутизации, то 85000 маршрутов из большой общей таблицы превращаются в таблицы по 2-3 тысячи маршрутов, порядок уже совсем другой, любой роутер должен сдюжить. Правда не знаю хорошо ли это вливается в концепцию работы BGP в данной статье (не использовал ни разу).
Вы путаете с HW NAT. Маршрутизация «в кремнии» не бывает, и делается средствами ядра (и стека ip) Linux.
Про PC-роутеры — насколько я себе представлял, DPDK и подобные библиотеки научились опускать маршрутизацию (ну т.е. фактически принятие решение об отправке фрейма на основании dst ip заголовка) в кремний сетевых карт. Но тут не буду настаивать, не моя экспертиза. Если необходимо — могу уточнить у разработчиков, работающих с этой библиотекой.
где моя экспертиза лежитВы неправильно употребляете это слово. Экспертиза означает процесс исследования чего-либо. Это калька с английского «experience», и означает это только одно — опыт, но не экспертизу.
Вы опытны в железе от Cisco.
Не думаю, что эти комментарии — адекватная площадка для лингвистических дискуссий, но оставляю за собой право использовать всю ширь русского сообразно собственному чувству языка. При этом, безусловно, не против, чтобы борцы за чистоту пользовались собственной его версией.
Жаргонизмы появляются, когда существующие слова в языке не могут точно передать смысл сказанного, или приходится использовать длинные словосочетания или конструкции. Здесь же такого нет — вы однозначно хотели сказать про ваш опыт или компетенцию.
Я ни в коей мере не борец за частоту языка, но у меня в голове не укладывается, как можно использовать эту дурацкую кальку. Будто человек нормальных слов не знает.
И как я говорил выше, меня не устраивает коннотативное наполнение слова «опыт», когда я говорю о своей экспертизе. Слово «компетенция» же иное по структуре использования и без уточняющего прилагательного мне режет слух гораздо больше, нежели «экспертиза». К тому же, «компетенция» — ровно таким же путем, через прямую кальку с английского, появившееся в русском языке слово, и никаких преимуществ его использование в данном случае не несет.
Обладать экспертизой в каком-то направлении — это, фактически, обладать набором необходимой информации, умений, опыта, возможностей и других скиллов для решения задачи в этом направлении.
Я практически уверен, что этимология слова — это не просто калька от expertise, а скорее упрощение словосочетания, подобного «набор экспертных знаний», «экспертный потенциал» и т.п.
Слово «опыт», поскольку нейтрально, обязательно требует уточнений, что опыт был положительным. Да и наличие положительного опыта в прошлом далеко не гарантирует, что текущая задача будет решена положительно. «Я уже три раза занимался сексом без презерватива с незнакомками — у меня есть положительный опыт!».
Компетенцию я считаю гораздо более узким понятием. Фактически, экспертиза состоит из набора различных компетенций, необходимых для покрытия направления. Да, можно сказать «наша компания обладает необходимым набором компетенций для решения этой задачи». Но при существовании нужного жаргонизма я не вижу в этом смысла. Если строитель будет говорить мне про «деревянные пробки» вместо «чопиков», я сильно напрягусь относительно его экспертизы в строительстве :)
>> а только для первого пакета в соединении
Маршрутизация работает по такому же принципу, т.е. только по первому пакету (при условии не отключенного FastPath).
Однако, почти всё — это не всё, к сожалению…
В связи с этим интересуюсь способом, который может из выгрузки РКН убрать все ресурсы доступные по IPv6, а уже имеющийся остаток IPv4-only перенаправить на VPN/proxy/etc…
Так что достаточно просто GRE-туннеля. Без IPSec. Внутри там прекрасно пойдёт SSL-трафик там, где это важно, так что дополнительных рисков это не создаёт.
(Если бы не было блокировки, то трафик бы шёл через провайдера без «сетевого шифрования»).
Всё это актуально до тех пор, пока цензура не начала проверять содержимое GRE, разумеется.
Хотя DPI уже вполне себе разбирают транзитные нешифрованные туннели и выдергивают из них DNS-запросы, например. Поскольку некоторые провайдеры используют в том числе и обработку DNS-запросов для целей фильтрации, я бы отказывался от шифрования в туннелях только в случае, если роутеру совсем с ним плохо становится.
Настроил с включением отдачи и одиночных маршрутов. Роутер спокойно вывез.
Роутер Mikrotik RB951Ui-2HnD, было свободно ~109Мб RAM, стало свободно ~60Мб. По CPU изменений не вижу. Единственное, CPU проседает в момент просмотра списка маршутов из WinBox.
Для bird Использовал локальный сервачок, который у меня торренты качает и на телек раздает.
В целом такой вариант решения мне очень нравится.
Если же трафик пошел в оператора — тот вылавливает доменное имя не из dns-запросов. Достаточно большое количество оных не подменяет dns, но практически все парсят HTTP GET и TLS SNI. Соответственно, dnscrypt от этого не спасет от слова «совсем».
В случае описанного решения вполне логично просто завернуть dns-трафик в туннель (например, статикой на 8.8.8.8). Шифрования туннеля вполне хватит для защиты dns-запросов от DPI провайдера.
Но если этого не делать — можно и dnscrypt использовать, безусловно. Просто он не заменит плагин для хрома, поскольку плагин нужен в случаях, когда мы не получили ip заблокированного ресурса в таблицу маршрутизации. Условный гугл в реестр был внесен с адресом 4.4.4.4, а нам (компьютеру на клиентской стороне) разрезолвился в 5.5.5.5. И не потому, что провайдер подменил ответ, а потому что у условного гугла 600 адресов в пуле этого адреса.
Например, достаточно легко сделать суммаризацию списка 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
То есть что бы получить заявленные вами 60 маршрутов (или около того), нужно суммировать маршруты с масками /6. Тут скорей всего ошибка где-то в расчетах (или у вас, или у меня).
#!/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;
Но повторюсь — на консистентность результат не проверял.
Если переписать скрипт вот так(что бы одиночные 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 штук.
Попробую использовать вашу версию скрипта для суммаризации, всё же 62к лучше, чем 85к.
Ну и да, есть повод отряхнуть пыль с мозга, вспомнить питон и переписать все скрипты в решении на нём, добавив суммаризацию.
А поскольку — спойлер! — у вас это не получится, то нет принципиальной разницы, делать всё, кроме суммаризации, на скриптах, а суммаризацию на aggregate, или делать всё на скриптах, включая суммаризацию.
В целом в жизни есть гораздо больше одного пути достижения желаемой цели, поэтому никто не говорит, что aggregate использовать нельзя. Нравится — используйте.
(Я — попробовал, результата не получил).
Это вариант чёрного списка. Мне больше нравится вариант белого списка — он проще и очевиднее. У меня есть белый список того, что идёт в инет напрямую:
- торренты (из-за трафика, которым не хочется грузить vpn)
- i2p (по приколу)
- ssh (чтобы уменьшить задержки, если бы игрался — здесь были бы игровые сервера)
- smtp (домашний почтовик дело принципа, не смотря на все препятствия)
- сайт провайдера (иногда они пускают в личный кабинет только из своей сети)
- собственно, сам vpn сервер
Всё остальное идёт через vpn. Отныне, и навеки веков. Аминь.
Самое смешное, что в моём случае дело даже не в РКН — у нас зачем-то решили заблокировать Яндекс. А бегать за ними и перенастраивать каждый раз как они решат ещё что-то поломать в интернете — нет, спасибо. Если им надоело просматривать мой трафик, могли так и сказать — зачем толсто намекать блокировками? В России, конечно, забавнее — одновременно вводят сохранение всего трафика страны на пол года, и тут же переводят большую часть населения на VPN. Умом, как обычно, не понять.
Однако ваш вариант для многих подойдет.
Яндекс, по секрету скажу, сегодня ночью и в России заблокировать решили, вместе с VK и OK :) Правда, от Яндекса только один адрес и быстро исправились.
Э… а зачем брать VPN в США? Что до излишней фрагментации, то это надо ещё постараться так сеть настроить — по-моему в наши дни с настройками MTU по умолчанию место для заголовков туннеля обычно оставляют все, но могу ошибаться. В общем, обе проблемы сначала надо себе самостоятельно создать, и только потом получится от них пострадать всласть.
Да и в целом я нахожусь ровно в середине России, все международные каналы идут в Москву, поэтому выход за пределы поля блокировок резко увеличивает латентность, даже если в Эстонии приземлиться.
С MTU — есть мы говорим про 100 Mbps, то на операторских сетях для физлиц там практически всегда 1500 в сторону абонента и даже baby giant крайне маловероятен. Ибо у операторского коммутатора главное достоинство — дешевизна порта, а «все эти мту-шмту» не повышают оплачиваемый спрос. Хотя это, конечно, на основании только собственного опыта — у меня за последние годы было с десяток российских ISP, где я что-то внедрял или траблшутил. В каких-то других операторах и особенно вне РФ всё может быть по-другому.
В любом случае, у меня на домашнем подключении точно 1500 и если PMTUD не отработает — на туннеле будет фрагментация со всеми вытекающими.
Что до увеличения задержек в принципе:
- 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 в другой стране.
Наличии реального ipv4 в данном случае совершенно не обязательно, но ваш VPN-клиент должен уметь соединяться с вашим VPN-сервером, для этого может быть использован реальный ipv4 адрес на одном из концов (либо на vps, либо «дома»), проброс необходимых портов, реальный ipv6 адрес или что-то типа того, главное что бы ваши сервер и клиент смогли соединиться.
Уже имеется VPS с CHR и к нему подключены клиенты VPN.
Интересует базовая настройка 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. Тут в комментариях несколько раз описывали варианты.
Опишите, чего хочется добиться, чуть подробнее — смогу подсказать более полно.
Сам список dst-address-list загружается с сервера на каждый роутер по SSH
Список составляется в ручном режиме, добавляются крупные сети или адреса необходимых ресурсов. Но в последнее время слишком много стало блокироваться, хотел бы оптимизировать
Можете показать примерный конфиг bird, который работает на PC-роутере со стороны «клиента», и который не только принимает актуальные маршруты с VPS, но и анонсирует две серых сетки (пусть это будут 172.16.16.0/24 и 10.0.2.0/24)?
Спасибо за ваш труд.
Изменения, которые потребуется сделать на обоих роутерах (и на VPS, и на PC): это поменять в protocol bgp строку import none; на import all; и раскомментировать export all; в protocol kernel.
Первое действие позволяет принимать по bgp получаемые префиксы, а второе — инсталлировать полученные маршруты в таблицу маршрутизации операционной системы.
Если эти серые сети появляются на pc-роутере динамически (например, как connected или по какому-либо протоколу динамической маршрутизации), можно научить bird редистрибьютить их оттуда и тогда он будет их анонсировать, только когда они реально есть. Но для такой схемы надо уже погружаться в архитектуру вашей сети, а вариант с bgp вручную будет работать вне зависимости от ее параметров.
В вашем случае лучше строить iBGP (т.е. чтобы номера AS с двух сторон совпадали) внутри туннеля (т.е. на адресах туннеля).
Текущая конфигурация сети — VPS и два Location. Все они имеют единственное подключение к провайдеру в своих городах и FreeBSD в качестве «роутерной» ОС. Сделать full-mesh для iBGP на vpn-линках труда не составляет, но кол-во Location может возрасти на 1-2 и хотелось бы сразу выбрать адекватное BGP-решение (или может на OSPF?).
И второй момент. Как я понимаю, использовать маршрутизацию через loopback-интерфейсы имеет смысл тогда, когда хотя бы на одном Location появится подключение ко второму провайдеру?
По второму вопросу — пиринг на лупбеках действительно имеет смысл при множественном подключении, но скорее не для множественных стыков с провайдерами, а множественных каналах вашей собственной сети (например, нескольких VPN, которые, разумеется, могут быть построены через нескольких операторов). В целом логика в том, что сначала вы обмениваетесь маршрутами на лупбеки через IGP (например, тот же OSPF), а потом уже между лупбеками поднимаете BGP или какой-то другой необходимый вам протокол. Это позволяет с одной стороны иметь единую логику маршрутизации, существенно уменьшив количество пиров и всех настроек на них, а с другой — получить быструю сходимость в случае перехода с туннеля на туннель.
Но это очевидно работает только внутри автономной системы (в том числе ее частей, объединенных туннелями). Стыки с внешними операторами по BGP с лупбеков особого смысла не несут, во всяком случае я не могу для себя его сформулировать.
Вижу риски в том, что icmp redirect cache у устройств может быть разный и по объему, и по времени хранения. Поэтому надо смотреть, с какой периодичностью трафик будет перескакивать назад на малинку (а для вас это будет проявляться в всплесках латентности — и если вы играете в онлайн-игры, то может испортить вам всю малину).
Я бы на вашем месте посмотрел, нет ли для кинетика поддержки «хоть какого-нибудь» протокола динамической маршрутизации (не обязательно bgp, можно IGP — т.е. ospf или rip). И потом поднял туннель и bgp-пиринг с малинки, но выливал эти префиксы в кинетик по этому внутреннему протоколу. Тогда дефолтом в домашней сети остается кинетик и он уже шлет редиректы, когда клиенты должны уйти в туннель. Поскольку адресов в туннеле несравнимо меньше, чем в интернете, клиенты не очень пострадают.
Но да, эта схема подразумевает, что вы обходитесь туннелем только для сетей. 80к (или даже 60к после суммаризации) префиксов отдельных заблокированных ip-адресов в IGP свернут крышу даже провайдерским маршрутизаторам, не то, что домашнему кинетику.
Для себя правда уже написал программку для парсинга файла со списком ip/сетей, может кому-то пригодится: github.
Кроме, собственно, парсинга также нормализует и производит суммаризацию (настраиваемо).
Вот так можно получить готовый файл для Bird (и IP и сети в одном выходном файле):
network-list-parser-linux-amd64.bin -src-file dump.csv -dst-file list.txt -prefix "route " -suffix " reject;"
PS: вообще он не выкидывает маршруты, а «укрупняет» их для уменьшения их количества, но из-за бага новая подсеть могла не включать оригинальные. Теперь все должно быть нормально.
К тому же, кто-то большой уже надавал им по попе за массовые блокировки и в последние дни они добавляют в лист в основном /32.
Но если не перестанет — в таких условиях VPS будет работать примерно так же, как и средний легальный сервис в облаке — он попадет под блокировку с такой же вероятностью. Плюс, конечно, что вы его контролируете и можете переехать в другое облако/IP.
Но полноценным решением был бы роутинг через что-то более стойкое к блокировкам — например, через TOR.
Универсального решения, к сожалению, нет — всегда надо подбирать решение под конкретную ситуацию. Пока что обход блокировок неплохо работает через прокси для 7 уровня и через маршрутизацию в туннели для 3 уровня. Возможно, следующим интересным вариантом станет туннелирование через native ipv6 у тех клиентов, которым провайдер дает ipv6. А может и не станет, поглядим.
У нас разработка в РФ, а продукт — миграция данных между облаками, с фокусам на западных клиентов. Блокировка AWS банально мешает продукт разрабатывать и тестировать — люди из офиса в РФ к некоторым регионам доступ через раз имеют.
Конечно же, мы сразу подняли машинку в DigitalOcean и VPN туннель. Но и машинка оказалась заблокированной, потому что Телеграм тоже умеет поднимать машинки в DigitalOcean. Так и живем…
Причем ареса VPS можно было бы обновлять динамически по принципу из TOR (чтобы обновления не заблокировали). Вот это был бы офигенный сервис!
Но в целом резолвинг на стороне VPS не очень подходит, потому что у многих ресурсов географически распределенный резолвинг. Т.е. резолвинг youtube в США и в РФ будет отличаться. А провайдеры, использующие резолвинг, делают это от своих адресов, разумеется.
Сам я, к сожалению, bird в такой конфигурации не использую, но думаю, что смотреть нужно в сторону параметра bgp_next_hop.
Могу собрать стенд и протестировать, но, к сожалению, в лучшем случае послезавтра. Если к тому моменту проблема не потеряет актуальность — напомните послезавтра, сделаю.
Да, вы можете манипулировать ими через автоматику и API микротика. Но делаете ли?
set protocols bgp 64999 neighbor 172.30.1.1 ebgp-multihop 250
set protocols bgp 64999 neighbor 172.30.1.1 remote-as 64998
set protocols bgp 64999 neighbor 172.30.1.1 route-map import BGP-NEXT-HOP
set policy route-map BGP-NEXT-HOP rule 10 action permit
set policy route-map BGP-NEXT-HOP rule 10 set ip-next-hop 172.30.1.1
К этому я добавил masquerading на tun30:
set service nat rule 5015 description 'Masquerade all to tun30'
set service nat rule 5015 outbound-interface tun30
set service nat rule 5015 protocol all
set service nat rule 5015 type masquerade
Судя по сложившейся ситуации, банить по крупным сетям РКН больше не будет, поэтому основная польза решения перемещается в анонсы адресов, занесенных в реестр по /32.
Далеко не каждый роутер нормально пережевывает 80к+ префиксов, да и остающиеся после прямой суммаризации 60к+ — тоже много. Поэтому я для себя решил, что буду заворачивать в туннель все сети /24, хотя бы один адрес из которых попадает в выгрузку. После суммаризации по таким сетям в выгрузке остается около 13к префиксов, что гораздо быстрее обрабатывается.
Ну и второе — я развел анонсы отдельно по сетям и по хостам на разные протоколы static, чтобы можно было легко манипулировать анонсами (кому отдавать только сети, кому и сети и хосты), а также разметить их через bgp community, чтобы и на приемных концах можно было легко зафильтровать разные группы анонсов.
Если кому-то тоже нужны такие модификации и он не знает сам, как это сделать — спросите, опишу подробнее.
В файле makebgp меняем строку генерации списка ip-адресов на вот такую:
cat /root/blacklist/tmpaddr.txt | grep -Eo "([0-9]{1,3}[\.]){3}[0-9]{1,3}" | cut -d. -f-3 | sort | uniq | sed 's_.*_&.0/24_' | aggregate -p 24 -m 24 -o 24 -q | sed 's_.*_route & reject;_' > /etc/bird/iplist.txt
(при этом не забываем поставить посоветованный konchok aggregate — apt install aggregate).
В /etc/bird/bird.conf вместо группы protocol static static_bgp пишем:
protocol static pfx_bgp {
import all;
include "pfxlist.txt";
}
protocol static hosts_bgp {
import all;
include "iplist.txt";
}
# BGP output filter
function bgp_out()
{
if ( proto = "pfx_bgp" ) then { bgp_community.add((64998,100)); return true; }
if ( proto = "hosts_bgp" ) then { bgp_community.add((64998,200)); return true; }
return false;
}
и в группе protocol bgp OurRouter заменяем
export where proto = "static_bgp";
на
export where bgp_out();
.Если пиров несколько и для каждого должна быть своя политика анонсов, дальше можно развивать идею, либо передавая ASN пира как параметр функции bgp_out и обрабатывая его в логике этой функции, либо в разных пирах использовать разные функции.
Ну и, соответственно, на принимающей стороне можно в фильтры добавлять участие bgp_community и в зависимости от них принимать или не принимать те или иные анонсы. Например, как это сделано у меня:
/routing filter
add action=accept bgp-communities=64998:100 chain=bgp_in comment=\
"Set pfx nexthop to EST" set-in-nexthop-direct=ovpn-est
add action=accept bgp-communities=64998:200 chain=bgp_in comment=\
"Set ip nexthop to USA" set-in-nexthop-direct=ovpn-nyc
Отключение одного из фильтров приведет к отключению приема либо сетей, либо хостов.
Далеко не каждый роутер нормально пережевывает 80к+ префиксов, да и остающиеся после прямой суммаризации 60к+ — тоже много.
Тут ещё вылезла подстава с дельтами, которые тот же Билайн получает на несколько часов раньше выгрузки на Гитхаб и сразу начинает блокировать.
Я бы в вашем случае пошел в следующих направлениях:
1) включил graceful restart
2) постарался уменьшить список загружаемых префиксов (через ту же суммаризацию, как было описано несколькими комментариями выше)
3) если это не поможет — мигрировать на новую версию ПО (сейчас доступна 2.0.2) и в ней внимательно покрутить доступные таймеры. В 1.6.4 конфигурируемых параметров существенно меньше, к сожалению. Для 2.0.2 репозитории мне неизвестны, возможно, придется собирать из исходных кодов.
Надеюсь, что создатели его починят, а я пока пишу свой вариант предоставления сервиса. Следите за обновлениями.
А сегодня еще и новый вариант появился antifilter.download. Кому-то может быть проще пользоваться им.
Совершенно внезапно обнаружил, что в некоторых условиях Mikrotik не пытается восстановить разорванное BGP-соединение. Зависает в статусе open sent и требует перезапуска вручную.
Как оказалось, это известный баг. Ниже ответ саппорта Mikrotik:
Yes, it is a known problem, it tries multiple times except that with each try and failure interval between tries increase. Currently solution for this problem when interval becomes too high is only disable/enable. This will change in ROS v7.
Кое-какие изменения со стороны сервиса для уменьшения влияния проблемы будут внесены. Но если у вас та же история — к сожалению, похоже, что только перезагрузка маршрутизатора сбрасывает этот таймер.
Обещания изменения в ROS v7 — это как про наступление коммунизма. «Жаль только, жить в эту пору прекрасную...»
Обещания изменения в ROS v7 — это как про наступление коммунизма.
Обычно это означает баг в той версии ядра Linux, на которой построен ROS v6. Патчем не исправить.
Ах вот почему он иногда не коннектился, пока что решилось так:
/routing bgp peer add as-override=yes hold-time=infinity in-filter=dynamic-in keepalive-time=10s multihop=yes name=vpn remote-address=10.100.140.1 remote-as=64998 remove-private-as=yes ttl=default update-sour
ce=vpn
и в bird так:
protocol bgp teranyu {
description "teranyu";
neighbor 10.100.140.5 as 64999;
import none;
export where proto = "static_bgp";
local as 64998;
passive off;
multihop;
keepalive time 10;
}
Да, вы оказались правы. Пришлось накостылять проверку и в шедулер занести.
:local namebgp "имя_bgp_peer"
:local timeout 10s
/routing bgp peer disable numbers=[find where name=$namebgp && disabled=no prefix-count!>1]; :delay $timeout; /routing bgp peer enable numbers=[find where name=$namebgp && disabled=yes]
Я не думаю, что hEX S не может выдержать такой объем таблицы маршрутизации — всё-таки это софтовый роутер, у него нет жесткого лимита на префиксы. Пока памяти и процессора хватает, всё должно работать.
Если сайты не открываются — надо смотреть, что с трейсом в этот момент до конкретного сайта, где умирает.
В целом, если проблема именно в количестве маршрутов, переход на суммаризованные списки должен помочь. У меня сейчас суммаризация порождает около 16 тысяч префиксов.
Уже готовый просуммированный список можно загружать отсюда.
Помянем.
Настройка BGP для обхода блокировок, или «Как я перестал бояться и полюбил РКН»