Темата е доста претупана, знам. Например, има страхотно статия, но там се разглежда само IP частта от списъка за блокиране. Ще добавим и домейни.

Поради факта, че съдилищата и RKN блокират всичко надясно и наляво, а доставчиците се опитват усилено да не попаднат под глобите, издадени от Revizorro, свързаните с това загуби от блокиране са доста големи. И сред "законно" блокираните сайтове има много полезни (здравей, rutracker)

Живея извън юрисдикцията на RKN, но моите родители, роднини и приятели останаха у дома. Затова беше решено да се измисли лесен начин за хората, далеч от ИТ, да заобиколят блокирането, за предпочитане без тяхното участие изобщо.

В тази бележка няма да описвам основните мрежови неща на стъпки, а ще опиша общите принципи за това как може да се приложи тази схема. Така че познаването на това как работи мрежата като цяло и в частност в Linux е задължително.

Видове брави

Първо, нека опресним паметта си за това, което е блокирано.

Има няколко типа ключалки в разтоварения XML от RKN:

IP
Име на домейна
URL

За простота ще ги намалим до две: IP и домейн и просто ще извадим домейна от блокиране по URL (по-точно, те вече са направили това за нас).

добри хора от Роскомсвобода реализира чудесен API, чрез които можем да получим това, от което се нуждаем:

IP: https://api.reserve-rbl.ru/api/v2/ips/json
Домейни: https://api.reserve-rbl.ru/api/v2/domains/json

Достъп до блокирани сайтове

За да направим това, имаме нужда от малък чужд VPS, за предпочитане с неограничен трафик - има много от тях за 3-5 долара. Трябва да го вземете в близката чужбина, така че пингът да не е много голям, но отново имайте предвид, че интернет и географията не винаги съвпадат. И тъй като няма SLA за 5 долара, по-добре е да вземете 2+ броя от различни доставчици за отказоустойчивост.

След това трябва да настроим криптиран тунел от клиентския рутер до VPS. Използвам Wireguard като най-бърз и лесен за настройка. Имам и клиентски рутери, базирани на Linux (APU2 или нещо в OpenWRT). В случай на някои Mikrotik / Cisco, можете да използвате протоколите, налични за тях като OpenVPN и GRE-over-IPSEC.

Идентифициране и пренасочване на интересния трафик

Можете, разбира се, да изключите целия интернет трафик през чужди държави. Но най-вероятно скоростта на работа с местно съдържание ще пострада значително от това. Освен това изискванията за честотна лента на VPS ще бъдат много по-високи.

Следователно ще трябва по някакъв начин да разпределим трафика към блокираните сайтове и избирателно да го насочим към тунела. Дори ако част от „допълнителния“ трафик стигне до там, пак е много по-добре, отколкото да карате всичко през тунела.

За управление на трафика ще използваме протокола BGP и ще обявяваме маршрути до необходимите мрежи от нашия VPS на клиентите. Нека вземем BIRD като един от най-функционалните и удобни BGP демони.

IP

С блокирането по IP всичко е ясно: ние просто обявяваме всички блокирани IP адреси с VPS. Проблемът е, че има около 600 хиляди подмрежи в списъка, който API връща, и по-голямата част от тях са /32 хостове. Този брой маршрути може да обърка слабите клиентски рутери.

Следователно при обработката на списъка беше решено да се обобщи до мрежата / 24, ако има 2 или повече хоста. Така броят на маршрутите беше намален до ~100 хиляди. Сценарият за това ще последва.

домейни

Това е по-сложно и има няколко начина. Например, можете да инсталирате прозрачен Squid на всеки клиентски рутер и да правите HTTP прихващане там и да надникнете в TLS ръкостискането, за да получите искания URL адрес в първия случай и домейна от SNI във втория.

Но поради всички видове новомодни TLS1.3 + eSNI, HTTPS анализът става все по-малко реален всеки ден. Да, и инфраструктурата от страна на клиента става все по-сложна - ще трябва да използвате поне OpenWRT.

Затова реших да поема по пътя на прихващане на отговори на DNS заявки. Тук също всеки DNS-over-TLS / HTTPS започва да се движи над главата ви, но можем (засега) да контролираме тази част на клиента - или да го деактивирате, или да използвате собствен сървър за DoT / DoH.

