BGP seadistamine blokeerimisest möödahiilimiseks või "Kuidas ma lõpetasin kartmise ja armusin RKN-i"

Noh, okei, "armusin" on liialdus. Pigem "võiks koos eksisteerida".

Nagu te kõik teate, on Roskomnadzor alates 16. aprillist 2018 väga laiaulatuslikult blokeerinud juurdepääsu võrgus olevatele ressurssidele, lisades ühtsesse domeeninimede registrisse, viiteid Interneti-saitide lehtedele ja võrguaadresse, mis võimaldavad teil tuvastada Internetis saidid, mis sisaldavad teavet, mille levitamine on Vene Föderatsioonis keelatud” (tekstis - lihtsalt register) /10 mõnikord. Selle tulemusena kannatavad Vene Föderatsiooni kodanikud ja ettevõtted, kes on kaotanud juurdepääsu absoluutselt legaalsetele ressurssidele, mida nad vajavad.

Pärast seda, kui ütlesin ühe Habré-teemalise artikli kommentaarides, et olen valmis ohvreid aitama möödasõiduskeemi loomisel, võtsid minuga ühendust mitu inimest, kes sellist abi palusid. Kui kõik nende jaoks töötas, soovitas üks neist tehnikat artiklis kirjeldada. Järele mõeldes otsustasin saidil oma vaikuse katkestada ja proovida ükskord kirjutada midagi vahepealset projekti ja Facebooki postituse vahele, st. habrapost. Tulemus on teie ees.

Kaebused

Kuna Vene Föderatsiooni territooriumil keelatud teabele juurdepääsu blokeerimisest möödahiilimise võimaluste avaldamine pole eriti seaduslik, on selle artikli eesmärk rääkida meetodist, mis võimaldab automatiseerida juurdepääsu ressurssidele, mis on lubatud Vene Föderatsiooni territooriumil, kuid kellegi tegevuse tõttu pole juurdepääs otse teie teenusepakkuja kaudu. Ja juurdepääs teistele ressurssidele, mis on saadud artiklist tulenevate toimingute tulemusena, on kahetsusväärne kõrvalmõju ega ole mingil juhul artikli eesmärk.

Samuti, kuna olen elukutselt, kutselt ja eluteelt eelkõige võrguarhitekt, pole programmeerimine ja Linux minu tugevad küljed. Seetõttu saab loomulikult skripte paremini kirjutada, VPS-i turvaprobleeme sügavamalt läbi töötada jne. Teie ettepanekud võetakse tänuga vastu, kui need on piisavalt üksikasjalikud - lisan need hea meelega artikli teksti.

TL; DR

Automatiseerime juurdepääsu ressurssidele teie olemasoleva tunneli kaudu, kasutades registri koopiat ja BGP-protokolli. Eesmärk on eemaldada tunnelisse kogu blokeeritud ressurssidele suunatud liiklus. Minimaalne selgitus, enamasti samm-sammult juhised.

Mida selleks vaja on

Kahjuks pole see postitus kõigile mõeldud. Selle tehnika kasutamiseks peate kokku panema mõned elemendid:

1. Sul peab olema linuxi server kusagil väljaspool blokeerimisvälja. Või vähemalt soov sellist serverit käivitada - kuna see maksab nüüd alates 9 dollarist aastas ja võib-olla vähem. Meetod sobib ka siis, kui sul on eraldi VPN tunnel, siis võib server asuda plokivälja sees.
2. Teie ruuter peab olema piisavalt tark, et seda teha
   • mis tahes VPN-klient, mis teile meeldib (ma eelistan OpenVPN-i, kuid see võib olla PPTP, L2TP, GRE+IPSec ja mis tahes muu tunneli liidese loomine);
   • BGPv4 protokoll. Mis tähendab, et SOHO jaoks võib selleks olla Mikrotik või ükskõik milline OpenWRT/LEDE/sarnase kohandatud püsivaraga ruuter, mis võimaldab installida Quagga või Birdi. Ka arvutiruuteri kasutamine pole keelatud. Ettevõtte jaoks vaadake BGP-toe saamiseks piirimarsruuteri dokumentatsiooni.
