Konfigurowanie BGP w celu ominięcia blokowania lub „Jak przestałem się bać i zakochałem w RKN”

No cóż, określenie „kochać” to przesada. Raczej „był w stanie współistnieć”.

Jak wszyscy wiecie, od 16 kwietnia 2018 r. Roskomnadzor blokuje dostęp do zasobów w Internecie w niezwykle szerokim zakresie, dodając do „Ujednoliconego rejestru nazw domen, indeksów stron witryn w Internecie i adresów sieciowych umożliwiających identyfikację witryn w Internecie”, zawierający informacje, których rozpowszechnianie jest zabronione w Federacji Rosyjskiej” (w tekście - tylko rejestr) czasami przez /10. W rezultacie cierpią obywatele Federacji Rosyjskiej i przedsiębiorstwa, które utraciły dostęp do całkowicie legalnych zasobów, których potrzebują.

Po tym, jak w komentarzach do jednego z artykułów na temat Habré powiedziałam, że jestem gotowa pomóc ofiarom w przygotowaniu schematu bajpasów, zwróciło się do mnie kilka osób z prośbą o taką pomoc. Kiedy wszystko zadziałało, jeden z nich zalecił opisanie techniki w artykule. Po chwili namysłu postanowiłem przerwać milczenie na stronie i choć raz spróbować napisać coś pośredniego pomiędzy projektem a postem na Facebooku, czyli np. habrapost. Wynik jest przed tobą.

Odpowiedzialność

Ponieważ publikowanie sposobów ominięcia blokowania dostępu do informacji zabronionych na terytorium Federacji Rosyjskiej jest mało legalne, celem tego artykułu będzie omówienie metody, która pozwala zautomatyzować uzyskiwanie dostępu do zasobów dozwolonych na terytorium Federacji Rosyjskiej. terytorium Federacji Rosyjskiej, ale z powodu cudzych działań nie są bezpośrednio dostępne za pośrednictwem Twojego dostawcy. A dostęp do innych zasobów uzyskanych w wyniku działań z artykułu jest niefortunnym skutkiem ubocznym i w żaden sposób nie jest celem artykułu.

Ponadto, ponieważ z zawodu, zawodu i ścieżki życiowej jestem przede wszystkim architektem sieci, programowanie i Linux nie są moją mocną stroną. Dlatego oczywiście można pisać lepiej skrypty, głębiej pracować nad kwestiami bezpieczeństwa w VPS itp. Twoje sugestie zostaną przyjęte z wdzięcznością, jeśli będą wystarczająco szczegółowe - chętnie dodam je do tekstu artykułu.

TL; DR

Automatyzujemy dostęp do zasobów poprzez Twój istniejący tunel wykorzystując kopię rejestru i protokół BGP. Celem jest usunięcie całego ruchu kierowanego do zablokowanych zasobów do tunelu. Minimum wyjaśnień, głównie instrukcje krok po kroku.

Czego potrzebujesz do tego?

Niestety, ten post nie jest dla każdego. Aby zastosować tę technikę, będziesz musiał połączyć kilka elementów:

1. Musisz mieć serwer Linux gdzieś poza polem blokującym. Albo przynajmniej chęć posiadania takiego serwera - na szczęście kosztuje on teraz od 9 dolarów rocznie, a być może i mniej. Metoda jest również odpowiednia, jeśli masz oddzielny tunel VPN, wtedy serwer może znajdować się wewnątrz pola blokującego.
2. Twój router powinien być na tyle inteligentny, aby móc to zrobić
   • dowolny klient VPN, który lubisz (preferuję OpenVPN, ale może to być PPTP, L2TP, GRE+IPSec lub dowolna inna opcja tworząca interfejs tunelowy);
   • Protokół BGPv4. Oznacza to, że w przypadku SOHO może to być Mikrotik lub dowolny router z OpenWRT/LEDE/podobnym, niestandardowym oprogramowaniem, które pozwala na instalację Quagga lub Bird. Korzystanie z routera komputerowego również nie jest zabronione. W przypadku przedsiębiorstwa poszukaj wsparcia BGP w dokumentacji routera granicznego.