Как да прихвана DNS?

Тук също може да има няколко подхода.

Прихващане на DNS трафик чрез PCAP или NFLOG
И двата метода за прихващане са внедрени в помощната програма сидмат. Но не се поддържа от дълго време и функционалността е много примитивна, така че все още трябва да напишете сбруя за него.
Анализ на логовете на DNS сървъра
За съжаление познатите ми рекурсори не могат да регистрират отговори, а само заявки. По принцип това е логично, тъй като, за разлика от заявките, отговорите имат сложна структура и е трудно да се напишат в текстов вид.
DNSTap
За щастие много от тях вече поддържат DNSTap за тази цел.

Какво е DNSTap?

Това е протокол клиент-сървър, базиран на буфери на протоколи и потоци от рамки за прехвърляне от DNS сървър към колектор на структурирани DNS заявки и отговори. По същество DNS сървърът предава метаданни за заявка и отговор (тип съобщение, клиент/сървър IP и т.н.) плюс пълни DNS съобщения в (двоичната) форма, в която работи с тях по мрежата.

Важно е да се разбере, че в парадигмата DNSTap DNS сървърът действа като клиент, а колекторът действа като сървър. Тоест DNS сървърът се свързва с колектора, а не обратното.

Днес DNSTap се поддържа във всички популярни DNS сървъри. Но, например, BIND в много дистрибуции (като Ubuntu LTS) често се изгражда по някаква причина без неговата поддръжка. Така че нека не се занимаваме с повторно сглобяване, а вземем по-лек и по-бърз рекурсор - Unbound.

Как да хвана DNSTap?

Има някои номер CLI помощни програми за работа с поток от DNSTap събития, но те не са подходящи за решаване на нашия проблем. Затова реших да измисля свой собствен велосипед, който ще направи всичко необходимо: dnstap-bgp

Алгоритъм на работа:

Когато се стартира, той зарежда списък с домейни от текстов файл, обръща ги (habr.com -> com.habr), изключва прекъснати линии, дубликати и поддомейни (т.е. ако списъкът съдържа habr.com и www.habr.com, ще бъде зареден само първият) и изгражда префиксно дърво за бързо търсене в този списък
Действайки като DNSTap сървър, той чака връзка от DNS сървър. По принцип поддържа както UNIX, така и TCP сокети, но DNS сървърите, които познавам, могат да използват само UNIX сокети
Входящите DNSTap пакети първо се десериализират в Protobuf структура, а след това самото двоично DNS съобщение, намиращо се в едно от полетата на Protobuf, се анализира до нивото на DNS RR записи
Проверява се дали исканият хост (или неговия родителски домейн) е в заредения списък, ако не е, отговорът се игнорира
Само A/AAAA/CNAME RR се избират от отговора и съответните IPv4/IPv6 адреси се извличат от тях
IP адресите се кешират с конфигурируем TTL и се рекламират на всички конфигурирани BGP партньори
При получаване на отговор, сочещ към вече кеширан IP, неговият TTL се актуализира
След като TTL изтече, записът се премахва от кеша и от BGP съобщенията

Допълнителна функционалност:

Препрочитане на списъка с домейни от SIGHUP
Поддържане на кеша в синхрон с други копия dnstap-bgp чрез HTTP/JSON
Дублирайте кеша на диска (в базата данни на BoltDB), за да възстановите съдържанието му след рестартиране
Поддръжка за превключване към различно мрежово пространство от имена (защо е необходимо това ще бъде описано по-долу)
Поддръжка на IPv6

Ограничения:

IDN домейните все още не се поддържат
Малко BGP настройки

Събрах RPM и DEB пакети за лесен монтаж. Трябва да работи на всички сравнително нови операционни системи със systemd. те нямат никакви зависимости.

Схемата

И така, нека започнем да сглобяваме всички компоненти заедно. В резултат на това трябва да получим нещо като тази мрежова топология:

Логиката на работа, мисля, е ясна от диаграмата:

