BGP:n asettaminen ohittamaan esto tai "Kuinka lopetin pelkäämisen ja rakastuin RKN:ään"

No, okei, sana "rakastui" on liioittelua. Pikemminkin "voi olla rinnakkain".

Kuten kaikki tiedätte, Roskomnadzor on 16. huhtikuuta 2018 lähtien estänyt pääsyn verkon resursseihin erittäin laajoilla vedoilla lisäämällä verkkotunnusten yhtenäiseen rekisteriin, osoittimia Internetin sivustojen sivuille ja verkko-osoitteita, joiden avulla voit tunnistaa Internetistä sivustot, jotka sisältävät tietoa, jonka levittäminen on kielletty Venäjän federaatiossa” (tekstissä - vain rekisteri) /10 joskus. Tämän seurauksena Venäjän federaation kansalaiset ja yritykset kärsivät, koska he ovat menettäneet tarvitsemansa ehdottoman lailliset resurssit.

Sen jälkeen kun sanoin yhden Habré-artikkelin kommenteissa, että olen valmis auttamaan uhreja ohitusjärjestelmän perustamisessa, useat ihmiset ottivat minuun yhteyttä pyytäen tällaista apua. Kun kaikki toimi heille, yksi heistä suositteli tekniikan kuvaamista artikkelissa. Pohdittuani päätin rikkoa hiljaisuuden sivustolla ja yrittää kerrankin kirjoittaa jotain projektin ja Facebook-postauksen väliin, ts. habraposti. Tulos on edessäsi.

Vastuun kieltäminen

Koska ei ole kovin laillista julkaista tapoja, joilla estetään pääsy Venäjän federaation alueella kiellettyihin tietoihin, tämän artikkelin tarkoituksena on puhua menetelmästä, jonka avulla voit automatisoida pääsyn alueella sallittuihin resursseihin. Venäjän federaation kautta, mutta jonkun toiminnan vuoksi ei ole saatavilla suoraan palveluntarjoajasi kautta. Ja pääsy muihin resursseihin, jotka on saatu artikkelin toimien seurauksena, on valitettava sivuvaikutus, eikä se ole missään tapauksessa artikkelin tarkoitus.

Lisäksi, koska olen ammatiltani, ammatiltani ja elämänpolultani ensisijaisesti verkkoarkkitehti, ohjelmointi ja Linux eivät ole vahvuuksiani. Siksi skriptit voidaan tietysti kirjoittaa paremmin, VPS:n tietoturvaongelmat voidaan selvittää syvemmin jne. Ehdotuksesi otetaan kiitollisuudella vastaan, jos ne ovat riittävän yksityiskohtaisia ​​- lisään ne mielelläni artikkelin tekstiin.

TL; DR

Automatisoimme pääsyn resursseihin olemassa olevan tunnelin kautta käyttämällä kopiota rekisteristä ja BGP-protokollasta. Tavoitteena on poistaa kaikki estettyihin resursseihin kohdistettu liikenne tunneliin. Vähimmäisselitys, enimmäkseen vaiheittaiset ohjeet.

Mitä tarvitset tähän

Valitettavasti tämä postaus ei ole kaikille. Jotta voit käyttää tätä tekniikkaa, sinun on koottava muutama elementti:

  1. Sinulla on oltava linux-palvelin jossain estokentän ulkopuolella. Tai ainakin halu käynnistää tällainen palvelin - koska se maksaa nyt 9 dollaria / vuosi ja mahdollisesti vähemmän. Menetelmä sopii myös, jos sinulla on erillinen VPN-tunneli, jolloin palvelin voi sijaita lohkokentän sisällä.
  2. Reitittimesi on oltava tarpeeksi älykäs voidakseen tehdä sen
    • mikä tahansa VPN-asiakas, josta pidät (Pidän parempana OpenVPN:ää, mutta se voi olla PPTP, L2TP, GRE+IPSec ja mikä tahansa muu vaihtoehto, joka luo tunnelirajapinnan);
    • BGPv4-protokolla. Mikä tarkoittaa, että SOHO:lle se voi olla Mikrotik tai mikä tahansa reititin, jossa on OpenWRT/LEDE/vastaava mukautettu laiteohjelmisto, jonka avulla voit asentaa Quaggan tai Birdin. PC-reitittimen käyttöä ei myöskään ole kielletty. Jos kyseessä on yritys, katso rajareitittimesi dokumentaatiosta BGP-tuki.
  3. Sinun tulisi tuntea Linuxin käyttö ja verkkoteknologiat, mukaan lukien BGP. Tai ainakin haluat saada sen idean. Koska en tällä kertaa ole valmis omaksumaan äärimmäisyyttä, sinun on tutkittava joitain kohtia, jotka ovat sinulle käsittämättömiä. Vastaan ​​kuitenkin tiettyihin kysymyksiin kommenteissa, enkä todennäköisesti ole ainoa, joka vastaa, joten kysy rohkeasti.