3. Powinieneś znać wykorzystanie Linuksa i technologie sieciowe, w tym protokół BGP. A przynajmniej chcesz wpaść na taki pomysł. Ponieważ tym razem nie jestem gotowy, aby ogarnąć ogrom, będziesz musiał sam przestudiować pewne aspekty, które są dla ciebie niezrozumiałe. Oczywiście odpowiem jednak na konkretne pytania w komentarzach i prawdopodobnie nie będę jedyną osobą, która odpowie, więc nie wahaj się zapytać.

Co zostało użyte w przykładzie

• Odpis z rejestru – z https://github.com/zapret-info/z-i 
• VPS-Ubuntu 16.04
• Usługa wyznaczania tras — ptak 1.6.3   
• Routera - Mikrotik hAP ac
• Foldery robocze - ponieważ pracujemy jako root, większość wszystkiego będzie znajdować się w folderze domowym roota. Odpowiednio:
  • /root/blacklist - folder roboczy ze skryptem kompilacji
  • /root/zi – kopia rejestru z githuba
  • /etc/bird - standardowy folder ustawień usług ptaków
• Zewnętrzny adres IP VPS z serwerem routingu i punktem końcowym tunelu to 194.165.22.146, ASN 64998; zewnętrzny adres IP routera - 81.177.103.94, ASN 64999
• Adresy IP wewnątrz tunelu to odpowiednio 172.30.1.1 i 172.30.1.2.

Można oczywiście zastosować dowolne inne routery, systemy operacyjne i oprogramowanie, dopasowując rozwiązanie do ich logiki.

W skrócie – logika rozwiązania

1. Działania przygotowawcze
   1. Kupno VPS-a
   2. Podniesienie tunelu od routera do VPS
2. Otrzymujemy i regularnie aktualizujemy kopię rejestru
3. Instalacja i konfiguracja usługi routingu
4. Na podstawie rejestru tworzymy listę tras statycznych dla usługi routingu
5. Podłączamy router do usługi i konfigurujemy przesyłanie całego ruchu przez tunel.

Rzeczywiste rozwiązanie

Działania przygotowawcze

W Internecie istnieje wiele usług, które zapewniają VPS za wyjątkowo rozsądne ceny. Jak dotąd znalazłem i korzystam z opcji za 9 USD/rok, ale nawet jeśli nie przejmujesz się zbytnio, istnieje wiele opcji za 1E/miesiąc na każdym rogu. Kwestia wyboru VPS wykracza daleko poza zakres tego artykułu, więc jeśli ktoś czegoś nie rozumie, zapytaj w komentarzach.

Jeśli używasz VPS nie tylko do usługi routingu, ale także do zakończenia w nim tunelu, musisz podnieść ten tunel i prawie na pewno skonfigurować dla niego NAT. W Internecie istnieje wiele instrukcji dotyczących tych działań, nie będę ich tutaj powtarzać. Głównym wymaganiem dla takiego tunelu jest to, że musi on tworzyć na routerze oddzielny interfejs obsługujący tunel w kierunku VPS. Najczęściej stosowane technologie VPN spełniają ten wymóg – na przykład OpenVPN w trybie tun sprawdza się idealnie.

Uzyskanie kopii rejestru

Jak powiedział Jabrail: „Kto nam przeszkadza, ten nam pomoże”. Ponieważ RKN tworzy rejestr zasobów zabronionych, grzechem byłoby nie wykorzystać tego rejestru do rozwiązania naszego problemu. Otrzymamy kopię rejestru z githuba.

Wchodzimy na Twój serwer Linux, wchodzimy w kontekst główny (sudo su —) i zainstaluj git, jeśli nie jest jeszcze zainstalowany.

apt install git

Przejdź do katalogu domowego i wyciągnij kopię rejestru.

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

