ProHoster > Օրագիր > Վարչակազմը > Շրջանցեք ILV արգելափակումը DNSTAp-ով և BGP-ով

Շրջանցեք ILV արգելափակումը DNSTAp-ով և BGP-ով

Շրջանցեք ILV արգելափակումը DNSTAp-ով և BGP-ով

Թեման բավականին ծեծված է, ես գիտեմ: Օրինակ, կա մի մեծ հոդված, բայց այնտեղ դիտարկվում է միայն բլոկ ցուցակի IP մասը։ Կավելացնենք նաև տիրույթներ։

Շնորհիվ այն բանի, որ դատարանները և RKN-ն արգելափակում են ամեն ինչ աջ ու ձախ, և պրովայդերները ջանում են չընկնել Revizorro-ի կողմից տրված տուգանքների տակ, արգելափակումից առաջացած կորուստները բավականին մեծ են: Իսկ «օրենքով» արգելափակված կայքերի շարքում կան շատ օգտակար (բարև, rutracker)

Ես ապրում եմ ՌԿՀ-ի ենթակայությունից դուրս, բայց ծնողներս, հարազատներս, ընկերներս մնացել են տանը։ Այսպիսով, որոշվեց ՏՏ-ից հեռու մարդկանց համար գտնել արգելափակումը շրջանցելու հեշտ միջոց, ցանկալի է ընդհանրապես առանց նրանց մասնակցության:

Այս գրառման մեջ ես չեմ նկարագրի հիմնական ցանցային բաները քայլերով, այլ նկարագրելու եմ ընդհանուր սկզբունքները, թե ինչպես կարող է իրականացվել այս սխեման: Այսպիսով, անհրաժեշտ է իմանալ, թե ինչպես է աշխատում ցանցը ընդհանրապես և մասնավորապես Linux-ում:

Փականների տեսակները

Նախ, եկեք թարմացնենք մեր հիշողությունը, թե ինչն է արգելափակվում։

RKN-ից բեռնաթափված XML-ում կան մի քանի տեսակի կողպեքներ.

  • IP
  • Դոմենների անունը
  • URL

Պարզության համար մենք դրանք կնվազեցնենք երկուսի՝ IP-ի և տիրույթի, և մենք պարզապես կհանենք տիրույթը URL-ով արգելափակումից (ավելի ճիշտ՝ նրանք դա արդեն արել են մեզ համար):

լավ մարդիկ Ռոսկոմսվոբոդա հասկացավ հրաշալի API, որի միջոցով մենք կարող ենք ստանալ այն, ինչ մեզ անհրաժեշտ է.

Մուտք դեպի արգելափակված կայքեր

Դա անելու համար մեզ անհրաժեշտ է մի փոքր արտասահմանյան VPS, գերադասելի է անսահմանափակ տրաֆիկով. դրանցից շատերը կան 3-5 դոլարով: Այն պետք է տանել մոտակա արտասահմանում, որպեսզի պինգը շատ մեծ չլինի, բայց նորից հաշվի առեք, որ ինտերնետն ու աշխարհագրությունը միշտ չէ, որ համընկնում են։ Եվ քանի որ 5 դոլարով SLA չկա, ավելի լավ է տարբեր պրովայդերներից վերցնել 2+ կտոր սխալների հանդուրժողականության համար:

Հաջորդը, մենք պետք է ստեղծենք կոդավորված թունել հաճախորդի երթուղիչից դեպի VPS: Ես օգտագործում եմ Wireguard-ը որպես ամենաարագ և ամենահեշտ կարգավորվողը: Ես նաև ունեմ Linux-ի վրա հիմնված հաճախորդների երթուղիչներ (APU2 կամ ինչ-որ բան OpenWRT-ում): Որոշ Mikrotik / Cisco-ի դեպքում կարող եք օգտագործել դրանց վրա առկա արձանագրությունները, ինչպիսիք են OpenVPN-ը և GRE-over-IPSEC-ը:

Հետաքրքրությունների երթևեկի նույնականացում և վերահղում

Դուք, իհարկե, կարող եք անջատել ամբողջ ինտերնետ տրաֆիկը արտասահմանյան երկրների միջոցով: Բայց, ամենայն հավանականությամբ, դրանից մեծապես կտուժի տեղական բովանդակության հետ աշխատելու արագությունը։ Բացի այդ, VPS-ի թողունակության պահանջները շատ ավելի բարձր կլինեն:

