🥇A BGP konfigurálása a blokkolás megkerülésére, vagy „Hogyan hagytam abba a félelmet és szerettem bele az RKN-be”

Nos, oké, a „szeretett” túlzás. Inkább „együtt tudott élni vele”.

Mint mindannyian tudják, 16. április 2018. óta a Roszkomnadzor rendkívül nagy vonalakban blokkolja az internetes forrásokhoz való hozzáférést, kiegészítve a „Domainnevek, az internetes webhelyek oldalindexeinek és a webhelyek azonosítását lehetővé tevő hálózati címek egységes nyilvántartásával”. az interneten”, amely olyan információkat tartalmaz, amelyek terjesztése az Orosz Föderációban tilos” (a szövegben - csak egy nyilvántartás) néha /10. Ennek eredményeként az Orosz Föderáció polgárai és a vállalkozások szenvednek, mivel elvesztették hozzáférésüket a számukra szükséges, teljesen legális forrásokhoz.

Miután az egyik Habré-cikk kommentjében elmondtam, hogy kész vagyok segíteni az áldozatokon egy elkerülő rendszer felállításában, többen is kerestek ilyen segítséget. Amikor minden működött nekik, egyikük azt javasolta, hogy írja le a technikát egy cikkben. Némi gondolkodás után úgy döntöttem, megtöröm a hallgatásomat az oldalon, és egyszer megpróbálok valami közteset írni egy projekt és egy Facebook-bejegyzés közé, pl. habrapost. Az eredmény előtted van.

A felelősség megtagadása

Mivel nem túl legális az Orosz Föderáció területén tiltott információkhoz való hozzáférés blokkolásának megkerülésének módjainak közzététele, ennek a cikknek az a célja, hogy egy olyan módszerről szóljon, amely lehetővé teszi az interneten engedélyezett erőforrásokhoz való hozzáférés automatizálását. az Orosz Föderáció területén, de valaki tevékenysége miatt nem érhetők el közvetlenül az Ön szolgáltatóján keresztül. És a cikkből származó műveletek eredményeként megszerzett egyéb forrásokhoz való hozzáférés sajnálatos mellékhatás, és semmiképpen sem a cikk célja.

Továbbá, mivel hivatásom, elhivatottságom és életútom alapján elsősorban hálózati építész vagyok, a programozás és a Linux nem az erősségeim. Így természetesen jobban meg lehet írni a szkripteket, mélyebben ki lehet dolgozni a VPS biztonsági problémáit stb. Javaslatait köszönettel fogadjuk, ha kellően részletesek – szívesen kiegészítem a cikk szövegével.

TL, DR

Automatizáljuk az erőforrásokhoz való hozzáférést a meglévő alagúton keresztül, a rendszerleíró adatbázis és a BGP-protokoll másolatának használatával. A cél az, hogy a blokkolt erőforrásoknak címzett összes forgalmat eltávolítsák az alagútból. Minimális magyarázatok, többnyire lépésenkénti instrukciók.

Mi kell ehhez?

Sajnos ez a bejegyzés nem mindenkinek szól. A technika használatához több elemet kell összeállítania:

Valahol a blokkoló mezőn kívül kell lennie egy linux szervernek. Vagy legalábbis a vágy, hogy legyen egy ilyen szerver – szerencsére most már 9 dollárba kerül/év, és talán kevesebb is. A módszer akkor is megfelelő, ha van egy külön VPN alagút, akkor a szerver a blokkoló mezőn belül is elhelyezhető.
Az útválasztónak elég okosnak kell lennie ahhoz, hogy képes legyen rá
- tetszőleges VPN kliens (én az OpenVPN-t részesítem előnyben, de lehet PPTP, L2TP, GRE+IPSec vagy bármilyen más lehetőség, ami alagút interfészt hoz létre);
- BGPv4 protokoll. Ami azt jelenti, hogy a SOHO számára ez lehet Mikrotik vagy bármilyen OpenWRT/LEDE/hasonló egyedi firmware-rel rendelkező router, amely lehetővé teszi a Quagga vagy a Bird telepítését. A számítógépes útválasztó használata szintén nem tilos. Vállalat esetén keresse meg a BGP támogatást a border router dokumentációjában.
Ismernie kell a Linux használatát és a hálózati technológiákat, beleértve a BGP protokollt is. Vagy legalábbis szeretne ilyen ötletet kapni. Mivel ezúttal nem állok készen a mérhetetlenség befogadására, néhány számodra érthetetlen szempontot egyedül kell tanulmányoznod. Természetesen konkrét kérdésekre válaszolok a megjegyzésekben, és nem valószínű, hogy én leszek az egyetlen, aki válaszol, ezért ne habozzon kérdezni.