Ustawiamy aktualizację cron (robię to raz na 20 minut, ale możesz wybrać dowolny interwał, który Cię interesuje). W tym celu uruchamiamy crontab -e i dodaj do niego następujący wiersz:

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

Podłączamy hook, który po aktualizacji rejestru utworzy pliki dla usługi routingu. Aby to zrobić, utwórz plik /root/zi/.git/hooks/post-merge o następującej treści:

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

i nie zapomnij uczynić go wykonywalnym

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

Nieco później utworzymy skrypt makebgp, do którego odwołuje się hak.

Instalacja i konfiguracja usługi routingu

Zainstaluj ptaka. Niestety, wersja ptaka obecnie zamieszczona w repozytoriach Ubuntu jest porównywalna pod względem świeżości z odchodami Archaeopteryx, dlatego musimy najpierw dodać do systemu oficjalne PPA twórców oprogramowania.

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

Następnie natychmiast wyłączamy ptaka dla IPv6 - nie będziemy go potrzebować w tej instalacji.

systemctl stop bird6
systemctl disable bird6

Poniżej znajduje się minimalistyczny plik konfiguracyjny usługi Bird (/etc/bird/bird.conf), co nam w zupełności wystarczy (i jeszcze raz przypominam, że nikt nie zabrania rozwijania i dostosowywania pomysłu do własnych potrzeb)

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 routera - identyfikator routera, który wizualnie wygląda jak adres IPv4, ale nim nie jest. W naszym przypadku może to być dowolna liczba 32-bitowa w formacie adresu IPv4, jednak dobrze jest podać dokładnie adres IPv4 swojego urządzenia (w tym przypadku VPS).

protokół bezpośrednio określa, które interfejsy będą współpracować z procesem routingu. Przykład podaje kilka przykładowych nazw, możesz dodać inne. Możesz po prostu usunąć linię; w tym przypadku serwer będzie nasłuchiwał wszystkich dostępnych interfejsów z adresem IPv4.

protokół static to nasza magia, która ładuje listy prefiksów i adresów IP (które w rzeczywistości są prefiksami /32, oczywiście) z plików w celu późniejszego ogłoszenia. Skąd pochodzą te listy, zostanie omówione poniżej. Należy pamiętać, że ładowanie adresów IP jest domyślnie komentowane, powodem jest duża liczba przesyłanych plików. Dla porównania w chwili pisania tego tekstu na liście prefiksów znajduje się 78 linii, a na liście adresów IP 85898. Gorąco polecam uruchamianie i debugowanie tylko na liście prefiksów oraz to, czy włączyć ładowanie IP w przyszłość zależy od Ciebie, po przeprowadzeniu eksperymentów z routerem. Nie każdy z nich jest w stanie łatwo przetrawić 85 tysięcy wpisów w tablicy routingu.

protokół bgp w rzeczywistości konfiguruje połączenie bgp z routerem. Adres IP to adres zewnętrznego interfejsu routera (lub adres interfejsu tunelu po stronie routera), 64998 i 64999 to numery systemów autonomicznych. Można je w tym przypadku przypisać w postaci dowolnych liczb 16-bitowych, jednak dobrą praktyką jest stosowanie numerów AS z zakresu prywatnego określonego w RFC6996 - 64512-65534 włącznie (istnieje format dla 32-bitowych ASN-ów, ale w naszym przypadku to zdecydowanie przesada). Opisana konfiguracja wykorzystuje eBGP peering, w którym numery systemów autonomicznych usługi routingu i routera muszą być różne.

Jak widać, usługa musi znać adres IP routera, więc jeśli masz dynamiczny lub nierutowalny adres prywatny (RFC1918) lub współdzielony (RFC6598), nie masz możliwości podniesienia peeringu na zewnętrznym interfejs, ale usługa będzie nadal działać wewnątrz tunelu.

