Настройване на BGP за заобикаляне на блокирането или „Как спрях да се страхувам и се влюбих в RKN“

Е, добре, за „влюбих се“ е преувеличено. По-скоро "може да съществува съвместно с".

Както всички знаете, от 16 април 2018 г. Roskomnadzor блокира достъпа до ресурси в мрежата с изключително широки удари, добавяйки към Единния регистър на имена на домейни, указатели към страници на сайтове в Интернет и мрежови адреси, които ви позволяват да идентифицират сайтове в интернет, съдържащи информация, чието разпространение е забранено в Руската федерация” (в текста - просто регистър) /10 понякога. В резултат на това страдат гражданите на Руската федерация и предприятията, които са загубили достъп до абсолютно законните ресурси, от които се нуждаят.

След като казах в коментарите към една от статиите на Хабре, че съм готов да помогна на пострадалите с изграждането на байпасна схема, няколко души се свързаха с мен с молба за такава помощ. Когато всичко проработи при тях, един от тях препоръча да опишат техниката в статия. Като се замислих, реших да наруша мълчанието си в сайта и поне веднъж да се опитам да напиша нещо междинно между проект и пост във Фейсбук, т.е. хабрапост. Резултатът е пред вас.

Отказ от отговорност

Тъй като не е много законно да се публикуват начини за заобикаляне на блокиране на достъпа до информация, забранена на територията на Руската федерация, целта на тази статия ще бъде да говорим за метод, който ви позволява да автоматизирате достъпа до ресурси, които са разрешени на територията на Руската федерация, но поради нечии действия недостъпни директно чрез вашия доставчик. А достъпът до други ресурси, получен в резултат на действия от статията, е неприятен страничен ефект и в никакъв случай не е целта на статията.

Освен това, тъй като съм предимно мрежов архитект по професия, призвание и жизнен път, програмирането и Linux не са силните ми страни. Следователно, разбира се, скриптовете могат да бъдат написани по-добре, проблемите със сигурността във VPS могат да бъдат разработени по-задълбочено и т.н. Вашите предложения ще бъдат приети с благодарност, ако са достатъчно подробни - ще се радвам да ги добавя към текста на статията.

TL; DR

Ние автоматизираме достъпа до ресурси през вашия съществуващ тунел, като използваме копие на регистъра и BGP протокола. Целта е да се премахне целия трафик, адресиран до блокирани ресурси в тунела. Минимално обяснение, предимно инструкции стъпка по стъпка.

Какво ви трябва за това

За съжаление, тази публикация не е за всеки. За да използвате тази техника, ще трябва да съберете няколко елемента:

  1. Трябва да имате линукс сървър някъде извън полето за блокиране. Или поне желанието да стартирате такъв сървър - тъй като сега струва от $ 9 / година, а може би и по-малко. Методът е подходящ и ако имате отделен VPN тунел, тогава сървърът може да бъде разположен вътре в блоковото поле.
  2. Вашият рутер трябва да е достатъчно интелигентен, за да може
    • всеки VPN клиент, който харесвате (предпочитам OpenVPN, но може да бъде PPTP, L2TP, GRE+IPSec и всяка друга опция, която създава тунелен интерфейс);
    • BGPv4 протокол. Което означава, че за SOHO може да бъде Mikrotik или всеки рутер с OpenWRT/LEDE/подобен персонализиран фърмуер, който ви позволява да инсталирате Quagga или Bird. Използването на компютърен рутер също не е забранено. За предприятие вижте документацията за вашия граничен рутер за поддръжка на BGP.
  3. Трябва да сте запознати с използването на Linux и мрежовите технологии, включително BGP. Или поне искате да разберете тази идея. Тъй като този път не съм готов да прегърна необятността, ще трябва да проучите сами някои точки, които са неразбираеми за вас. Въпреки това, разбира се, ще отговоря на конкретни въпроси в коментарите и е малко вероятно да съм единственият, който отговаря, така че не се колебайте да питате.

Какво се използва в примера

  • Копие от регистъра https://github.com/zapret-info/z-i 
  • VPS - Ubuntu 16.04
  • Услуга за маршрутизиране - птица 1.6.3   
  • Рутер - Mikrotik hAP ac
  • Работни папки - тъй като работим като root, повечето от всичко ще бъде поставено в основната папка home. Съответно:
    • /root/blacklist - работна папка със скрипт за компилация
    • /root/zi - копие на системния регистър от github
    • /etc/bird - стандартна папка с настройки на услугата за птици
  • Приемаме 194.165.22.146, ASN 64998 като външен IP адрес на VPS със сървъра за маршрутизиране и крайната точка на тунела; външен IP адрес на рутера - 81.177.103.94, ASN 64999
  • IP адресите в тунела са съответно 172.30.1.1 и 172.30.1.2.