Mit használunk a példában

Az anyakönyv másolata - tól https://github.com/zapret-info/z-i
VPS – Ubuntu 16.04
Útválasztási szolgáltatás - madár 1.6.3
Router - Mikrotik hAP ac
Működő mappák – mivel rootként dolgozunk, a legtöbb minden a gyökér home mappájában lesz. Illetőleg:
- /root/blacklist – működő mappa a fordítási szkripttel
- /root/zi – a regisztrációs adatbázis másolata a githubból
- /etc/bird - szabványos mappa a madárszolgáltatás beállításaihoz
A VPS külső IP-címe az útválasztó szerverrel és az alagút végponttal 194.165.22.146, ASN 64998; az útválasztó külső IP-címe - 81.177.103.94, ASN 64999
Az alagútban lévő IP-címek 172.30.1.1 és 172.30.1.2.

Természetesen bármilyen más útválasztót, operációs rendszert és szoftverterméket használhat, logikájukhoz igazítva a megoldást.

Röviden - a megoldás logikája

Előkészítő intézkedések
1. VPS beszerzése
2. Alagút emelése az útválasztótól a VPS-ig
Megkapjuk és rendszeresen frissítjük a nyilvántartás másolatát
Az útválasztási szolgáltatás telepítése és konfigurálása
A rendszerleíró adatbázis alapján elkészítjük az útválasztási szolgáltatás statikus útvonalainak listáját
Csatlakoztatjuk az útválasztót a szolgáltatáshoz, és konfiguráljuk az összes forgalom az alagúton keresztül történő elküldését.

A tényleges megoldás

Előkészítő intézkedések

Az interneten számos szolgáltatás kínál VPS-t rendkívül kedvező áron. Eddig megtaláltam és használom is a 9 dollár/év opciót, de még ha nem is vesződsz túl sokat, sok lehetőség van 1E/hó áron minden sarkon. A VPS kiválasztásának kérdése messze túlmutat e cikk keretein, ezért ha valaki nem ért valamit ezzel kapcsolatban, kérdezze meg a megjegyzésekben.

Ha nem csak az útválasztási szolgáltatáshoz használ VPS-t, hanem egy alagút lezárására is, akkor fel kell emelnie ezt az alagutat, és szinte biztosan be kell állítania hozzá a NAT-ot. Az interneten számos utasítás található ezekről a műveletekről, itt nem ismétlem meg őket. Az ilyen alagúttal szemben támasztott fő követelmény az, hogy külön interfészt kell létrehoznia az útválasztón, amely támogatja az alagutat a VPS felé. A legtöbb használt VPN technológia megfelel ennek a követelménynek – például az OpenVPN tun módban tökéletes.

A rendszerleíró adatbázis másolatának beszerzése

Ahogy Jabrail mondta: „Aki akadályoz minket, az segít rajtunk.” Mivel az RKN létrehozza a tiltott források nyilvántartását, vétek lenne nem ezt a regisztert használni a problémánk megoldására. A rendszerleíró adatbázis másolatát megkapjuk a githubtól.

A Linux szerverére megyünk, a gyökér kontextusba esünk (sudo su -), és telepítse a git-et, ha még nincs telepítve.

apt install git

Lépjen a saját könyvtárába, és vegye ki a rendszerleíró adatbázis másolatát.

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