Jest również całkiem jasne, że z jednej usługi możesz zapewnić trasy do kilku różnych routerów - po prostu zduplikuj dla nich ustawienia, kopiując sekcję protokołu bgp i zmieniając adres IP sąsiada. Dlatego przykład pokazuje ustawienia peeringu poza tunelem, jako najbardziej uniwersalne. Łatwo je usunąć do tunelu, zmieniając odpowiednio adresy IP w ustawieniach.

Przetwarzanie rejestru dla usługi routingu

Teraz tak naprawdę musimy stworzyć listy prefiksów i adresów IP, które zostały wymienione w protokole statycznym na poprzednim etapie. W tym celu pobieramy plik rejestru i tworzymy z niego potrzebne pliki za pomocą następującego skryptu umieszczonego w /root/czarna lista/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'

Nie zapomnij uczynić go wykonywalnym

chmod +x /root/blacklist/makebgp

Teraz możesz uruchomić go ręcznie i obserwować wygląd plików w /etc/bird.

Najprawdopodobniej ptak w tej chwili dla Ciebie nie działa, ponieważ na poprzednim etapie poprosiłeś go o wyszukanie plików, które jeszcze nie istnieją. Dlatego uruchamiamy go i sprawdzamy, czy się uruchomił:

systemctl start bird
birdc show route

Wynik drugiego polecenia powinien pokazać około 80 rekordów (to na razie, ale kiedy to skonfigurujesz, wszystko będzie zależeć od gorliwości RKN w blokowaniu sieci) coś takiego:

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

Zespół

birdc show protocol

pokaże status protokołów w ramach usługi. Dopóki nie skonfigurujesz routera (patrz kolejny punkt), protokół OurRouter będzie w stanie startowym (faza Connect lub Active), a po udanym połączeniu przejdzie do stanu up (faza Established). Na przykład w moim systemie wynik tego polecenia wygląda następująco:

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

Podłączanie routera

Pewnie każdemu znudziło się czytanie tego obrusu, ale opamiętajcie się – koniec jest bliski. Co więcej, w tej sekcji nie będę w stanie podać instrukcji krok po kroku - będzie ona inna dla każdego producenta.

Mogę jednak pokazać kilka przykładów. Główną logiką jest podniesienie peeringu BGP i przypisanie następnego skoku do wszystkich otrzymanych prefiksów, wskazując na nasz tunel (jeśli musimy wysyłać ruch przez interfejs p2p) lub adres IP następnego skoku, jeśli ruch będzie kierowany do sieci Ethernet.

Na przykład na Mikrotiku w RouterOS rozwiązano to w następujący sposób

/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

a w Cisco IOS - tak

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

Jeśli ten sam tunel jest używany zarówno do peeringu BGP, jak i do przesyłania użytecznego ruchu, nie jest konieczne ustawianie następnego skoku; zostanie on ustawiony poprawnie przy użyciu protokołu. Ale jeśli ustawisz to ręcznie, nie pogorszy to również sytuacji.

Na innych platformach będziesz musiał sam wymyślić konfigurację, ale jeśli będziesz mieć jakieś trudności, napisz w komentarzach, postaram się pomóc.

Po rozpoczęciu Twojej sesji BGP przyszły i zostały zainstalowane w tabeli trasy do dużych sieci, ruch popłynął z nich na adresy i szczęście jest już blisko, możesz wrócić do serwisu ptaków i spróbować odkomentować znajdujący się tam wpis łączący listę adresów IP, wykonaj następnie

systemctl reload bird

i zobacz jak Twój router przesłał te 85 tys. tras. Przygotuj się do odłączenia i zastanów się, co z tym zrobić :)

Razem

Czysto teoretycznie, po wykonaniu opisanych powyżej kroków, masz teraz usługę, która automatycznie przekierowuje ruch na adresy IP zakazane w Federacji Rosyjskiej po przekroczeniu systemu filtrowania.

Można to oczywiście poprawić. Na przykład dość łatwo jest podsumować listę adresów IP za pomocą rozwiązań Perl lub Python. Prosty skrypt Perla wykonujący to za pomocą Net::CIDR::Lite zamienia 85 tysięcy prefiksów na 60 (nie tysiące), ale oczywiście obejmuje znacznie większy zakres adresów niż jest blokowany.