3. Peaksite olema tuttav Linuxi kasutamise ja võrgutehnoloogiatega, sealhulgas BGP-ga. Või vähemalt tahta seda mõtet saada. Kuna ma ei ole seekord valmis seda mõõtmatust omaks võtma, peate omal käel uurima mõningaid teile arusaamatuid punkte. Konkreetsete küsimuste puhul vastan aga loomulikult kommentaarides ja tõenäoliselt ei vasta ma ainuke, seega küsige julgelt.

Mida näites kasutatakse

• Registri koopia https://github.com/zapret-info/z-i 
• VPS – Ubuntu 16.04
• Marsruutimisteenus - lind 1.6.3   
• Ruuter - Mikrotik hAP ac
• Töötavad kaustad – kuna töötame rootina, paigutatakse enamus kõigest kodujuurkausta. Vastavalt:
  • /root/blacklist – kompileerimisskriptiga töötav kaust
  • /root/zi – githubi registri koopia
  • /etc/bird – standardsete linnuteenuse sätete kaust
• VPS-i välise IP-aadressina koos marsruutimisserveri ja tunneli lõpp-punktiga aktsepteerime 194.165.22.146, ASN 64998; ruuteri väline IP-aadress - 81.177.103.94, ASN 64999
• Tunnelis olevad IP-aadressid on vastavalt 172.30.1.1 ja 172.30.1.2.

Loomulikult võite kasutada ka muid ruutereid, operatsioonisüsteeme ja tarkvaratooteid, kohandades lahendust nende loogikaga sobivaks.

Lühidalt – lahenduse loogika

1. Ettevalmistavad toimingud
   1. VPS-i hankimine
   2. Tõstame tunneli ruuterist VPS-i
2. Registri koopia hankimine ja korrapärane värskendamine
3. Marsruutimisteenuse installimine ja konfigureerimine
4. Looge registri põhjal marsruutimisteenuse staatiliste marsruutide loend
5. Ühendame ruuteri teenusega ja seadistame kogu liikluse tunneli kaudu saatmise.

Tegelik otsus

Ettevalmistavad toimingud

Võrgu laiuses on palju teenuseid, mis pakuvad VPS-i äärmiselt mõistliku raha eest. Siiani olen leidnud ja kasutanud võimalust 9 dollarit aastas, kuid isegi kui te väga ei viitsi, on iga nurga peal palju võimalusi 1E / kuus. VPS-i valimise küsimus jääb selle artikli ulatusest kaugele kaugemale, nii et kui kellelegi pole selles osas midagi selge, küsige kommentaarides.

Kui kasutate VPS-i mitte ainult marsruutimisteenuse jaoks, vaid ka sellel oleva tunneli lõpetamiseks, peate selle tunneli üles tõstma ja peaaegu ühemõtteliselt konfigureerima selle jaoks NAT-i. Nende toimingute jaoks on võrgus palju juhiseid, ma ei korda neid siin. Sellise tunneli põhinõue on, et see peab looma teie ruuterile eraldi liidese, mis toetab tunnelit VPS-i suunas. Enamik kasutatavaid VPN-tehnoloogiaid vastavad sellele nõudele – näiteks OpenVPN tun-režiimis on hea.

Hankige registri koopia

Nagu Jabrayil ütles: "See, kes meid takistab, aitab meid." Kuna RKN loob keelatud ressursside registrit, oleks patt seda registrit meie probleemi lahendamiseks mitte kasutada. Githubist saame registri koopia.

Me läheme teie Linuxi serverisse, langeme juure konteksti (sudo su-) ja installige git, kui see pole veel installitud.

apt install git

Minge oma kodukataloogi ja tõmmake välja registri koopia.

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