Beállítunk egy cron frissítést (én 20 percenként egyszer csinálom, de te választhatsz bármilyen intervallumot, ami érdekli). Ennek érdekében elindítjuk crontab -e és add hozzá a következő sort:

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

Csatlakoztatunk egy horgot, amely a beállításjegyzék frissítése után fájlokat hoz létre az útválasztási szolgáltatáshoz. Ehhez hozzon létre egy fájlt /root/zi/.git/hooks/post-merge a következő tartalommal:

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

és ne felejtsd el végrehajthatóvá tenni

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

Kicsit később elkészítjük a makebgp szkriptet, amelyre a hook hivatkozik.

Útválasztási szolgáltatás telepítése és konfigurálása

Telepítse madár. Sajnos az Ubuntu tárolókban jelenleg közzétett madár verziója frissességében az Archeopteryx ürülékéhez hasonlítható, ezért először a szoftverfejlesztők hivatalos PPA-ját kell hozzáadnunk a rendszerhez.

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

Ezek után azonnal letiltjuk a bird IPv6-ot – ebben a telepítésben nem lesz rá szükségünk.

systemctl stop bird6
systemctl disable bird6

Az alábbiakban egy minimalista madárszolgáltatás konfigurációs fájl található (/etc/bird/bird.conf), ami nekünk bőven elég (és még egyszer emlékeztetlek arra, hogy senki nem tiltja, hogy az ötletet a saját igényeid szerint alakítsd és hangold)

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

router id - router azonosító, amely vizuálisan úgy néz ki, mint egy IPv4-cím, de nem az. Esetünkben ez bármilyen 32 bites szám lehet IPv4 címformátumban, de jó forma pontosan feltüntetni a készüléked (jelen esetben VPS) IPv4 címét.

A közvetlen protokoll meghatározza, hogy mely interfészek működjenek együtt az útválasztási folyamattal. A példa néhány példanevet ad, hozzáadhat másokat is. Egyszerűen törölheti a sort, ebben az esetben a szerver az összes elérhető interfészt meghallgatja IPv4 címmel.

A static protokoll a mi varázslatunk, amely betölti az előtagok és IP-címek listáját (amelyek valójában /32-es előtagok, természetesen) a későbbi bejelentés céljából. Az alábbiakban arról lesz szó, hogy honnan származnak ezek a listák. Felhívjuk figyelmét, hogy az IP-címek betöltése alapértelmezés szerint ki van írva, ennek oka a nagy mennyiségű feltöltés. Összehasonlításképpen a cikk írásakor az előtagok listájában 78 sor található, az IP-címek listájában pedig 85898. Erősen javaslom, hogy csak az előtagok listáján indítsa el és végezze el a hibakeresést, és hogy engedélyezze-e az IP-betöltést. a jövőt Ön dönti el, miután kísérletezett a routerével. Nem mindenki tudja könnyen megemészteni az útválasztási táblázat 85 ezer bejegyzését.

A bgp protokoll valójában beállítja a bgp társviszony-létesítést az útválasztóval. Az IP-cím az útválasztó külső interfészének címe (vagy a router oldalán lévő alagút-interfész címe), a 64998 és 64999 az autonóm rendszerek számai. Ebben az esetben tetszőleges 16 bites számok formájában hozzárendelhetők, de jó gyakorlat az RFC6996 - 64512-65534 által meghatározott privát tartományból származó AS számok használata (a 32 bites ASN-ekhez van formátum, de esetünkben ez határozottan túlzás). A leírt konfiguráció eBGP peering-t használ, amelyben az útválasztási szolgáltatás és a router autonóm rendszereinek számának különböznie kell.

Mint látható, a szolgáltatásnak ismernie kell az útválasztó IP-címét, így ha dinamikus vagy nem irányítható privát (RFC1918) vagy megosztott (RFC6598) címe van, akkor nincs lehetősége a társviszony-létesítésre a külső felületen. felületen, de a szolgáltatás továbbra is az alagútban fog működni.