Ponieważ usługa działa na trzecim poziomie modelu ISO/OSI, nie uchroni Cię przed zablokowaniem witryny/strony, jeśli zostanie ona znaleziona pod błędnym adresem zarejestrowanym w rejestrze. Ale wraz z rejestrem z githuba przychodzi plik nxdomain.txt, który kilkoma kreskami skryptu łatwo zamienia się w źródło adresów np. wtyczki SwitchyOmega w Chrome.

Trzeba też wspomnieć, że rozwiązanie wymaga dodatkowego dopracowania, jeśli nie jesteś tylko użytkownikiem Internetu, ale także samodzielnie publikujesz pewne zasoby (na tym łączu działa np. strona internetowa lub serwer pocztowy). Korzystając ze środków routera, konieczne jest ścisłe powiązanie ruchu wychodzącego z tej usługi z Twoim adresem publicznym, w przeciwnym razie utracisz łączność z zasobami objętymi listą prefiksów otrzymanych przez router.

Jeśli masz jakieś pytania, pytaj, jestem gotowy odpowiedzieć.

UPD. Dziękuję nawigacja и TerAnYu dla parametrów git, które pozwalają zmniejszyć liczbę pobieranych plików.

UPD2. Koledzy, wygląda na to, że popełniłem błąd nie dodając do artykułu instrukcji dotyczącej założenia tunelu pomiędzy VPS-em a routerem. Rodzi się w związku z tym wiele pytań.
Na wszelki wypadek jeszcze raz zaznaczę, że przed rozpoczęciem tego poradnika skonfigurowałeś już tunel VPN w pożądanym kierunku i sprawdziłeś jego funkcjonalność (np. przekierowując tam ruch domyślnie lub statycznie). Jeśli nie ukończyłeś jeszcze tej fazy, wykonywanie kroków opisanych w artykule nie ma większego sensu. Nie mam jeszcze własnego tekstu na ten temat, ale jeśli wpiszesz w Google „konfigurowanie serwera OpenVPN” wraz z nazwą systemu operacyjnego zainstalowanego na VPS i „konfigurowanie klienta OpenVPN” z nazwą twojego routera , najprawdopodobniej znajdziesz wiele artykułów na ten temat, w tym na temat Habré.

UPD3. Niepoświęcony Napisałem kod, który zamienia plik dump.csv w plik wynikowy dla ptaka z opcjonalnym podsumowaniem adresów IP. Dlatego sekcję „Przetwarzanie rejestru dla usługi routingu” można zastąpić, wywołując jej program. https://habr.com/post/354282/#comment_10782712

UPD4. Trochę pracy nad błędami (nie dodałem ich do tekstu):
1) zamiast tego systemctl przeładuj ptaka użycie polecenia ma sens konfiguracja ptaka.
2) w routerze Mikrotik, zamiast zmieniać następny skok na adres IP drugiej strony tunelu /routing filter dodaj akcję=zaakceptuj łańcuch=protokół dynamiczny=bgp komentarz=»Ustaw następny skok» set-in-nexthop=172.30.1.1 sensowne jest określenie trasy bezpośrednio do interfejsu tunelu, bez adresu /routing filter add action=zaakceptuj łańcuch=protokół dynamiczny=bgp komentarz=»Ustaw następny skok» set-in-nexthop-direct=<nazwa interfejsu>

UPD5. Pojawiła się nowa usługa https://antifilter.download, skąd możesz pobrać gotowe listy adresów IP. Aktualizowane co pół godziny. Po stronie klienta pozostaje jedynie oprawić rekordy w odpowiednią „trasę… odrzucić”.
I w tym momencie prawdopodobnie wystarczy poszarpać babcię i zaktualizować artykuł.

UPD6. Poprawiona wersja artykułu dla tych, którzy nie chcą tego rozgryźć, ale chcą zacząć - tutaj.

Źródło: www.habr.com