🥇Настройка BGP для абыходу блакіровак, або «Як я перастаў баяцца і палюбіў РКН»

Ну добра, пра "пакахаў" - гэта перабольшанне. Хутчэй «змог суіснаваць з».

Як вы ўсё ведаеце, з 16 красавіка 2018 года Роскомнадзор вельмі шырокімі мазкамі блакуе доступ да рэсурсаў у сетцы, дадаючы ў «Адзіны рэестр даменных імёнаў, паказальнікаў старонак сайтаў у сетцы «Інтэрнэт» і сеткавых адрасоў, якія дазваляюць ідэнтыфікаваць сайты ў сетцы «Інтэрнэт», якія змяшчаюць інфармацыю, распаўсюджванне якой у Расійскай Федэрацыі забаронена »(па тэксце - проста рэестр) па /10 часам. У выніку грамадзяне Расійскай Федэрацыі і бізнес церпяць, страціўшы доступ да неабходных ім цалкам легальных рэсурсаў.

Пасля таго, як у каментарах да аднаго з артыкулаў на Хабры я сказаў, што гатовы дапамагчы пацярпелым з настройкай схемы абыходу, да мяне звярнуліся некалькі чалавек з просьбай аб такой дапамозе. Калі ў іх усё зарабіла, адзін з іх парэкамендаваў апісаць методыку ў артыкуле. Падумаўшы, вырашыў парушыць сваё маўчанне на сайце і паспрабаваць у якія-то павекі напісаць нешта прамежкавае паміж праектам і пастом у Facebook, г.зн. хабрапост. Вынік - перад вамі.

адмова

Паколькі публікаваць спосабы абыходу блакіровак доступу да інфармацыі, забароненай на тэрыторыі Расійскай Федэрацыі, не вельмі законна, мэтай гэтага артыкула будзе расказаць аб метадзе, які дазваляе аўтаматызаваць атрыманне доступу да рэсурсаў, дазволеных на тэрыторыі Расійскай Федэрацыі, але з-за нечых дзеянняў недаступным напрамую. праз вашага правайдэра. А доступ да іншых рэсурсаў, які атрымліваецца ў выніку дзеянняў з артыкула, з'яўляецца прыкрым пабочным эфектам і мэтай артыкула ні ў якім разе не з'яўляецца.

Таксама, паколькі я па прафесіі, пакліканні і жыццёвым шляху перш за ўсё сеткавы архітэктар, праграмаванне і лінуксы не з'яўляюцца маімі моцнымі бакамі. Таму, безумоўна, скрыпты можна напісаць лепш, пытанні бяспекі ў VPS можна прапрацаваць глыбей і т.д. Вашы прапановы будуць прыняты з падзякай, калі яны будуць дастаткова дэталёвыя — з задавальненнем дадам іх у тэкст артыкула.

TL, д-р

Аўтаматызуем доступ да рэсурсаў праз існуючы ў вас тунэль, выкарыстоўваючы копію рэестра і пратакол 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/zi - копія рэестра з 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 адпаведна.

Безумоўна, вы можаце выкарыстоўваць любыя іншыя роўтэры, аперацыйныя сістэмы і праграмныя прадукты, карэктуючы рашэнне пад іх логіку.

Коратка - логіка рашэння

Падрыхтоўчыя дзеянні
1. Атрымліваем VPS
2. Паднімаем тунэль ад маршрутызатара да 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 хвілін, але вы можаце абраць любы цікавы вам інтэрвал). Для гэтага запускаем кронтаб -e і дадаем у яго наступны радок:

*/20 * * * * cd ~/z-i && git pull && git gc

Падлучальны хук, які будзе ствараць файлы для сэрвісу маршрутызацыі пасля абнаўлення рэестра. Для гэтага ствараем файл /root/zi/.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 и TerAnYu за параметры для git, якія дазваляюць паменшыць аб'ёмы пампаванага.

UPD2. Калегі, падобна, я здзейсніў памылку, не дадаўшы ў артыкул інструкцыю па наладзе тунэля паміж VPS і роўтэрам. Вельмі шмат пытанняў выкліканы гэтым.
На ўсякі выпадак яшчэ раз адзначу - разумеецца, што перад пачаткам дзеянняў па гэтым кіраўніцтве вы ўжо наладзілі VPN-тунэль у патрэбным вам кірунку і праверылі яго працаздольнасць (напрыклад, загарнуўшы туды трафік па дэфолце або статыкай). Калі гэтая фаза ў вас яшчэ не выканана, выконваць дзеянні з артыкула не вельмі мае сэнс. Пакуль у мяне свайго тэксту на гэты конт няма, але калі трошкі «настройка сервера OpenVPN» разам з імем аперацыйнай сістэмы, усталяванай на VPS, і «настройка кліента OpenVPN» з імем вашага маршрутызатара — хутчэй за ўсё, вы знойдзеце некаторую колькасць артыкулаў на гэты конт , у тым ліку і на хабры.

UPD3. Unsacrificed напісаў код, які робіць з dump.csv выніковы файл для bird з апцыянальнай сумарызацыяй ip-адрасоў. Таму раздзел "Апрацоўка рэестра для сэрвісу маршрутызацыі" можна замяніць на выклік яго праграмы. https://habr.com/post/354282/#comment_10782712

UPD4. Невялікая праца над памылкамі (не ўносіў па тэксце):
1) замест systemctl reload bird мае сэнс выкарыстоўваць каманду birdc configure.
2) у маршрутызатары Mikrotik замест змены некстхопа на IP другога боку тунэля /routing filter add action=accept chain=dynamic-in protocol=bgp comment="Set nexthop" set-in-nexthop=172.30.1.1 мае сэнс паказваць маршрут прама ў інтэрфейс тунэля, без адраса /routing filter add action=accept chain=dynamic-in protocol=bgp comment="Set nexthop" set-in-nexthop-direct=<імя інтэрфейсу>

UPD5. З'явіўся новы сервіс https://antifilter.download, адкуль можна забіраць ужо гатовыя спісы ip-адрасоў. Абнаўляюцца раз у паўгадзіны. На кліенцкім баку пры гэтым застаецца толькі апраўдаць запісы адпаведнымі "route… reject".
І на гэтым, мусіць, ужо хопіць лахмаціць бабулю і абнаўляць артыкул.

UPD6. Перапрацаваная версія артыкула для тых, каму не хочацца разбірацца, а хочацца запусціцца тут.

Крыніца: habr.com

Настройка BGP для абыходу блакіровак, або «Як я перастаў баяцца і палюбіў РКН»