Настройване на BGP за заобикаляне на блокирането или „Как спрях да се страхувам и се влюбих в RKN“

Разбира се, можете да използвате всякакви други рутери, операционни системи и софтуерни продукти, като коригирате решението, за да отговаря на тяхната логика.

Накратко – логиката на решението

  1. Подготвителни действия
    1. Получаване на VPS
    2. Повдигаме тунела от рутера до VPS
  2. Получаване и редовно актуализиране на копие от регистъра
  3. Инсталиране и конфигуриране на услугата за маршрутизиране
  4. Създайте списък със статични маршрути за услугата за маршрутизиране въз основа на регистъра
  5. Свързваме рутера към услугата и настройваме изпращането на целия трафик през тунела.

Действителното решение

Подготвителни действия

В необятността на мрежата има много услуги, които предоставят VPS за изключително разумни пари. Досега намерих и използвам опцията за $9/година, но дори и да не си правите труда, има много опции за 1E/месец на всеки ъгъл. Въпросът за избора на VPS е далеч извън обхвата на тази статия, така че ако нещо не е ясно на някого по въпроса, попитайте в коментарите.

Ако използвате VPS не само за услугата за маршрутизиране, но и за прекратяване на тунел върху него, трябва да повдигнете този тунел и почти недвусмислено да конфигурирате NAT за него. В мрежата има голям брой инструкции за тези действия, няма да ги повтарям тук. Основното изискване за такъв тунел е, че той трябва да създаде отделен интерфейс на вашия рутер, който поддържа тунела към VPS. Повечето използвани VPN технологии отговарят на това изискване - например OpenVPN в режим tun е добре.

Вземете копие от регистъра

Както е казал Джабраил: „Този, който ни пречи, ще ни помогне“. Тъй като RKN създава регистър на забранените ресурси, би било грях да не използваме този регистър, за да решим проблема си. Ще получим копие от регистъра от github.

Отиваме на вашия Linux сървър, попадаме в контекста на root'a (судо су-) и инсталирайте git, ако вече не е инсталиран.

apt install git

Отидете в домашната си директория и извадете копие от системния регистър.

cd ~ && git clone --depth=1 https://github.com/zapret-info/z-i 

Настройте актуализация на cron (имам я на всеки 20 минути, но можете да изберете всеки интервал, който ви интересува). За да направим това, стартираме кронтаб -е и добавете следния ред към него:

*/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 е сравнима по свежест с изпражненията на Archeopteryx, така че трябва първо да добавим официалния PPA на разработчиците на софтуер към системата.

add-apt-repository ppa:cz.nic-labs/bird
apt update
apt install bird

След това незабавно деактивираме птицата за IPv6 - в тази инсталация няма да ни е необходима.

systemctl stop bird6
systemctl disable bird6