Հետևաբար, մեզ անհրաժեշտ կլինի ինչ-որ կերպ տրաֆիկ բաշխել արգելափակված կայքերին և ընտրողաբար ուղղել այն դեպի թունել: Նույնիսկ եթե «հավելյալ» երթևեկության մի մասը հասնում է այնտեղ, դա դեռ շատ ավելի լավ է, քան ամեն ինչ թունելով քշել:

Երթևեկությունը կառավարելու համար մենք կօգտագործենք BGP արձանագրությունը և կհայտարարենք դեպի անհրաժեշտ ցանցեր երթուղիները մեր VPS-ից մինչև հաճախորդներ: Եկեք ընդունենք BIRD-ը որպես BGP ամենաֆունկցիոնալ և հարմար դևոններից մեկը:

IP

IP-ի կողմից արգելափակման դեպքում ամեն ինչ պարզ է՝ մենք պարզապես հայտարարում ենք բոլոր արգելափակված IP-ների մասին VPS-ով։ Խնդիրն այն է, որ API-ի վերադարձած ցանկում կա մոտ 600 հազար ենթացանց, և դրանց ճնշող մեծամասնությունը /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-ը:

Շրջանցեք ILV արգելափակումը DNSTAp-ով և BGP-ով

Դա հաճախորդ-սերվեր արձանագրություն է՝ հիմնված Protocol Buffers-ի և Frame Streams-ի վրա՝ 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 հայտարարություններից

Լրացուցիչ ֆունկցիոնալություն.

  • ՍԻՂՈՒՊ-ի կողմից տիրույթների ցանկի վերընթերցում
  • Քեշը համաժամեցված պահելը այլ օրինակների հետ dnstap-bgp HTTP/JSON-ի միջոցով
  • Կրկնօրինակեք քեշը սկավառակի վրա (BoltDB տվյալների բազայում)՝ վերագործարկումից հետո դրա բովանդակությունը վերականգնելու համար
  • Աջակցություն այլ ցանցի անվանատարածք անցնելու համար (թե ինչու է դա անհրաժեշտ, կներկայացվի ստորև)
  • IPv6 աջակցություն

Սահմանափակումներ.

  • IDN տիրույթները դեռ չեն աջակցվում
  • Մի քանի BGP կարգավորումներ

Ես հավաքեցի RPM և DEB փաթեթներ հեշտ տեղադրման համար: Պետք է աշխատի բոլոր համեմատաբար վերջերս համակարգված ՕՀ-երի վրա: նրանք ոչ մի կախվածություն չունեն:

Ծրագիրը

Այսպիսով, եկեք սկսենք հավաքել բոլոր բաղադրիչները միասին: Արդյունքում, մենք պետք է ստանանք այս ցանցի տոպոլոգիայի նման մի բան.
Շրջանցեք ILV արգելափակումը DNSTAp-ով և BGP-ով

Աշխատանքի տրամաբանությունը, կարծում եմ, պարզ է դիագրամից.

  • Հաճախորդն ունի մեր սերվերը կազմաձևված որպես DNS, և DNS հարցումները նույնպես պետք է անցնեն VPN-ով: Սա անհրաժեշտ է, որպեսզի մատակարարը չկարողանա օգտագործել DNS-ի գաղտնալսումը արգելափակելու համար:
  • Կայքը բացելիս հաճախորդը ուղարկում է DNS հարցում, ինչպիսին է «որոնք են xxx.org-ի IP-ները»:
  • չկապված լուծում է xxx.org-ը (կամ վերցնում է այն քեշից) և պատասխան է ուղարկում հաճախորդին «xxx.org-ն ունի այսինչ IP IP-ն»՝ զուգահեռաբար կրկնօրինակելով այն DNSTap-ի միջոցով:
  • dnstap-bgp հայտարարում է այս հասցեները ԲԻՐԴ BGP-ի միջոցով, եթե տիրույթը արգելափակված ցանկում է
  • ԲԻՐԴ գովազդում է այս IP-ների երթուղին next-hop self հաճախորդի երթուղիչ
  • Հաճախորդից այս IP-ներին հաջորդող փաթեթները անցնում են թունելով

Սերվերում արգելափակված կայքերի երթուղիների համար ես օգտագործում եմ առանձին աղյուսակ BIRD-ի ներսում և այն ոչ մի կերպ չի հատվում ՕՀ-ի հետ։