Mitä esimerkissä käytetään

  • Kopio rekisteristä https://github.com/zapret-info/z-i 
  • VPS - Ubuntu 16.04
  • Reitityspalvelu - lintu 1.6.3   
  • Reititin - Mikrotik hAP ac
  • Toimivat kansiot - koska työskentelemme pääkäyttäjänä, suurin osa kaikesta sijoitetaan pääkansioon. Vastaavasti:
    • /root/blacklist - toimiva kansio käännösskriptillä
    • /root/zi - kopio githubin rekisteristä
    • /etc/bird - lintupalvelun vakioasetuskansio
  • Hyväksymme 194.165.22.146, ASN 64998 VPS:n ulkoiseksi IP-osoitteeksi reitityspalvelimen ja tunnelin päätepisteen kanssa; reitittimen ulkoinen IP-osoite - 81.177.103.94, ASN 64999
  • Tunnelin sisällä olevat IP-osoitteet ovat 172.30.1.1 ja 172.30.1.2.

BGP:n asettaminen ohittamaan esto tai "Kuinka lopetin pelkäämisen ja rakastuin RKN:ään"

Tietenkin voit käyttää mitä tahansa muita reitittimiä, käyttöjärjestelmiä ja ohjelmistotuotteita säätämällä ratkaisua niiden logiikkaan sopivaksi.

Lyhyesti - ratkaisun logiikka

  1. Valmistelutoimet
    1. VPS:n hankkiminen
    2. Nostamme tunnelin reitittimestä VPS:ään
  2. Rekisterin kopion hankkiminen ja säännöllinen päivittäminen
  3. Reitityspalvelun asennus ja konfigurointi
  4. Luo luettelo staattisista reiteistä reitityspalvelulle rekisterin perusteella
  5. Yhdistämme reitittimen palveluun ja asetamme kaiken liikenteen lähettämisen tunnelin läpi.

Varsinainen päätös

Valmistelutoimet

Verkon laajuudessa on monia palveluita, jotka tarjoavat VPS:n erittäin kohtuullisella rahalla. Toistaiseksi olen löytänyt ja käyttänyt 9 dollaria/vuosi vaihtoehdon, mutta vaikka et todellakaan vaivautuisi, on joka kulmassa paljon vaihtoehtoja hintaan 1E/kk. Kysymys VPS:n valinnasta on kaukana tämän artikkelin soveltamisalasta, joten jos jollekin ei ole selvää tästä, kysy kommenteissa.

Jos käytät VPS:ää paitsi reitityspalveluun, myös tunnelin päättämiseen siinä, sinun on nostettava tämä tunneli ja määritettävä sille lähes yksiselitteisesti NAT. Verkossa on suuri määrä ohjeita näihin toimiin, en toista niitä tässä. Tällaisen tunnelin päävaatimus on, että sen on luotava erillinen käyttöliittymä reitittimellesi, joka tukee tunnelia VPS:ään. Useimmat käytetyt VPN-tekniikat täyttävät tämän vaatimuksen - esimerkiksi OpenVPN tun-tilassa on hyvä.

Hanki kopio rekisteristä

Kuten Jabrayil sanoi: "Se, joka estää meitä, auttaa meitä." Koska RKN luo rekisteriä kiellettyistä resursseista, olisi syntiä olla käyttämättä tätä rekisteriä ongelmamme ratkaisemiseen. Saamme kopion rekisteristä githubilta.

Menemme Linux-palvelimellesi, joudumme root'a (sudo su-) ja asenna git, jos sitä ei ole jo asennettu.

apt install git

Mene kotihakemistoosi ja vedä kopio rekisteristä.

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