Az is teljesen világos, hogy egy szolgáltatásból több különböző útválasztóhoz is biztosíthat útvonalakat - csak duplikálja meg a beállításokat a protokoll bgp szakaszának másolásával és a szomszéd IP-címének megváltoztatásával. Ezért a példa az alagúton kívüli társítás beállításait mutatja a leguniverzálisabbnak. Könnyű eltávolítani őket az alagútba az IP-címek megfelelő módosításával a beállításokban.

A beállításjegyzék feldolgozása az útválasztási szolgáltatáshoz

Most valójában listákat kell létrehoznunk az előtagokból és az IP-címekből, amelyeket az előző szakaszban a statikus protokollban említettek. Ehhez vesszük a registry fájlt, és a következő szkript segítségével elkészítjük belőle a számunkra szükséges fájlokat /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'

Ne felejtse el végrehajthatóvá tenni

chmod +x /root/blacklist/makebgp

Most már manuálisan is futtathatja, és megfigyelheti a fájlok megjelenését az /etc/bird könyvtárban.

Valószínűleg a madár jelenleg nem működik az Ön számára, mert az előző szakaszban arra kérte, hogy keressen olyan fájlokat, amelyek még nem léteztek. Ezért elindítjuk, és ellenőrizzük, hogy elindult-e:

systemctl start bird
birdc show route

A második parancs kimenetének körülbelül 80 rekordot kell mutatnia (egyelőre ez, de amikor beállítja, minden az RKN buzgalmától függ a hálózatok blokkolásakor) valami ilyesmi:

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

Csapat

birdc show protocol

megmutatja a szolgáltatáson belüli protokollok állapotát. Amíg nem konfiguráltad a routert (lásd a következő pontot), az OurRouter protokoll induló állapotban lesz (Connect vagy Active fázis), majd a sikeres csatlakozás után felfelé (Established phase) megy. Például az én rendszeremen ennek a parancsnak a kimenete így néz ki:

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

Router csatlakoztatása

Valószínűleg mindenki belefáradt ennek a lábtörlőnek az olvasásához, de nyugodj meg – közel a vég. Sőt, ebben a részben nem fogok tudni lépésről lépésre utasításokat adni - ez minden gyártónál eltérő lesz.

Néhány példát azonban mutathatok. A fő logika az, hogy fel kell emelni a BGP társviszony-létesítést, és az összes fogadott előtaghoz hozzá kell rendelni a nexthop-ot, amely az alagútunkra mutat (ha a forgalmat p2p interfészen keresztül kell továbbítanunk), vagy a nexthop IP-címére, ha a forgalom az ethernetre megy.

Például a RouterOS Mikrotikon ez a következőképpen oldható meg

/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

és Cisco IOS-ben – így

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

Ha ugyanazt az alagutat használják a BGP társviszony-létesítésre és a hasznos forgalom továbbítására is, akkor nem szükséges a nexthop beállítása, a protokoll megfelelően lesz beállítva. De ha manuálisan állítod be, attól sem lesz rosszabb.

Más platformokon magának kell kitalálnia a konfigurációt, de ha nehézségei vannak, írja meg a megjegyzésekben, megpróbálok segíteni.

Miután a BGP-munkamenet elkezdődött, a nagy hálózatokhoz vezető útvonalak megérkeztek és telepítve vannak a táblázatban, a forgalom a címekre áramlott róluk, és a boldogság közel van, visszatérhet a madárszolgálathoz, és megpróbálhatja törölni a bejegyzést, amely összeköti a IP-címek listája, ezt követően hajtsa végre

systemctl reload bird

és nézze meg, hogyan vitte át a routere ezt a 85 ezer útvonalat. Készülj fel, hogy kihúzd a konnektorból, és gondold át, mit kezdj vele :)

Összességében

Pusztán elméletileg a fent leírt lépések elvégzése után most már rendelkezik egy szolgáltatással, amely automatikusan átirányítja a forgalmat az Orosz Föderációban tiltott IP-címekre a szűrőrendszeren túl.