Seadistage cron-värskendus (mul on see iga 20 minuti järel, kuid saate valida mis tahes teile huvipakkuva intervalli). Selleks jookseme crontab -e ja lisage sellele järgmine rida:

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

Ühendame konksu, mis loob pärast registri värskendamist marsruutimisteenuse failid. Selleks loome faili /root/zi/.git/hooks/post-merge järgmise sisuga:

#!/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"

ja ärge unustage seda käivitatavaks muuta

chmod +x /root/z-i/.git/hooks/post-merge

Hooki viidatud makebgp skript luuakse hiljem.

Marsruutimisteenuse installimine ja konfigureerimine

Paigalda lind. Kahjuks on praegu Ubuntu hoidlates avaldatud linnu versioon värskuse poolest võrreldav Archeopteryxi väljaheidetega, seega peame esmalt süsteemi lisama tarkvaraarendajate ametliku PPA.

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

Pärast seda keelame linnu IPv6 jaoks kohe välja - selles installis me seda ei vaja.

systemctl stop bird6
systemctl disable bird6

Allpool on linnuteenuse minimalistlik konfiguratsioonifail (/etc/bird/bird.conf), mis on meile täiesti piisav (ja veel kord tuletan meelde, et keegi ei keela ideed enda vajadustele vastavaks arendada ja häälestada)

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;
}

ruuteri id - ruuteri identifikaator, mis näeb visuaalselt välja nagu IPv4 aadress, kuid see pole nii. Meie puhul võib see olla suvaline 32-bitine number IPv4 aadressivormingus, kuid hea tava on määrata seal oma seadme (antud juhul VPS) IPv4 aadress.

Protocol Direct määrab, millised liidesed marsruutimisprotsessiga töötavad. Näites on paar nimenäidet, võite lisada veel. Samuti saate rea lihtsalt kustutada, sel juhul kuulab server kõiki saadaolevaid IPv4-aadressiga liideseid.

staatiline protokoll on meie võlu, mis laadib failidest eesliidete ja IP-aadresside loendid (mis on loomulikult /32 prefiksid) hilisemaks teatamiseks. Sellest, kust need nimekirjad pärinevad, arutatakse allpool. Pane tähele, et IP-aadresside laadimine on vaikimisi välja kommenteeritud, põhjuseks on suur üleslaadimiste hulk. Võrdluseks, artikli kirjutamise ajal oli eesliidete loendis rida 78 ja IP-aadresside loendis 85898. Soovitan tungivalt alustada ja siluda ainult eesliidete loendis ning otsustada, kas või mitte. IP-aadressi laadimise lubamiseks pärast ruuteriga katsetamist. Mitte igaüks neist ei suuda hõlpsalt seedida marsruutimistabeli 85 tuhat kirjet.

protokolli bgp seadistab tegelikult teie ruuteriga bgp-i ühenduse. ip-aadress on ruuteri välisliidese aadress (või tunneli liidese aadress ruuteri küljelt), 64998 ja 64999 on autonoomsete süsteemide numbrid. Sel juhul saab neid määrata mis tahes 16-bitiste numbrite kujul, kuid hea tava on kasutada RFC6996-64512-65534 (kaasa arvatud) defineeritud privaatvahemiku AS-numbreid (olemas on 32-bitine ASN-vorming, kuid meie puhul on see kindlasti liialdatud). Kirjeldatud konfiguratsioonis kasutatakse eBGP peeringut, mille puhul peavad marsruutimisteenuse ja ruuteri autonoomsed süsteeminumbrid olema erinevad.

Nagu näete, peab teenus teadma ruuteri IP-aadressi, nii et kui teil on dünaamiline või mittemarsruutitav privaatne (RFC1918) või jagatud (RFC6598) aadress, pole teil võimalust välise liidese kaudu suhtlust tõsta, kuid teenus töötab tunnelis ikkagi.