Клиентът има нашия сървър, конфигуриран като DNS, и DNS заявките също трябва да преминават през VPN. Това е необходимо, за да не може доставчикът да използва DNS прихващане за блокиране.
При отваряне на сайта клиентът изпраща DNS заявка като „какви са IP адресите на xxx.org“
свободен разрешава xxx.org (или го взема от кеша) и изпраща отговор на клиента „xxx.org има такъв и такъв IP“, като го дублира паралелно чрез DNSTap
dnstap-bgp обявява тези адреси в ПТИЧКА чрез BGP, ако домейнът е в списъка с блокирани
ПТИЧКА обявява маршрут до тези IP с next-hop self клиентски рутер
Следващите пакети от клиента към тези IP адреси преминават през тунела

На сървъра за маршрути до блокирани сайтове използвам отделна таблица вътре в BIRD и тя не се пресича с ОС по никакъв начин.

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

Също така е възможно клиентите да не зачитат чудесата на DNS TTL, което може да накара клиента да използва някои остарели записи от своя гнил кеш, вместо да поиска Unbound.

На практика нито първото, нито второто ми създават проблеми, но вашият пробег може да варира.

Настройка на сървъра

За по-лесно навиване написах роля за Ansible. Може да конфигурира както сървъри, така и клиенти, базирани на Linux (предназначени за базирани на deb дистрибуции). Всички настройки са доста очевидни и са зададени inventory.yml. Тази роля е изрязана от моята голяма книга с игри, така че може да съдържа грешки - искания за изтегляне добре дошли 🙂

Нека да преминем през основните компоненти.

BGP

Изпълнението на два BGP демона на един и същи хост има фундаментален проблем: BIRD не иска да настрои BGP peering с localhost (или всеки локален интерфейс). Изобщо от думата. Търсенето в гугъл и четенето на пощенски списъци не помогна, те твърдят, че това е проектирано. Може би има някакъв начин, но не го намерих.

Можете да опитате друг BGP демон, но харесвам BIRD и се използва навсякъде от мен, не искам да създавам обекти.

Затова скрих dnstap-bgp в пространството на имената на мрежата, което е свързано с корена чрез интерфейса veth: това е като тръба, чиито краища стърчат в различни пространства на имена. На всеки от тези краища ние окачваме частни p2p IP адреси, които не надхвърлят хоста, така че те могат да бъдат всякакви. Това е същият механизъм, използван за достъп до процесите вътре обичан от всички Докер и други контейнери.

За това е писано сценарий и вече описаната по-горе функционалност за плъзгане за косата към друго пространство на имена беше добавена към dnstap-bgp. Поради това той трябва да се стартира като root или да се изпрати на двоичния файл CAP_SYS_ADMIN чрез командата setcap.

Примерен скрипт за създаване на пространство от имена

#!/bin/bash

NS="dtap"

IP="/sbin/ip"
IPNS="$IP netns exec $NS $IP"

IF_R="veth-$NS-r"
IF_NS="veth-$NS-ns"

IP_R="192.168.149.1"
IP_NS="192.168.149.2"

/bin/systemctl stop dnstap-bgp || true

$IP netns del $NS > /dev/null 2>&1
$IP netns add $NS

$IP link add $IF_R type veth peer name $IF_NS
$IP link set $IF_NS netns $NS

$IP addr add $IP_R remote $IP_NS dev $IF_R
$IP link set $IF_R up

$IPNS addr add $IP_NS remote $IP_R dev $IF_NS
$IPNS link set $IF_NS up

/bin/systemctl start dnstap-bgp

dnstap-bgp.conf

namespace = "dtap"
domains = "/var/cache/rkn_domains.txt"
ttl = "168h"

[dnstap]
listen = "/tmp/dnstap.sock"
perm = "0666"

[bgp]
as = 65000
routerid = "192.168.149.2"

peers = [
    "192.168.149.1",
]

bird.conf

router id 192.168.1.1;

table rkn;

# Clients
protocol bgp bgp_client1 {
    table rkn;
    local as 65000;
    neighbor 192.168.1.2 as 65000;
    direct;
    bfd on;
    next hop self;
    graceful restart;
    graceful restart time 60;
    export all;
    import none;
}