Այս սխեման ունի մի թերություն. հաճախորդից ստացված առաջին SYN փաթեթը, ամենայն հավանականությամբ, ժամանակ կունենա հեռանալ ներքին մատակարարի միջոցով: երթուղին անմիջապես չի հայտարարվում։ Եվ այստեղ տարբերակները հնարավոր են՝ կախված նրանից, թե ինչպես է պրովայդերը կատարում արգելափակումը։ Եթե ​​նա պարզապես գցում է երթեւեկությունը, ապա խնդիր չկա։ Իսկ եթե վերահղում է ինչ-որ ՀՏՎ, ապա (տեսականորեն) հնարավոր են հատուկ էֆեկտներ։

Հնարավոր է նաև, որ հաճախորդները չհարգեն DNS TTL հրաշքները, ինչը կարող է պատճառ դառնալ, որ հաճախորդը օգտագործի որոշ հնացած գրառումներ իր փտած քեշից՝ Unbound-ին հարցնելու փոխարեն:

Գործնականում ոչ առաջինը, ոչ երկրորդը ինձ համար խնդիրներ չառաջացրեցին, բայց ձեր վազքը կարող է տարբեր լինել։

Սերվերի թյունինգ

Գլորվելու հեշտության համար գրեցի դեր Անսիբլի համար. Այն կարող է կարգավորել ինչպես սերվերները, այնպես էլ հաճախորդները՝ հիմնված Linux-ի վրա (նախատեսված է deb-ի վրա հիմնված բաշխումների համար): Բոլոր կարգավորումները բավականին ակնհայտ են և դրված են inventory.yml. Այս դերը կտրված է իմ մեծ գրքույկից, ուստի այն կարող է պարունակել սխալներ. քաշեք հարցումներ բարի գալուստ 🙂

Եկեք անցնենք հիմնական բաղադրիչները:

BGP

Երկու BGP դեմոններ նույն հոսթի վրա գործարկելը հիմնարար խնդիր ունի. BIRD-ը չի ցանկանում կարգավորել BGP peering-ը localhost-ի հետ (կամ որևէ տեղական ինտերֆեյսի): Բառից ընդհանրապես. Գուգլելը և փոստի ցուցակները կարդալը չօգնեց, նրանք պնդում են, որ դա դիզայնով է: Միգուցե ինչ-որ ճանապարհ կա, բայց ես չգտա:

Դուք կարող եք փորձել մեկ այլ BGP դեմոն, բայց ես սիրում եմ BIRD-ը և այն ամենուր օգտագործվում է իմ կողմից, ես չեմ ուզում արտադրել սուբյեկտներ:

Հետևաբար, ես թաքցրեցի dnstap-bgp ցանցի անվանատարածքի ներսում, որը veth ինտերֆեյսի միջոցով միացված է արմատին. այն նման է խողովակի, որի ծայրերը դուրս են ցցվում տարբեր անվանատարածքներում: Այս ծայրերից յուրաքանչյուրի վրա մենք կախում ենք մասնավոր p2p IP հասցեներ, որոնք չեն անցնում հյուրընկալողից այն կողմ, այնպես որ դրանք կարող են լինել ցանկացած բան: Սա նույն մեխանիզմն է, որն օգտագործվում է ներսում գործընթացներ մուտք գործելու համար բոլորի կողմից սիրված Docker և այլ բեռնարկղեր:

Սրա համար գրված էր սցենար և dnstap-bgp-ին ավելացվեց վերևում նկարագրված ֆունկցիոնալությունը՝ ձեզ մազերով մեկ այլ անվանատարածք քաշելու համար: Դրա պատճառով այն պետք է գործարկվի որպես արմատ կամ թողարկվի 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",
]

թռչուն.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-ում Unbound երկուականը սեղմված է 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 и dont_summarize կարող եք IP-ներին և ցանցերին ասել, որ բաց թողնեն կամ չամփոփեն: Ինձ դա պետք էր։ իմ VPS-ի ենթացանցը եղել է արգելափակման ցուցակում 🙂

Զավեշտալին այն է, որ RosKomSvoboda API-ն արգելափակում է հարցումները լռելյայն Python օգտագործողի գործակալի միջոցով: Կարծես թե սցենարիստը հասկացավ: Հետևաբար, մենք այն փոխում ենք Օգնելիսի:

Առայժմ այն ​​աշխատում է միայն 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.

թռչուն.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-ի հետևում), ուստի այս մեթոդը բավականին ցածր ճշգրտություն ունի։

Բայց կողպեքների շրջանցման կարիքների համար դա բավական է:

Հավելումներ, խմբագրումներ, պահանջներ. բարի գալուստ:

Source: www.habr.com

Добавить комментарий