Aseta cron-päivitys (minulla on se 20 minuutin välein, mutta voit valita minkä tahansa sinua kiinnostavan intervallin). Tätä varten käynnistämme crontab -e ja lisää siihen seuraava rivi:

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

Yhdistämme koukun, joka luo tiedostot reitityspalveluun rekisterin päivityksen jälkeen. Tätä varten luomme tiedoston /root/zi/.git/hooks/post-merge seuraavalla sisällöllä:

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

äläkä unohda tehdä siitä suoritettavaa

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

Hookin viittaama makebgp-skripti luodaan myöhemmin.

Reitityspalvelun asennus ja konfigurointi

Asenna lintu. Valitettavasti tällä hetkellä Ubuntu-varastoissa julkaistu lintuversio on verrattavissa tuoreudeltaan Archeopteryxin ulosteisiin, joten meidän on ensin lisättävä järjestelmään ohjelmistokehittäjien virallinen PPA.

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

Sen jälkeen poistamme Bird välittömästi käytöstä IPv6:lle - tässä asennuksessa emme tarvitse sitä.

systemctl stop bird6
systemctl disable bird6

Alla on lintupalvelun minimalistinen asetustiedosto (/etc/bird/bird.conf), joka on meille aivan riittävä (ja vielä kerran muistutan, että kukaan ei kiellä kehittämästä ja virittämästä ideaa omiin tarpeisiisi)

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

reitittimen tunnus - reitittimen tunniste, joka näyttää visuaalisesti IPv4-osoitteelta, mutta se ei ole sitä. Meidän tapauksessamme se voi olla mikä tahansa 32-bittinen numero IPv4-osoitemuodossa, mutta on hyvä käytäntö määrittää laitteesi IPv4-osoite (tässä tapauksessa VPS) siihen.

Protocol direct määrittää, mitkä rajapinnat toimivat reititysprosessin kanssa. Esimerkki antaa pari esimerkkiä nimistä, voit lisätä lisää. Voit myös yksinkertaisesti poistaa rivin, jolloin palvelin kuuntelee kaikkia saatavilla olevia IPv4-osoitteen liitäntöjä.

staattinen protokolla on taikuuttamme, joka lataa tiedostoista luettelot etuliitteistä ja IP-osoitteista (jotka ovat tietysti /32-etuliitteet) myöhempää ilmoitusta varten. Mistä nämä luettelot ovat peräisin, käsitellään alla. Huomaa, että ip-osoitteiden lataaminen on oletusarvoisesti kommentoitu, syynä tähän on suuri latausmäärä. Vertailun vuoksi artikkelin kirjoitushetkellä riviä etuliitteiden luettelossa oli 78 ja IP-osoitteiden luettelossa 85898. Suosittelen, että aloitat ja debugaat vain etuliitteiden luettelosta ja päätät, onko vai ei. salliaksesi IP-latauksen tulevaisuudessa, kun olet kokeillut reitittimesi kanssa. Jokainen heistä ei pysty helposti sulattamaan 85 tuhatta merkintää reititystaulukossa.

protokolla bgp itse asiassa määrittää bgp-liikenteen reitittimesi kanssa. ip-osoite on reitittimen ulkoisen liitännän osoite (tai tunnelirajapinnan osoite reitittimen puolelta), 64998 ja 64999 ovat autonomisten järjestelmien numeroita. Tässä tapauksessa ne voidaan määrittää minkä tahansa 16-bittisten numeroiden muodossa, mutta on hyvä käytäntö käyttää AS-numeroita RFC6996 - 64512-65534 määrittelemästä yksityisestä alueesta (on 32-bittinen ASN-muoto, mutta meidän tapauksessamme tämä on ehdottomasti ylivoimaista). Kuvatussa konfiguraatiossa käytetään eBGP-peeringiä, jossa reitityspalvelun ja reitittimen autonomisten järjestelmänumeroiden tulee olla erilaisia.

Kuten näet, palvelun on tiedettävä reitittimen IP-osoite, joten jos sinulla on dynaaminen tai ei-reititettävä yksityinen (RFC1918) tai jaettu (RFC6598) osoite, sinulla ei ole mahdollisuutta nostaa peeringiä ulkoisessa rajapinnassa, mutta palvelu toimii edelleen tunnelin sisällä.