# DNSTap-BGP
protocol bgp bgp_dnstap {
    table rkn;
    local as 65000;
    neighbor 192.168.149.2 as 65000;
    direct;
    passive on;
    rr client;
    import all;
    export none;
}

# Static routes list
protocol static static_rkn {
    table rkn;
    include "rkn_routes.list";
    import all;
    export none;
}

rkn_routes.list

route 3.226.79.85/32 via "ens3";
route 18.236.189.0/24 via "ens3";
route 3.224.21.0/24 via "ens3";
...

DNS

По подразбиране в Ubuntu необвързаният двоичен файл е фиксиран от профила на AppArmor, което му забранява свързването към всички видове DNSTap сокети. Можете или да изтриете този профил, или да го деактивирате:

# cd /etc/apparmor.d/disable && ln -s ../usr.sbin.unbound .
# apparmor_parser -R /etc/apparmor.d/usr.sbin.unbound

Това вероятно трябва да се добави към книгата. Идеално е, разбира се, да коригирате профила и да издадете необходимите права, но бях твърде мързелив.

необвързан.conf

server:
    chroot: ""
    port: 53
    interface: 0.0.0.0
    root-hints: "/var/lib/unbound/named.root"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    access-control: 192.168.0.0/16 allow

remote-control:
    control-enable: yes
    control-use-cert: no

dnstap:
    dnstap-enable: yes
    dnstap-socket-path: "/tmp/dnstap.sock"
    dnstap-send-identity: no
    dnstap-send-version: no

    dnstap-log-client-response-messages: yes

Изтегляне и обработка на списъци

Скрипт за изтегляне и обработка на списък с IP адреси
Той изтегля списъка, обобщава до префикса Pfx. В dont_add и не_обобщавайте можете да кажете на IP адресите и мрежите да пропуснат или да не обобщават. Имах нужда от това. подмрежата на моя VPS беше в списъка за блокиране 🙂

Смешното е, че API на RosKomSvoboda блокира заявки с потребителския агент на Python по подразбиране. Изглежда, че script-kiddy го е разбрал. Затова го променяме на Ognelis.

Засега работи само с IPv4. делът на IPv6 е малък, но ще бъде лесно да се коригира. Освен ако не трябва да използвате и bird6.

rkn.py

#!/usr/bin/python3

import json, urllib.request, ipaddress as ipa

url = 'https://api.reserve-rbl.ru/api/v2/ips/json'
pfx = '24'

dont_summarize = {
    # ipa.IPv4Network('1.1.1.0/24'),
}

dont_add = {
    # ipa.IPv4Address('1.1.1.1'),
}

req = urllib.request.Request(
    url,
    data=None, 
    headers={
        'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.47 Safari/537.36'
    }
)

f = urllib.request.urlopen(req)
ips = json.loads(f.read().decode('utf-8'))

prefix32 = ipa.IPv4Address('255.255.255.255')

r = {}
for i in ips:
    ip = ipa.ip_network(i)
    if not isinstance(ip, ipa.IPv4Network):
        continue

    addr = ip.network_address

    if addr in dont_add:
        continue

    m = ip.netmask
    if m != prefix32:
        r[m] = [addr, 1]
        continue

    sn = ipa.IPv4Network(str(addr) + '/' + pfx, strict=False)

    if sn in dont_summarize:
        tgt = addr
    else:
        tgt = sn

    if not sn in r:
        r[tgt] = [addr, 1]
    else:
        r[tgt][1] += 1

o = []
for n, v in r.items():
    if v[1] == 1:
        o.append(str(v[0]) + '/32')
    else:
        o.append(n)

for k in o:
    print(k)

Скрипт за актуализиране
Пускам го на короната веднъж на ден, може би си струва да го дърпам на всеки 4 часа. това според мен е периодът за подновяване, който RKN изисква от доставчиците. Освен това имат някакво друго супер спешно блокиране, което може да пристигне по-бързо.

Прави следното:

Изпълнява първия скрипт и актуализира списъка с маршрути (rkn_routes.list) за BIRD
Презаредете BIRD
Актуализира и изчиства списъка с домейни за dnstap-bgp
Презаредете dnstap-bgp

rkn_update.sh

#!/bin/bash

ROUTES="/etc/bird/rkn_routes.list"
DOMAINS="/var/cache/rkn_domains.txt"