Üsna läbipaistev on ka see, et ühest teenusest saab marsruute pakkuda mitmele erinevale ruuterile – lihtsalt dubleeri nende jaoks sätted, kopeerides protokolli bgp sektsiooni koos naabri IP-aadressi muutmisega. Seetõttu on näites väljas tunnelist piilumise seaded kõige universaalsemad. Neid pole keeruline tunnelisse eemaldada, muutes seadetes vastavalt IP-aadresse.

Marsruutimisteenuse registri töötlemine

Nüüd peame tegelikult looma eesliidete ja IP-aadresside loendid, mida mainiti eelmises etapis protokollis staatiline. Selleks võtame registrifaili ja teeme sellest järgmise skriptiga, mis asub, vajalikud failid /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'

Ärge unustage seda käivitatavaks muuta

chmod +x /root/blacklist/makebgp

Nüüd saate seda käsitsi käivitada ja jälgida failide välimust kaustas /etc/bird.

Tõenäoliselt praegu lind teie jaoks ei tööta, kuna eelmisel etapil soovitasite tal otsida faile, mida veel ei eksisteerinud. Seetõttu käivitame selle ja kontrollime selle käivitumist:

systemctl start bird
birdc show route

Teise käsu väljund peaks näitama umbes 80 kirjet (see on hetkel ja selle seadistamisel sõltub kõik ILV innukusest võrkude blokeerimisel) järgmiselt:

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

Meeskond

birdc show protocol

näitab teenuse protokollide olekut. Kuni ruuteri konfigureerimiseni (vt järgmist lõiku), on OurRouteri protokoll käivitusolekus (ühendamise või aktiivse faasid) ja pärast edukat ühenduse loomist läheb see üles olekusse (kehtestatud faas). Näiteks minu süsteemis näeb selle käsu väljund välja järgmine:

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

Ruuteri ühendamine

Tõenäoliselt on kõik juba väsinud selle jalalapi lugemisest, aga võta näpust – lõpp on käes. Veelgi enam, selles jaotises ei saa ma anda samm-sammult juhiseid - see on iga tootja jaoks erinev.

Siiski võin teile tuua paar näidet. Peamine loogika on tõsta BGP peering ja lisada nexthop kõigile vastuvõetud eesliidetele, osutades meie tunnelile (kui teil on vaja liiklust p2p liidese kaudu väljastada) või nexthopi ip-aadressile, kui liiklus läheb Etherneti).

Näiteks RouterOS-i Mikrotiku puhul lahendatakse see järgmiselt

/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

ja Cisco IOS-is – niimoodi

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

Juhul, kui sama tunnelit kasutatakse nii BGP peeringuks kui ka kasuliku liikluse edastamiseks, ei ole nexthopi seadistamine vajalik, see seadistatakse õigesti protokolli abil. Aga kui käsitsi seadistada, siis ei lähe ka hullemaks.

Teistel platvormidel peate konfiguratsiooni ise välja mõtlema, kuid kui teil on raskusi, kirjutage kommentaaridesse, proovin aidata.

Kui teie BGP seanss on tõusnud, marsruudid suurtesse võrkudesse on saabunud ja tabelisse installitud, liiklus nendelt aadressidele on kadunud ja õnn on lähedal, võite naasta linnuteenistusse ja proovida seal olevat kirjet, mis ühendab IP-aadresside loend, käivitage pärast seda

systemctl reload bird

ja vaadake, kuidas teie ruuter need 85 tuhat marsruuti üle kandis. Ole valmis selle välja lülitama ja mõtle, mida sellega peale hakata 🙂

Kogusummas

Puhtalt teoreetiliselt on teil pärast ülaltoodud toimingute tegemist teenus, mis suunab liikluse automaatselt ümber filtreerimissüsteemist mööda Vene Föderatsioonis keelatud IP-aadressidele.