On myös melko läpinäkyvää, että voit tarjota useille eri reitittimille reittejä yhdestä palvelusta - kopioi niiden asetukset kopioimalla protokollan bgp-osio vaihtamalla naapurin IP-osoitetta. Tästä syystä esimerkki näyttää asetukset tunnelin ulkopuolelle katsomiselle yleisimmillään. Niiden poistaminen tunneliin ei ole vaikeaa muuttamalla IP-osoitteita asetuksissa vastaavasti.

Rekisterinkäsittely reitityspalvelua varten

Nyt meidän on itse asiassa luotava luetteloita etuliitteistä ja ip-osoitteista, jotka mainitaan edellisessä vaiheessa protokollastatic. Tätä varten otamme rekisteritiedoston ja teemme siitä tarvitsemamme tiedostot seuraavalla skriptillä, joka sijaitsee /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'

Älä unohda tehdä siitä suoritettavaa

chmod +x /root/blacklist/makebgp

Nyt voit ajaa sen manuaalisesti ja tarkkailla tiedostojen ulkoasua /etc/bird-hakemistossa.

Todennäköisesti tällä hetkellä lintu ei toimi sinulle, koska edellisessä vaiheessa ehdotit, että se etsii tiedostoja, joita ei vielä ollut olemassa. Siksi käynnistämme sen ja hallitsemme sen käynnistymistä:

systemctl start bird
birdc show route

Toisen komennon lähdön pitäisi näyttää noin 80 merkintää (tämä on tällä hetkellä, ja kun määrität sen, kaikki riippuu ILV:n innokkuudesta verkkojen estämisessä) seuraavasti:

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

Joukkue

birdc show protocol

näyttää palvelun protokollien tilan. Kunnes määrität reitittimen (katso seuraava kappale), OurRouter-protokolla on aloitustilassa (Connect- tai Active-vaiheet), ja onnistuneen yhteyden jälkeen se siirtyy ylös-tilaan (Established-vaihe). Esimerkiksi järjestelmässäni tämän komennon tulos näyttää tältä:

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

Reitittimen yhdistäminen

Kaikki ovat luultavasti jo kyllästyneet lukemaan tätä jalkaliinaa, mutta ota rohkeasti - loppu on lähellä. Lisäksi tässä osiossa en voi antaa vaiheittaisia ​​​​ohjeita - se on erilainen jokaiselle valmistajalle.

Voin kuitenkin näyttää sinulle pari esimerkkiä. Päälogiikka on nostaa BGP peering ja liittää nexthop kaikkiin vastaanotettuihin etuliitteisiin osoittaen meidän tunneliimme (jos sinun on tulostettava liikennettä p2p-liitännän kautta) tai nexthop ip-osoitteeseen, jos liikenne menee ethernetiin).

Esimerkiksi RouterOS:n Mikrotikissa tämä ratkaistaan ​​seuraavasti

/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:ssä - näin

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

Siinä tapauksessa, että samaa tunnelia käytetään sekä BGP-liikenteen vaihtoon että hyödyllisen liikenteen välittämiseen, nexthopia ei tarvitse asettaa, vaan se asetetaan oikein protokollan avulla. Mutta jos asetat sen manuaalisesti, se ei myöskään huonone.

Muilla alustoilla sinun on selvitettävä kokoonpano itse, mutta jos sinulla on vaikeuksia, kirjoita kommentteihin, yritän auttaa.

Kun BGP-istuntosi on noussut, reitit suuriin verkkoihin ovat saapuneet ja asennettu taulukkoon, liikenne niistä on mennyt osoitteisiin ja onnellisuus on lähellä, voit palata lintupalveluun ja yrittää poistaa kommentin sieltä, joka yhdistää luettelo ip-osoitteista, suorita sen jälkeen

systemctl reload bird

ja katso kuinka reitittimesi siirsi nämä 85 tuhatta reittiä. Valmistaudu sammuttamaan se ja miettimään mitä tehdä sillä 🙂

Yhteensä

Puhtaasti teoreettisesti yllä olevien vaiheiden suorittamisen jälkeen sinulla on palvelu, joka ohjaa automaattisesti liikenteen IP-osoitteisiin, jotka on kielletty Venäjän federaatiossa suodatusjärjestelmän ohi.