Természetesen lehet javítani. Például elég könnyű összefoglalni az IP-címek listáját perl vagy python megoldások segítségével. Egy egyszerű Perl-szkript ezt a Net::CIDR::Lite használatával 85 ezer előtagot 60-ra (nem ezerre) változtat, de természetesen sokkal nagyobb címtartományt fed le, mint a blokkolva.

Mivel a szolgáltatás az ISO/OSI modell harmadik szintjén működik, nem menti meg Önt egy webhely/oldal blokkolása alól, ha a rendszerleíró adatbázisban rögzített rossz címre oldja fel. Ám a registry-vel együtt a githubból érkezik az nxdomain.txt fájl is, amely néhány szkriptvonással könnyen címforrássá válik például a Chrome SwitchyOmega pluginjához.

Azt is szükséges megemlíteni, hogy a megoldás további finomítást igényel, ha Ön nem csak internet-felhasználó, hanem saját maga is közzétesz bizonyos forrásokat (például ezen a kapcsolaton fut egy weboldal vagy levelezőszerver). Az útválasztó eszközeivel szigorúan le kell kötni a szolgáltatásból kimenő forgalmat a nyilvános címéhez, ellenkező esetben elveszíti a kapcsolatot azokkal az erőforrásokkal, amelyeket az útválasztó által kapott előtagok listája lefed.

Ha kérdésed van, tedd fel, készséggel válaszolok.

UPD. Köszönöm navigáció и TerAnYu a git paramétereihez, amelyek lehetővé teszik a letöltési mennyiség csökkentését.

UPD2. Kollégák, úgy tűnik, hibát követtem el, amikor nem adtam meg a cikkhez a VPS és az útválasztó közötti alagút létrehozására vonatkozó utasításokat. Ez sok kérdést felvet.
Minden esetre még egyszer megjegyzem, hogy az útmutató elindítása előtt már konfigurált egy VPN-alagutat a kívánt irányba, és ellenőrizte a működését (például úgy, hogy alapértelmezés szerint vagy statikusan irányítja oda a forgalmat). Ha még nem fejezte be ezt a fázist, nincs sok értelme követni a cikkben szereplő lépéseket. Erről még nincs saját szövegem, de ha a google-ban az „OpenVPN szerver beállítása” a VPS-re telepített operációs rendszer nevével együtt, az „OpenVPN kliens beállítása” pedig a routered nevével , valószínűleg számos cikket talál ebben a témában , többek között a Habréról is.

UPD3. Feláldozatlan Írtam egy kódot, amely a dump.csv fájlt egy eredő fájllá alakítja a madár számára az IP-címek opcionális összegzésével. Ezért a „Rendszerleíró adatbázis feldolgozása az útválasztási szolgáltatáshoz” szakasz lecserélhető a program meghívásával. https://habr.com/post/354282/#comment_10782712

UPD4. Egy kis munka a hibákon (nem tettem hozzá a szöveghez):
1) helyette systemctl reload madár a parancs használatának van értelme birdc konfigurálása.
2) a Mikrotik útválasztóban, ahelyett, hogy a nexthop-ot az alagút második oldalának IP-jére változtatná /routing filter add action=accept chain=dynamic-in protocol=bgp comment=»Nexthop beállítása» set-in-nexthop=172.30.1.1 célszerű közvetlenül az alagút interfészhez vezető útvonalat megadni, cím nélkül /routing filter add action=accept chain=dynamic-in protocol=bgp comment=»Nexthop beállítása» set-in-nexthop-direct=<interfész neve>

UPD5. Új szolgáltatás jelent meg https://antifilter.download, ahonnan felveheti az IP-címek kész listáit. Félóránként frissül. A kliens oldalon nem marad más hátra, mint bekeretezni a rekordokat a megfelelő „útvonal... elutasítással”.
És ezen a ponton valószínűleg elég, ha lerongyolják a nagymamát, és frissítik a cikket.

UPD6. A cikk átdolgozott változata azoknak, akik nem akarnak rájönni, de el akarják kezdeni - itt.

Forrás: will.com

A BGP beállítása a blokkolás megkerülésére, vagy „Hogyan hagytam abba a félelmet és szerettem bele az RKN-be”