Seda saab muidugi parandada. Näiteks on piisavalt lihtne teha kokkuvõtteid IP-aadresside loendist perli või pythoni lahenduste kaudu. Lihtne perli skript, mis teeb seda Net::CIDR::Lite'iga, muudab 85 tuhat eesliidet 60-ks (mitte tuhandeks), kuid katab loomulikult palju suurema aadresside vahemiku kui blokeeritud.

Kuna teenus töötab ISO / OSI mudeli kolmandal tasemel, ei päästa see teid saidi / lehe blokeerimisest, kui see ei lahenda registris registreeritud aadressi. Kuid koos githubi registriga saabub fail nxdomain.txt, mis mõne skriptitõmbega muutub kergesti aadresside allikaks näiteks Chrome'i SwitchyOmega pistikprogrammi jaoks.

Olgu ka mainitud, et lahendus nõuab täiendavat lihvimist, kui sa pole lihtsalt internetikasutaja, vaid avaldad ka endalt mingeid ressursse (sel ühendusel töötab näiteks veebileht või meiliserver). Ruuteri abil peate sellest teenusest väljuva liikluse kõvasti siduma oma avaliku aadressiga, vastasel juhul kaotate ühenduse nende ressurssidega, mis on hõlmatud ruuteri vastuvõetud eesliidete loendiga.

Kui teil on küsimusi - küsige, valmis vastama.

UPD. Aitäh navigatsioon и TerAnYu giti võimaluste kohta allalaadimismahtude vähendamiseks.

UPD2. Kolleegid, tundub, et tegin vea, kui ei lisanud artiklisse juhiseid VPS-i ja ruuteri vahelise tunneli loomise kohta. See tekitab palju küsimusi.
Igaks juhuks märgin veel kord – eeldatakse, et enne selles juhendis kirjeldatud sammude alustamist olete VPN-tunneli juba vajalikus suunas konfigureerinud ja selle toimivust kontrollinud (näiteks liikluse mähimine sinna vaikimisi või staatiliselt). Kui te pole seda etappi veel lõpetanud, ei ole tegelikult mõtet artiklis toodud samme järgida. Mul ei ole selle kohta veel oma teksti, kuid kui te googeldate "OpenVPN-serveri seadistus" koos VPS-i installitud operatsioonisüsteemi nimega ja "OpenVPN-i kliendi seadistus" oma ruuteri nimega, siis tõenäoliselt leiate sellel teemal mitmeid artikleid , sealhulgas Habré kohta.

UPD3. Ohverdamata kirjutas koodi, mis teeb tulemuseks oleva linnu faili dump.csv-st koos IP-aadresside valikulise liitmisega. Seetõttu saab jaotise "Marsruutimisteenuse registri töötlemine" asendada selle programmi kutsega. https://habr.com/post/354282/#comment_10782712

UPD4. Natuke tööd vigade kallal (ei aidanud tekstis kaasa):
1) selle asemel systemctl reload lind on mõttekas kasutada käsku birdc konfigureerimine.
2) Mikrotik ruuteris, selle asemel, et muuta järgmine hüpe tunneli teise poole IP-ks /marsruutimise filter add action=accept chain=dynamic-in protocol=bgp comment="Määra nexthop" set-in-nexthop=172.30.1.1 marsruut on mõistlik määrata otse tunneli liidesesse, ilma aadressita /marsruutimise filter add action=accept chain=dynamic-in protocol=bgp comment="Määra nexthop" set-in-nexthop-direct=<liidese nimi>

UPD5. Uus teenus on saabunud https://antifilter.download, kust saab võtta valmis ip-aadresside loendeid. Uuendatakse iga poole tunni tagant. Kliendi poolel jääb üle vaid raamida kirjed vastava “marsruut ... tagasilükkamisega”.
Ja sellest ilmselt piisab, et mu vanaema tujutada ja artiklit värskendada.

UPD6. Artikli muudetud versioon neile, kes ei taha aru saada, kuid soovivad alustada - siin.

Allikas: www.habr.com