Sitä voidaan tietysti parantaa. Esimerkiksi IP-osoitteiden luettelon yhteenveto perl- tai python-ratkaisujen avulla on tarpeeksi helppoa. Yksinkertainen perl-komentosarja, joka tekee tämän Net::CIDR::Liten kanssa, muuttaa 85 60 etuliitettä XNUMX:ksi (ei tuhanneksi), mutta kattaa luonnollisesti paljon suuremman osoitteen alueen kuin estetään.

Koska palvelu toimii ISO / OSI-mallin kolmannella tasolla, se ei säästä sinua sivuston / sivun estosta, jos se ei ratkaise rekisteriin tallennettua osoitetta. Mutta githubin rekisterin mukana saapuu nxdomain.txt-tiedosto, joka muutamalla skriptin vedolla muuttuu helposti osoitelähteeksi esimerkiksi Chromen SwitchyOmega-laajennukselle.

On myös syytä mainita, että ratkaisu vaatii lisäterävyyttä, jos et ole vain Internetin käyttäjä, vaan julkaiset myös joitain resursseja itsestäsi (esimerkiksi verkkosivusto tai sähköpostipalvelin toimii tällä yhteydellä). Reitittimen avulla sinun on sidottava tästä palvelusta lähtevä liikenne julkiseen osoitteeseesi, muuten menetät yhteyden niihin resursseihin, jotka kuuluvat reitittimen vastaanottamien etuliitteiden luetteloon.

Jos sinulla on kysyttävää - kysy, valmis vastaamaan.

UPD. Kiitos navigointi и TerAnYu gitin vaihtoehdoista latausmäärien vähentämiseksi.

UPD2. Hyvät kollegat, näyttää siltä, ​​että tein virheen, kun en lisännyt artikkeliin ohjeita VPS:n ja reitittimen välisen tunnelin perustamisesta. Tästä syntyy paljon kysymyksiä.
Varmuuden vuoksi huomautan uudelleen - oletetaan, että ennen tämän oppaan vaiheiden aloittamista olet jo konfiguroinut VPN-tunnelin haluamaasi suuntaan ja tarkistanut sen suorituskyvyn (esimerkiksi liikenteen kääriminen sinne oletuksena tai staattisena). Jos et ole vielä suorittanut tätä vaihetta, ei todellakaan ole järkevää seurata artikkelin ohjeita. Minulla ei ole vielä omaa tekstiä tästä, mutta jos googletat "OpenVPN-palvelimen asetukset" yhdessä VPS:ään asennetun käyttöjärjestelmän nimen kanssa ja "OpenVPN-asiakasasetukset" reitittimesi nimellä, todennäköisesti löydät useita artikkeleita tästä aiheesta, mukaan lukien Habré.

UPD3. Uhraamaton kirjoitti koodin, joka tekee tuloksena olevan tiedoston linnulle dump.csv-tiedostosta valinnaisella IP-osoitteiden summauksella. Siksi "Reittipalvelun rekisterikäsittely" -osio voidaan korvata kutsulla sen ohjelmaan. https://habr.com/post/354282/#comment_10782712

UPD4. Vähän työtä virheiden parissa (ei vaikuttanut tekstiin):
1) sen sijaan systemctl reload lintu on järkevää käyttää komentoa birdc-asetukset.
2) Mikrotik-reitittimessä sen sijaan, että muuttaisit seuraavan hypyn tunnelin toisen puolen IP-osoitteeseen /routing filter add action=accept chain=dynamic-in protocol=bgp comment="Aseta nexthop" set-in-nexthop=172.30.1.1 on järkevää määrittää reitti suoraan tunnelirajapintaan ilman osoitetta /routing filter add action=accept chain=dynamic-in protocol=bgp comment="Aseta nexthop" set-in-nexthop-direct=<liitännän nimi>

UPD5. Uusi palvelu on saapunut https://antifilter.download, josta voit ottaa valmiita luetteloita ip-osoitteista. Päivitetään puolen tunnin välein. Asiakaspuolella ei jää muuta kuin kehystää merkinnät vastaavalla "reitti ... hylkäämällä".
Ja se luultavasti riittää isoäitilleni ja artikkelin päivittämiseen.

UPD6. Artikkelin tarkistettu versio niille, jotka eivät halua ymmärtää, mutta haluavat aloittaa - täällä.

Lähde: will.com

Lisää kommentti