# Get & summarize routes
/opt/rkn.py | sed 's/(.*)/route 1 via "ens3";/' > $ROUTES.new

if [ $? -ne 0 ]; then
    rm -f $ROUTES.new
    echo "Unable to download RKN routes"
    exit 1
fi

if [ -e $ROUTES ]; then
    mv $ROUTES $ROUTES.old
fi

mv $ROUTES.new $ROUTES

/bin/systemctl try-reload-or-restart bird

# Get domains
curl -s https://api.reserve-rbl.ru/api/v2/domains/json -o - | jq -r '.[]' | sed 's/^*.//' | sort | uniq > $DOMAINS.new

if [ $? -ne 0 ]; then
    rm -f $DOMAINS.new
    echo "Unable to download RKN domains"
    exit 1
fi

if [ -e $DOMAINS ]; then
    mv $DOMAINS $DOMAINS.old
fi

mv $DOMAINS.new $DOMAINS

/bin/systemctl try-reload-or-restart dnstap-bgp

Те са написани без много мислене, така че ако видите нещо, което може да се подобри - давайте.

Настройка на клиента

Тук ще дам примери за Linux рутери, но в случая с Mikrotik / Cisco би трябвало да е още по-лесно.

Първо настроихме BIRD:

bird.conf

router id 192.168.1.2;
table rkn;

protocol device {
    scan time 10;
};

# Servers
protocol bgp bgp_server1 {
    table rkn;
    local as 65000;
    neighbor 192.168.1.1 as 65000;
    direct;
    bfd on;
    next hop self;
    graceful restart;
    graceful restart time 60;
    rr client;
    export none;
    import all;
}

protocol kernel {
    table rkn;
    kernel table 222;
    scan time 10;
    export all;
    import none;
}

По този начин ще синхронизираме маршрутите, получени от BGP, с таблицата за маршрутизиране на ядрото номер 222.

След това е достатъчно да поискате от ядрото да погледне тази плоча, преди да погледне тази по подразбиране:

# ip rule add from all pref 256 lookup 222
# ip rule
0:  from all lookup local
256:    from all lookup 222
32766:  from all lookup main
32767:  from all lookup default

Всичко, остава да конфигурирате DHCP на рутера, за да разпределите IP адреса на тунела на сървъра като DNS и схемата е готова.

Ограничения

С настоящия алгоритъм за генериране и обработка на списъка с домейни, той включва, наред с други неща, youtube.com и неговите CDN.

И това води до факта, че всички видеоклипове ще минават през VPN, което може да задръсти целия канал. Може би си струва да съставите списък с популярни домейни-изключения, които блокират RKN за момента, вътрешностите са тънки. И ги пропуснете при анализиране.

Заключение

Описаният метод ви позволява да заобиколите почти всяко блокиране, което доставчиците прилагат в момента.

По принцип, dnstap-bgp може да се използва за всякакви други цели, където е необходимо известно ниво на контрол на трафика въз основа на името на домейна. Само имайте предвид, че в наше време хиляди сайтове могат да висят на един и същ IP адрес (зад някои Cloudflare, например), така че този метод има доста ниска точност.

Но за нуждите на заобикалянето на брави това е напълно достатъчно.

Добавки, редакции, заявки за изтегляне - добре дошли!

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

Заобикаляне на блокирането на ILV с DNSTap и BGP

Видове брави

Достъп до блокирани сайтове

Идентифициране и пренасочване на интересния трафик

IP

домейни

Как да прихвана DNS?

Какво е DNSTap?

Как да хвана DNSTap?

Схемата

Настройка на сървъра

BGP

DNS

Изтегляне и обработка на списъци

Настройка на клиента

Ограничения

Заключение

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

Заобикаляне на блокирането на ILV с DNSTap и BGP

Видове брави

Достъп до блокирани сайтове

Идентифициране и пренасочване на интересния трафик

IP

домейни

Как да прихвана DNS?

Какво е DNSTap?

Как да хвана DNSTap?

Схемата

Настройка на сървъра

BGP

DNS

Изтегляне и обработка на списъци

Настройка на клиента

Ограничения

Заключение

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

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