По-долу е минималистичен конфигурационен файл за услугата за птици (/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 реда в списъка с префикси и 85898 в списъка с ip адреси. Силно препоръчвам да започнете и да отстранявате грешки само от списъка с префикси и да решите дали или не за да активирате зареждането на ip в бъдеще, след като експериментирате с вашия рутер. Не всеки от тях може лесно да усвои 85 хиляди записа в таблицата за маршрутизиране.

протоколът bgp всъщност настройва bgp peering с вашия рутер. ip-адресът е адресът на външния интерфейс на рутера (или адресът на тунелния интерфейс от страната на рутера), 64998 и 64999 са номерата на автономните системи. В този случай те могат да бъдат присвоени под формата на всякакви 16-битови числа, но е добра практика да се използват AS номера от частния диапазон, дефиниран от RFC6996 - 64512-65534 включително (има 32-битов ASN формат, но в нашия случай това определено е пресилено). Описаната конфигурация използва eBGP peering, при който номерата на автономната система на услугата за маршрутизиране и маршрутизатора трябва да са различни.

Както можете да видите, услугата трябва да знае IP адреса на рутера, така че ако имате динамичен или немаршрутизиращ частен (RFC1918) или споделен (RFC6598) адрес, нямате опция да задействате peering на външния интерфейс, но услугата все още ще работи в тунела.

Също така е доста прозрачно, че можете да предоставите няколко различни рутера с маршрути от една услуга - просто дублирайте настройките за тях, като копирате раздела на протокола bgp с промяна на IP адреса на съседа. Ето защо примерът показва настройките за надникване извън тунела като най-универсални. Не е трудно да ги премахнете в тунела, като промените съответно IP адресите в настройките.

Обработка на регистър за услугата за маршрутизиране

Сега трябва всъщност да създадем списъци с префикси и ip-адреси, които са споменати в предишната стъпка в статиката на протокола. За да направим това, вземаме файла на системния регистър и създаваме необходимите файлове от него със следния скрипт, намиращ се в /root/черен списък/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.

Най-вероятно в този момент птицата не работи за вас, защото на предишния етап сте предложили да търси файлове, които все още не съществуват. Затова го стартираме и контролираме да стартира:

systemctl start bird
birdc show route

Резултатът от втората команда трябва да показва около 80 записа (това е в момента и когато го настроите, всичко ще зависи от усърдието на ILV при блокиране на мрежи) по следния начин:

54.160.0.0/12      unreachable [static_bgp 2018-04-19] * (200)

Отбор

birdc show protocol

ще покаже състоянието на протоколите в рамките на услугата. Докато не конфигурирате рутера (вижте следващия параграф), протоколът OurRouter ще бъде в начално състояние (Свързване или Активни фази), а след успешна връзка ще премине в активно състояние (Установена фаза). Например в моята система резултатът от тази команда изглежда така:

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 peering и да се прикачи nexthop към всички получени префикси, сочещи към нашия тунел (ако трябва да изведете трафик през p2p интерфейса) или nexthop 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 peering, така и за предаване на полезен трафик, не е необходимо да се задава nexthop, той ще бъде зададен правилно чрез протокола. Но ако го настроите ръчно, също няма да стане по-лошо.

На други платформи ще трябва сами да разберете конфигурацията, но ако имате затруднения, пишете в коментарите, ще се опитам да помогна.

След като вашата BGP сесия се издигне, маршрутите към големи мрежи са пристигнали и са инсталирани в таблицата, трафикът към адресите от тях е изчезнал и щастието е близо, можете да се върнете към услугата за птици и да опитате да разкоментирате записа там, който свързва списък с ip адреси, изпълнете след това

systemctl reload bird

и вижте как вашият рутер прехвърли тези 85 хиляди маршрута. Пригответе се да го изключите и помислете какво да правите с него 🙂

Общо

Чисто теоретично, след извършване на горните стъпки, имате услуга, която автоматично пренасочва трафика към IP адреси, забранени в Руската федерация, покрай системата за филтриране.

Разбира се, може да се подобри. Например, достатъчно лесно е да обобщите списък с ip адреси чрез perl или python решения. Прост perl скрипт, който прави това с Net::CIDR::Lite, превръща 85 хиляди префикса в 60 (не хиляди), но естествено покрива много по-голям диапазон от адреси, отколкото е блокиран.

Тъй като услугата работи на третото ниво на модела ISO / OSI, тя няма да ви спаси от блокиране на сайт / страница, ако не се разреши на адреса, който е записан в регистъра. Но заедно с регистъра от github пристига файлът nxdomain.txt, който с няколко удара на скрипта лесно се превръща в източник на адреси за например приставката SwitchyOmega в Chrome.

Трябва също така да се спомене, че решението изисква допълнително изостряне, ако не сте просто потребител на Интернет, но и публикувате някои ресурси от себе си (например уебсайт или пощенски сървър работи на тази връзка). С помощта на рутера трябва да обвържете твърдо изходящия трафик от тази услуга към вашия публичен адрес, в противен случай ще загубите връзка с тези ресурси, които са обхванати от списъка с префикси, получени от рутера.

Ако имате въпроси - питайте, готови да отговорят.

UPD. Благодаря ти нация и ТерАнЮ за опции за git за намаляване на обемите на изтегляне.

UPD2. Колеги, изглежда, че направих грешка, като не добавих инструкции за настройка на тунел между VPS и рутера в статията. Много въпроси са породени от това.
За всеки случай отбелязвам отново - предполага се, че преди да започнете стъпките в това ръководство, вече сте конфигурирали VPN тунела в посоката, от която се нуждаете, и сте проверили неговата производителност (например обвиване на трафика там по подразбиране или статичен). Ако все още не сте завършили тази фаза, няма смисъл да следвате стъпките от статията. Все още нямам собствен текст за това, но ако търсите в Google „Настройка на OpenVPN сървър“ заедно с името на операционната система, инсталирана на VPS, и „Настройка на OpenVPN клиент“ с името на вашия рутер, най-вероятно вие ще намерите редица статии по тази тема, включително на Хабре.

UPD3. Непожертвани написа код, който прави получения файл за птица от dump.csv с незадължително сумиране на ip адреси. Следователно разделът "Обработка на регистъра за услугата за маршрутизиране" може да бъде заменен с извикване на неговата програма. https://habr.com/post/354282/#comment_10782712

UPD4. Малко работа по грешките (не са участвали в текста):
1) вместо това systemctl презареди птица има смисъл да използвате командата birdc конфигуриране.
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-адреси. Актуализира се на всеки половин час. От страна на клиента всичко, което остава, е да рамкира записите със съответния „маршрут ... отхвърляне“.
И това може би е достатъчно, за да разбия баба си и да актуализирам статията.

UPD6. Преработена версия на статията за тези, които не искат да разберат, но искат да започнат - тук.

Източник: www.habr.com

Добавяне на нов коментар