ProHoster > Օրագիր > Վարչակազմը > BGP-ի կարգավորում՝ արգելափակումը շրջանցելու համար, կամ «Ինչպես ես դադարեցի վախենալ և սիրահարվել RKN-ին»
BGP-ի կարգավորում՝ արգելափակումը շրջանցելու համար, կամ «Ինչպես ես դադարեցի վախենալ և սիրահարվել RKN-ին»
Դե, լավ, «սիրվածի» մասին չափազանցություն է: Ավելի շուտ՝ «կարողացավ գոյակցել»։
Ինչպես բոլորդ գիտեք, 16 թվականի ապրիլի 2018-ից Ռոսկոմնադզորը չափազանց լայն շարժումներով արգելափակում է ինտերնետի ռեսուրսների հասանելիությունը՝ ավելացնելով «Դոմենների անունների միասնական ռեգիստրը, կայքերի էջերի ինդեքսները ինտերնետում և ցանցային հասցեները, որոնք թույլ են տալիս նույնականացնել կայքերը։ ինտերնետում», որը պարունակում է տեղեկատվություն, որի տարածումն արգելված է Ռուսաստանի Դաշնությունում» (տեքստում՝ պարզապես գրանցամատյան) /10 երբեմն. Արդյունքում տուժում են Ռուսաստանի Դաշնության քաղաքացիները և բիզնեսը՝ զրկվելով իրենց անհրաժեշտ լիովին օրինական ռեսուրսներից։
Այն բանից հետո, երբ ես Habré-ի հոդվածներից մեկի մեկնաբանություններում ասացի, որ պատրաստ եմ օգնել տուժածներին շրջանցման սխեմա ստեղծելու հարցում, մի քանի հոգի եկան ինձ մոտ՝ խնդրելով նման օգնություն: Երբ նրանց մոտ ամեն ինչ ստացվեց, նրանցից մեկը խորհուրդ տվեց հոդվածում նկարագրել տեխնիկան: Որոշ մտածելուց հետո ես որոշեցի խախտել իմ լռությունը կայքում և մեկ անգամ փորձել միջանկյալ ինչ-որ բան գրել նախագծի և ֆեյսբուքյան գրառման միջև, այսինքն. habrapost. Արդյունքը ձեր առջև է։
Հրաժարում պատասխանատվությունից
Քանի որ շատ օրինական չէ Ռուսաստանի Դաշնության տարածքում արգելված տեղեկատվության մուտքի արգելափակումը շրջանցելու եղանակներ հրապարակելը, այս հոդվածի նպատակը կլինի խոսել մի մեթոդի մասին, որը թույլ է տալիս ավտոմատացնել մուտքը դեպի ռեսուրսներ, որոնք թույլատրվում են: Ռուսաստանի Դաշնության տարածք, սակայն ուրիշի գործողությունների պատճառով ուղղակիորեն հասանելի չեն ձեր մատակարարի միջոցով: Իսկ հոդվածի գործողությունների արդյունքում ձեռք բերված այլ ռեսուրսների հասանելիությունը տհաճ կողմնակի ազդեցություն է և ոչ մի կերպ չի հանդիսանում հոդվածի նպատակը:
Նաև, քանի որ ես մասնագիտությամբ, մասնագիտությամբ և կյանքի ճանապարհով հիմնականում ցանցային ճարտարապետ եմ, ծրագրավորումն ու Linux-ը իմ ուժեղ կողմերը չեն: Հետևաբար, իհարկե, սցենարները կարելի է ավելի լավ գրել, VPS-ում անվտանգության խնդիրները կարելի է ավելի խորը մշակել և այլն։ Ձեր առաջարկները կընդունվեն երախտագիտությամբ, եթե դրանք բավականաչափ մանրամասն լինեն, ես ուրախ կլինեմ դրանք ավելացնել հոդվածի տեքստում:
TL. DR
Մենք ավտոմատացնում ենք ռեսուրսների հասանելիությունը ձեր գոյություն ունեցող թունելի միջոցով՝ օգտագործելով ռեեստրի և BGP արձանագրության պատճենը: Նպատակը արգելափակված ռեսուրսներին հասցեագրված ողջ երթևեկությունն է դեպի թունել: Նվազագույն բացատրություններ, հիմնականում քայլ առ քայլ հրահանգներ:
Սրա համար ի՞նչ է պետք։
Ցավոք, այս գրառումը բոլորի համար չէ: Այս տեխնիկան օգտագործելու համար ձեզ հարկավոր է մի քանի տարրեր միասին դնել.
Դուք պետք է ունենաք linux սերվեր ինչ-որ տեղ արգելափակման դաշտից դուրս: Կամ գոնե նման սերվեր ունենալու ցանկությունը, բարեբախտաբար, այն այժմ արժե $9/տարի, և հնարավոր է ավելի քիչ: Մեթոդը հարմար է նաև, եթե ունեք առանձին VPN թունել, ապա սերվերը կարող է տեղակայվել արգելափակման դաշտի ներսում:
Ձեր երթուղիչը պետք է բավականաչափ խելացի լինի, որպեսզի կարողանա
ցանկացած VPN հաճախորդ, որը ձեզ դուր է գալիս (ես նախընտրում եմ OpenVPN, բայց դա կարող է լինել PPTP, L2TP, GRE+IPSec կամ ցանկացած այլ տարբերակ, որը ստեղծում է թունելի միջերես);
BGPv4 արձանագրություն. Սա նշանակում է, որ SOHO-ի համար դա կարող է լինել Mikrotik կամ ցանկացած երթուղիչ OpenWRT/LEDE/նման հարմարեցված որոնվածով, որը թույլ է տալիս տեղադրել Quagga կամ Bird: ԱՀ երթուղիչի օգտագործումը նույնպես արգելված չէ: Ձեռնարկության դեպքում փնտրեք BGP աջակցություն ձեր սահմանային երթուղիչի փաստաթղթերում:
Դուք պետք է հասկանաք Linux-ի օգտագործման և ցանցային տեխնոլոգիաները, ներառյալ BGP արձանագրությունը: Կամ գոնե ուզում եք նման գաղափար ունենալ: Քանի որ ես պատրաստ չեմ այս անգամ ընդունել անսահմանությունը, դուք ստիպված կլինեք ինքնուրույն ուսումնասիրել ձեզ համար անհասկանալի որոշ ասպեկտներ։ Այնուամենայնիվ, ես, իհարկե, կպատասխանեմ մեկնաբանություններում կոնկրետ հարցերին և դժվար թե միակ պատասխանողը լինեմ, այնպես որ մի հապաղեք հարցնել:
Աշխատանքային թղթապանակներ. քանի որ մենք աշխատում ենք որպես root, ամեն ինչի մեծ մասը կգտնվի root-ի հիմնական թղթապանակում: Համապատասխանաբար.
/root/blacklist - աշխատանքային թղթապանակ կոմպիլացիոն սցենարով
/root/zi - ռեեստրի պատճենը github-ից
/etc/bird - ստանդարտ թղթապանակ թռչունների սպասարկման կարգավորումների համար
VPS-ի արտաքին IP հասցեն երթուղային սերվերով և թունելի վերջնակետով 194.165.22.146, ASN 64998; երթուղիչի արտաքին IP հասցեն - 81.177.103.94, ASN 64999
Թունելի ներսում IP հասցեներն են՝ համապատասխանաբար 172.30.1.1 և 172.30.1.2:
Իհարկե, դուք կարող եք օգտագործել ցանկացած այլ երթուղիչ, օպերացիոն համակարգեր և ծրագրային արտադրանք՝ լուծումը հարմարեցնելով դրանց տրամաբանությանը:
Համառոտ - լուծման տրամաբանությունը
Նախապատրաստական գործողություններ
Ստանալով VPS
Թունելի բարձրացում երթուղիչից դեպի VPS
Մենք ստանում և պարբերաբար թարմացնում ենք ռեեստրի պատճենը
Երթուղային ծառայության տեղադրում և կարգավորում
Մենք ռեեստրի հիման վրա ստեղծում ենք ստատիկ երթուղիների ցուցակ երթուղային ծառայության համար
Մենք միացնում ենք երթուղիչը ծառայությանը և կարգավորում ենք ամբողջ երթևեկությունը թունելի միջոցով ուղարկելը:
Իրական լուծումը
Նախապատրաստական գործողություններ
Ինտերնետում կան բազմաթիվ ծառայություններ, որոնք տրամադրում են VPS չափազանց մատչելի գներով: Առայժմ ես գտել եմ և օգտագործում եմ տարբերակը 9 դոլար/տարի, բայց նույնիսկ եթե շատ չանհանգստանաք, ամեն անկյունում կան 1E/ամսական բազմաթիվ տարբերակներ: VPS ընտրելու հարցը շատ դուրս է այս հոդվածի շրջանակներից, այնպես որ, եթե ինչ-որ մեկը այս մասին ինչ-որ բան չի հասկանում, հարցրեք մեկնաբանություններում:
Եթե դուք օգտագործում եք VPS ոչ միայն երթուղային ծառայության համար, այլ նաև դրա վրա թունելը դադարեցնելու համար, դուք պետք է բարձրացնեք այս թունելը և, գրեթե անկասկած, կարգավորեք NAT-ը դրա համար: Ինտերնետում կան մեծ թվով հրահանգներ այս գործողությունների վերաբերյալ, ես դրանք այստեղ չեմ կրկնի։ Նման թունելի հիմնական պահանջն այն է, որ այն պետք է ստեղծի առանձին ինտերֆեյս ձեր երթուղիչի վրա, որն աջակցում է թունելը դեպի VPS: Շատ օգտագործվող VPN տեխնոլոգիաները բավարարում են այս պահանջը, օրինակ, OpenVPN-ը tun ռեժիմում կատարյալ է:
Ռեեստրի պատճեն ստանալը
Ինչպես ասաց Ջաբրայիլը, «Նա, ով խանգարում է մեզ, կօգնի մեզ»: Քանի որ RKN-ն ստեղծում է արգելված ռեսուրսների ռեգիստր, մեղք կլինի չօգտագործել այս ռեգիստրը մեր խնդիրը լուծելու համար։ Մենք ռեգիստրի պատճենը կստանանք github-ից:
Մենք գնում ենք ձեր Linux սերվեր, ընկնում ենք արմատային համատեքստում (սուդո սու —) և տեղադրել git, եթե այն արդեն տեղադրված չէ:
apt install git
Գնացեք ձեր տնային գրացուցակ և հանեք ռեեստրի պատճենը:
cd ~ && git clone --depth=1 https://github.com/zapret-info/z-i
Մենք ստեղծեցինք cron-ի թարմացում (ես դա անում եմ 20 րոպեն մեկ, բայց դուք կարող եք ընտրել ձեզ հետաքրքրող ցանկացած ընդմիջում): Դա անելու համար մենք սկսում ենք crontab -e և դրան ավելացնել հետևյալ տողը.
*/20 * * * * cd ~/z-i && git pull && git gc
Մենք կապում ենք կեռիկ, որը ռեեստրի թարմացումից հետո ֆայլեր կստեղծի երթուղային ծառայության համար: Դա անելու համար ստեղծեք ֆայլ /root/zi/.git/hooks/post-merge հետևյալ բովանդակությամբ.
Մենք մի փոքր ուշ կստեղծենք makebgp սկրիպտը, որին հղում է անում կեռիկը։
Երթուղային ծառայության տեղադրում և կարգավորում
Տեղադրեք թռչուն: Ցավոք, Ubuntu-ի պահոցներում ներկայումս տեղադրված թռչնի տարբերակը թարմությամբ համեմատելի է Archeopteryx feces-ի հետ, ուստի մենք նախ պետք է համակարգում ավելացնենք ծրագրաշարի մշակողների պաշտոնական PPA-ն:
Դրանից հետո մենք անմիջապես անջատում ենք թռչնակը 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;
}
երթուղիչի id - երթուղիչի նույնացուցիչ, որը տեսողականորեն կարծես IPv4 հասցե է, բայց մեկը չէ: Մեր դեպքում դա կարող է լինել ցանկացած 32-բիթանոց թիվ IPv4 հասցեի ձևաչափով, բայց լավ ձև է՝ նշելու հենց ձեր սարքի IPv4 հասցեն (այս դեպքում՝ VPS):
protocol direct-ը սահմանում է, թե որ միջերեսները կաշխատեն երթուղավորման գործընթացի հետ: Օրինակը տալիս է մի քանի օրինակ անուն, կարող եք ավելացնել ուրիշներ: Դուք կարող եք պարզապես ջնջել գիծը, այս դեպքում սերվերը կլսի բոլոր հասանելի միջերեսները՝ IPv4 հասցեով:
արձանագրության ստատիկը մեր կախարդանքն է, որը բեռնում է նախածանցների և IP հասցեների ցուցակները (որոնք, իհարկե, իրականում /32 նախածանցներ են) ֆայլերից հետագա հայտարարության համար: Թե որտեղից են այս ցուցակները, կքննարկվի ստորև: Խնդրում ենք նկատի ունենալ, որ IP հասցեների բեռնումը լռելյայն մեկնաբանվում է, դրա պատճառը վերբեռնման մեծ ծավալն է: Համեմատության համար նշեմ, որ գրելու պահին նախածանցների ցանկում կա 78 տող, իսկ IP հասցեների ցանկում՝ 85898: Ես խստորեն խորհուրդ եմ տալիս սկսել և վրիպազերծել միայն նախածանցների ցանկում և միացնել IP-ի բեռնումը, թե ոչ: ապագան պետք է որոշեք ձեր երթուղիչի հետ փորձարկումներից հետո: Դրանցից ամեն մեկը չի կարող հեշտությամբ մարսել երթուղային աղյուսակի 85 հազար գրառում։
bgp արձանագրությունը, փաստորեն, կարգավորում է bgp peering-ը ձեր երթուղիչի հետ: IP հասցեն երթուղիչի արտաքին ինտերֆեյսի հասցեն է (կամ թունելի ինտերֆեյսի հասցեն երթուղիչի կողմում), 64998 և 64999 ինքնավար համակարգերի թվերն են: Այս դեպքում դրանք կարող են վերագրվել ցանկացած 16-բիթանոց թվի տեսքով, սակայն լավ պրակտիկա է օգտագործել AS թվեր RFC6996 - 64512-65534 ներառյալ մասնավոր տիրույթից (կա ձևաչափ 32-բիթանոց ASN-ների համար, բայց մեր դեպքում սա միանշանակ չափազանցված է): Նկարագրված կոնֆիգուրացիան օգտագործում է eBGP peering, որի դեպքում երթուղային ծառայության և երթուղիչի ինքնավար համակարգերի համարները պետք է տարբեր լինեն:
Ինչպես տեսնում եք, ծառայությունը պետք է իմանա երթուղիչի IP հասցեն, այնպես որ, եթե դուք ունեք դինամիկ կամ ոչ երթուղղելի մասնավոր (RFC1918) կամ համօգտագործվող (RFC6598) հասցե, դուք հնարավորություն չունեք բարձրացնելու արտաքին կապը: ինտերֆեյս, սակայն ծառայությունը դեռ կաշխատի թունելի ներսում:
Նաև միանգամայն պարզ է, որ մեկ ծառայությունից կարող եք երթուղիներ տրամադրել մի քանի տարբեր երթուղիչներ. պարզապես կրկնօրինակեք դրանց կարգավորումները՝ պատճենելով արձանագրության bgp բաժինը և փոխելով հարևանի IP հասցեն: Այդ իսկ պատճառով օրինակը ցույց է տալիս թունելից դուրս նայելու կարգավորումները՝ որպես ամենաունիվերսալ: Հեշտ է դրանք հեռացնել թունելում՝ համապատասխանաբար փոխելով IP հասցեները կարգավորումներում:
Ռեեստրի մշակում երթուղային ծառայության համար
Այժմ մեզ անհրաժեշտ է, փաստորեն, ստեղծել նախածանցների և IP հասցեների ցուցակներ, որոնք նշված էին նախորդ փուլում արձանագրության ստատիկում: Դա անելու համար մենք վերցնում ենք ռեեստրի ֆայլը և դրանից պատրաստում մեզ անհրաժեշտ ֆայլերը՝ օգտագործելով հետևյալ սկրիպտը, որը տեղադրված է. /root/սև ցուցակ/makebgp
Այժմ դուք կարող եք գործարկել այն ձեռքով և դիտել ֆայլերի տեսքը /etc/bird-ում:
Ամենայն հավանականությամբ, թռչունն այս պահին չի աշխատում ձեզ մոտ, քանի որ նախորդ փուլում դուք նրան խնդրել եք փնտրել դեռևս գոյություն չունեցող ֆայլեր: Հետևաբար, մենք գործարկում ենք այն և ստուգում, որ այն սկսվել է.
systemctl start bird
birdc show route
Երկրորդ հրամանի ելքը պետք է ցույց տա մոտ 80 գրառում (սա առայժմ, բայց երբ այն կարգավորեք, ամեն ինչ կախված կլինի ցանցերի արգելափակման մեջ RKN-ի նախանձախնդրությունից) նման բան.
ցույց կտա ծառայության ներսում արձանագրությունների կարգավիճակը: Քանի դեռ չեք կարգավորել երթուղիչը (տե՛ս հաջորդ կետը), OurRouter արձանագրությունը կլինի մեկնարկային վիճակում (Connect կամ Active փուլ), իսկ հաջող միացումից հետո այն կանցնի վերին վիճակի (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 peering-ը և նշանակել nexthop-ը բոլոր ստացված նախածանցներին՝ մատնացույց անելով մեր թունելը (եթե մեզ անհրաժեշտ է թրաֆիկը ուղարկել p2p ինտերֆեյսի միջոցով) կամ nexthop IP հասցեն, եթե տրաֆիկը գնում է դեպի Ethernet):
Օրինակ, Mikrotik-ում RouterOS-ում դա լուծվում է հետևյալ կերպ
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 ֆայլը, որը սկրիպտի մի քանի հարվածով հեշտությամբ վերածվում է հասցեների աղբյուրի, օրինակ, Chrome-ի SwitchyOmega plugin-ի համար։
Հարկ է նաև նշել, որ լուծումը պահանջում է լրացուցիչ ճշգրտում, եթե դուք ոչ միայն ինտերնետի օգտատեր եք, այլ նաև ինքնուրույն հրապարակում եք որոշ ռեսուրսներ (օրինակ՝ վեբկայքը կամ փոստային սերվերն աշխատում է այս կապով): Օգտագործելով երթուղիչի միջոցները, անհրաժեշտ է խստորեն կապել ելքային երթևեկությունը այս ծառայությունից ձեր հանրային հասցեին, հակառակ դեպքում դուք կկորցնեք կապը այն ռեսուրսների հետ, որոնք ծածկված են երթուղիչի կողմից ստացված նախածանցների ցանկով:
Եթե հարցեր ունեք, հարցրեք, ես պատրաստ եմ պատասխանել։
UPD. Շնորհակալություն նավարկություն и ՏերԱնՅու git-ի պարամետրերի համար, որոնք թույլ են տալիս նվազեցնել ներբեռնման ծավալները:
UPD2. Գործընկերներ, կարծես սխալ եմ թույլ տվել՝ հոդվածում չավելացնելով VPS-ի և երթուղիչի միջև թունելի տեղադրման հրահանգներ: Սրանից շատ հարցեր են առաջանում։
Ամեն դեպքում, ես ևս մեկ անգամ կնշեմ, որ նախքան այս ուղեցույցը սկսելը, դուք արդեն կարգավորել եք VPN թունելը ձեզ անհրաժեշտ ուղղությամբ և ստուգել դրա ֆունկցիոնալությունը (օրինակ՝ երթևեկությունն այնտեղ շրջելով լռելյայն կամ ստատիկ կերպով): Եթե դեռ չեք ավարտել այս փուլը, իմաստ չունի հետևել հոդվածի քայլերին: Ես դեռ չունեմ իմ սեփական տեքստը այս մասին, բայց եթե google-ում եք «ստեղծում OpenVPN սերվեր»՝ VPS-ում տեղադրված օպերացիոն համակարգի անվան հետ միասին, և «ստեղծում OpenVPN հաճախորդ»՝ ձեր երթուղիչի անունով: , դուք, ամենայն հավանականությամբ, կգտնեք մի շարք հոդվածներ այս թեմայով, այդ թվում՝ Habré-ում:
UPD3: Չզոհաբերված Ես գրեցի կոդ, որը dump.csv-ին վերածում է թռչնի համար ստացված ֆայլի՝ IP հասցեների կամայական ամփոփմամբ: Հետևաբար, «Ռեեստրի մշակում երթուղային ծառայության համար» բաժինը կարող է փոխարինվել՝ զանգահարելով դրա ծրագիրը: https://habr.com/post/354282/#comment_10782712
UPD4. Մի փոքր աշխատանք սխալների վրա (ես դրանք չեմ ավելացրել տեքստում).
1) փոխարենը systemctl reload bird իմաստ ունի օգտագործել հրամանը 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=<interface name>
UPD5. Հայտնվել է նոր ծառայություն https://antifilter.download, որտեղից կարող եք վերցնել IP հասցեների պատրաստի ցուցակները։ Թարմացվում է յուրաքանչյուր կես ժամը մեկ: Հաճախորդի կողմից մնում է միայն ձայնագրությունները շրջանակել համապատասխան «երթուղի... մերժել»:
Եվ այս պահին, հավանաբար, բավական է ձեր տատիկին պատռել և թարմացնել հոդվածը:
UPD6. Հոդվածի վերանայված տարբերակը նրանց համար, ովքեր չեն ցանկանում դա պարզել, բայց ցանկանում են սկսել. այստեղ.