🥇Configurar BGP para evitar o bloqueo ou "Como deixei de ter medo e me namorei de RKN"

Ben, vale, sobre "namorouse" é unha esaxeración. Máis ben "podería convivir con".

Como todos sabedes, desde o 16 de abril de 2018, Roskomnadzor bloquea o acceso aos recursos da rede con trazos extremadamente amplos, engadindo ao Rexistro Unificado de nomes de dominio, punteiros a páxinas de sitios en Internet e enderezos de rede que che permiten identificar sitios en Internet que conteñan información, cuxa difusión está prohibida na Federación Rusa" (no texto - só un rexistro) /10 ás veces. Como resultado, os cidadáns da Federación Rusa e as empresas sofren, ao perder o acceso aos recursos completamente legais que necesitan.

Despois de que dixese nos comentarios dun dos artigos sobre Habré que estaba preparado para axudar ás vítimas a montar un esquema de derivación, varias persoas contactaron comigo para pedir esa axuda. Cando todo lles funcionou, un deles recomendou describir a técnica nun artigo. Reflexionando, decidín romper o meu silencio no sitio e tentar por unha vez escribir algo intermedio entre un proxecto e unha publicación en Facebook, é dicir. habrapost. O resultado está diante de ti.

retratação

Dado que non é moi legal publicar formas de evitar o bloqueo de acceso a información prohibida no territorio da Federación Rusa, o propósito deste artigo será falar dun método que che permita automatizar o acceso aos recursos que están permitidos na Federación Rusa. territorio da Federación Rusa, pero debido ás accións doutra persoa non se pode acceder directamente a través do teu provedor. E o acceso a outros recursos obtidos como resultado das accións do artigo é un desafortunado efecto secundario e de ningún xeito é o propósito do artigo.

Ademais, dado que son principalmente arquitecto de redes de profesión, vocación e camiño de vida, a programación e Linux non son os meus puntos fortes. Polo tanto, por suposto, os guións pódense escribir mellor, os problemas de seguridade en VPS pódense resolver máis profundamente, etc. As túas suxestións serán aceptadas con gratitude, se son o suficientemente detalladas; estarei encantada de engadilas ao texto do artigo.

TL, RD

Automatizamos o acceso aos recursos a través do teu túnel existente mediante unha copia do rexistro e do protocolo BGP. O obxectivo é eliminar todo o tráfico dirixido a recursos bloqueados no túnel. Explicación mínima, principalmente instrucións paso a paso.

Que necesitas para iso

Desafortunadamente, esta publicación non é para todos. Para usar esta técnica, terás que xuntar algúns elementos:

Debes ter un servidor Linux nalgún lugar fóra do campo de bloqueo. Ou polo menos o desexo de iniciar un servidor deste tipo, xa que agora custa a partir de $ 9 / ano, e posiblemente menos. O método tamén é axeitado se tes un túnel VPN separado, entón o servidor pódese localizar dentro do campo de bloqueo.
O teu enrutador debe ser o suficientemente intelixente como para poder facelo
- calquera cliente VPN que che guste (prefiro OpenVPN, pero pode ser PPTP, L2TP, GRE+IPSec e calquera outra opción que cree unha interface de túnel);
- Protocolo BGPv4. O que significa que para SOHO podería ser Mikrotik ou calquera router con OpenWRT/LEDE/firmware personalizado similar que che permita instalar Quagga ou Bird. Tampouco está prohibido usar un enrutador de PC. No caso dunha empresa, busque soporte BGP na documentación do seu enrutador de fronteira.
Debería estar familiarizado co uso de Linux e as tecnoloxías de rede, incluíndo BGP. Ou polo menos quere ter esa idea. Como non estou preparado para abrazar a inmensidade desta vez, terás que estudar por ti mesmo algúns puntos que che resultan incomprensibles. Non obstante, por suposto, responderei preguntas específicas nos comentarios e é pouco probable que sexa o único que responda, así que non dubide en preguntar.

O que se usa no exemplo

Copia do rexistro https://github.com/zapret-info/z-i
VPS - Ubuntu 16.04
Servizo de enrutamento - paxaro 1.6.3
enrutador - Mikrotik hAP ac
Cartafoles de traballo: xa que estamos a traballar como root, a maior parte de todo colocarase no cartafol de inicio raíz. Respectivamente:
- /root/blacklist - cartafol de traballo con script de compilación
- /root/zi - unha copia do rexistro de github
- /etc/bird - cartafol de configuración estándar do servizo de aves
Aceptamos 194.165.22.146, ASN 64998 como enderezo IP externo do VPS co servidor de enrutamento e o punto de terminación do túnel; enderezo IP externo do enrutador - 81.177.103.94, ASN 64999
Os enderezos IP dentro do túnel son 172.30.1.1 e 172.30.1.2, respectivamente.

Por suposto, pode usar calquera outro enrutador, sistema operativo e produto de software, axustando a solución para que se axuste á súa lóxica.

Brevemente - a lóxica da solución

Accións preparatorias
1. Conseguindo un VPS
2. Levantamos o túnel desde o router ata o VPS
Recibimos e actualizamos regularmente unha copia do rexistro
Instalación e configuración do servizo de enrutamento
Cree unha lista de rutas estáticas para o servizo de enrutamento en función do rexistro
Conectamos o router ao servizo e configuramos o envío de todo o tráfico polo túnel.

A decisión real

Accións preparatorias

Na inmensidade da rede hai moitos servizos que ofrecen VPS por un diñeiro moi razoable. Ata agora, atopei e usei a opción por 9 dólares ao ano, pero aínda que non che molestes, hai moitas opcións por 1 E/mes en cada esquina. A cuestión de escoller un VPS está moito máis aló do alcance deste artigo, polo que se algo non está claro para alguén sobre isto, pregúntalle nos comentarios.

Se usa VPS non só para o servizo de enrutamento, senón tamén para finalizar un túnel nel, cómpre elevar este túnel e, case inequívocamente, configurar NAT para iso. Hai un gran número de instrucións na rede para estas accións, non as repetirei aquí. O principal requisito para tal túnel é que debe crear unha interface separada no seu enrutador que admita o túnel cara ao VPS. A maioría das tecnoloxías VPN usadas cumpren este requisito; por exemplo, OpenVPN no modo tun está ben.

Obter unha copia do rexistro

Como dixo Jabrayil: "Quen nos estorba axudaranos". Dado que o RKN está a crear un rexistro de recursos prohibidos, sería un pecado non utilizar este rexistro para resolver o noso problema. Recibiremos unha copia do rexistro de github.

Imos ao teu servidor Linux, entramos no contexto de root'a (sudo su-) e instala git se aínda non está instalado.

apt install git

Vaia ao seu directorio de inicio e saque unha copia do rexistro.

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

Configura unha actualización cron (téñoa cada 20 minutos, pero podes escoller calquera intervalo que che interese). Para iso, corremos crontab -e e engádelle a seguinte liña:

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

Conectamos un gancho que creará ficheiros para o servizo de enrutamento despois de actualizar o rexistro. Para iso, creamos un ficheiro /root/zi/.git/hooks/post-merge co seguinte contido:

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

e non esquezas facelo executable

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

O script makebgp ao que fai referencia o gancho crearase máis tarde.

Instalación e configuración do servizo de enrutamento

Instalar paxaro. Desafortunadamente, a versión de bird lanzada actualmente nos repositorios de Ubuntu é comparable en frescura ás feces de Archaeopteryx, polo que primeiro necesitamos engadir ao sistema o PPA oficial dos desenvolvedores de software.

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

Despois diso, desactivamos inmediatamente Bird para IPv6; non o necesitaremos nesta instalación.

systemctl stop bird6
systemctl disable bird6

A continuación móstrase un ficheiro de configuración minimalista para o servizo de aves (/etc/bird/bird.conf), o que abonda para nós (e unha vez máis lémbrovos que ninguén prohibe desenvolver e afinar a idea para que se adapte ás vosas necesidades)

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 do enrutador: identificador do enrutador, visualmente semella un enderezo IPv4, pero non o é. No noso caso, pode ser calquera número de 32 bits no formato de enderezo IPv4, pero é unha boa práctica especificar alí o enderezo IPv4 do teu dispositivo (neste caso, VPS).

protocol direct determina que interfaces funcionarán co proceso de enrutamento. O exemplo dá un par de exemplos de nomes, podes engadir máis. Tamén pode simplemente eliminar a liña, nese caso o servidor escoitará en todas as interfaces dispoñibles cun enderezo IPv4.

O protocolo estático é a nosa maxia que carga listas de prefixos e enderezos IP (que son, por suposto, prefixos /32) dos ficheiros para o seu anuncio posterior. De onde proceden estas listas comentarase a continuación. Teña en conta que a carga de enderezos IP está comentada por defecto, o motivo é a gran cantidade de carga. A modo de comparación, no momento de escribir o artigo, hai 78 liñas na lista de prefixos e 85898 na lista de enderezos IP. Recomendo encarecidamente que inicie e depure só na lista de prefixos e decida se ou non. para activar a carga IP no futuro despois de probar co seu enrutador. Non todos poden dixerir facilmente 85 mil entradas na táboa de enrutamento.

protocol bgp realmente configura o peering bgp co teu enrutador. IP-address é o enderezo da interface externa do enrutador (ou o enderezo da interface do túnel desde o lado do enrutador), 64998 e 64999 son os números de sistemas autónomos. Neste caso, pódense asignar en forma de calquera número de 16 bits, pero é unha boa práctica usar números AS do rango privado definido por RFC6996 - 64512-65534 inclusive (hai un formato ASN de 32 bits, pero no noso caso definitivamente é excesivo). A configuración descrita utiliza eBGP peering, no que os números de sistema autónomo do servizo de enrutamento e do router deben ser diferentes.

Como podes ver, o servizo necesita coñecer o enderezo IP do enrutador, polo que se tes un enderezo privado (RFC1918) ou compartido (RFC6598) dinámico ou non enrutable, non tes opción de aumentar o peering na interface externa, pero o servizo seguirá funcionando dentro do túnel.

Tamén é bastante transparente que pode fornecer varios enrutadores diferentes con rutas dun servizo; só duplique a configuración para eles copiando a sección bgp do protocolo cambiando o enderezo IP do veciño. É por iso que o exemplo mostra as opcións de peering fóra do túnel, como as máis universais. Non é difícil eliminalos no túnel cambiando os enderezos IP na configuración en consecuencia.

Tramitación de Rexistro para o Servizo de Enrutamento

Agora necesitamos, de feito, crear listas de prefixos e enderezos IP, que se mencionan no paso anterior no protocolo estático. Para iso, collemos o ficheiro de rexistro e extraemos del os ficheiros que necesitamos co seguinte script, situado en /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'

Non esquezas facelo executable

chmod +x /root/blacklist/makebgp

Agora pode executalo manualmente e observar a aparición dos ficheiros en /etc/bird.

O máis probable é que neste momento o paxaro non che funcione, porque na fase anterior suxexiches que buscara ficheiros que aínda non existían. Polo tanto, lanzámolo e controlamos que se inicie:

systemctl start bird
birdc show route

A saída do segundo comando debería mostrar unhas 80 entradas (neste momento, e cando o configures, todo dependerá do celo do ILV no bloqueo de redes), así:

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

Equipo

birdc show protocol

mostrará o estado dos protocolos dentro do servizo. Ata que configure o enrutador (consulte o seguinte parágrafo), o protocolo OurRouter estará no estado de inicio (fases Conectar ou Activo), e despois dunha conexión exitosa, pasará ao estado superior (fase establecida). Por exemplo, no meu sistema, a saída deste comando é así:

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

Conectando un router

Probablemente todo o mundo xa está canso de ler este pano, pero anímate: o final está preto. Ademais, nesta sección non poderei dar instrucións paso a paso: será diferente para cada fabricante.

Non obstante, podo mostrarche un par de exemplos. A lóxica principal é aumentar o peering BGP e engadir nexthop a todos os prefixos recibidos, apuntando ao noso túnel (se precisas enviar tráfico a través da interface p2p) ou o enderezo IP nexthop se o tráfico vai a Ethernet).

Por exemplo, en Mikrotik en RouterOS, isto resólvese do seguinte xeito

/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

e en Cisco IOS - así

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

Se se usa o mesmo túnel tanto para o peering BGP como para transmitir tráfico útil, non é necesario configurar nexthop; establecerase correctamente mediante o protocolo. Pero se o configuras manualmente, tampouco o empeorará.

Noutras plataformas, terás que descubrir a configuración por ti mesmo, pero se tes algunha dificultade, escribe nos comentarios, tentarei axudar.

Despois de aumentar a súa sesión BGP, as rutas a grandes redes chegaron e están instaladas na táboa, o tráfico aos enderezos desde elas desapareceu e a felicidade está preto, pode volver ao servizo de aves e tentar descomentar a entrada alí que conecta o lista de enderezos IP, execute despois diso

systemctl reload bird

e mira como o teu router transferiu estas 85 mil rutas. Prepárate para apagalo e pensa que facer con el 🙂

En total

En teoría, despois de realizar os pasos anteriores, tes un servizo que redirixe automaticamente o tráfico a enderezos IP prohibidos na Federación Rusa máis aló do sistema de filtrado.

Por suposto, pódese mellorar. Por exemplo, é o suficientemente sinxelo resumir unha lista de enderezos IP mediante solucións perl ou python. Un simple script Perl que fai isto con Net::CIDR::Lite converte 85 mil prefixos en 60 (non mil), pero, naturalmente, cobre un rango moito máis grande de enderezos do que está bloqueado.

Dado que o servizo funciona no terceiro nivel do modelo ISO/OSI, non che salvará do bloqueo do sitio/páxina se non se resolve ao enderezo rexistrado no rexistro. Pero xunto co rexistro de github, chega o ficheiro nxdomain.txt, que con algúns trazos do script se converte facilmente nunha fonte de enderezos para, por exemplo, o complemento SwitchyOmega en Chrome.

Tamén hai que mencionar que a solución require un perfeccionamento adicional se non só es un usuario de Internet, senón que tamén publica algúns recursos propios (por exemplo, un sitio web ou un servidor de correo execútase nesta conexión). Mediante o enrutador, cómpre vincular o tráfico saínte desde este servizo ao seu enderezo público, se non, perderá a conectividade con aqueles recursos que están cubertos pola lista de prefixos que recibe o enrutador.

Se tes algunha dúbida, pregunta, listo para responder.

UPD. Grazas navión и TerAnYu para as opcións de git para reducir os volumes de descarga.

UPD2. Compañeiros, parece que cometín un erro ao non engadir instrucións para configurar un túnel entre o VPS e o enrutador ao artigo. Moitas preguntas son causadas por isto.
Por se acaso, volvo notar: suponse que antes de comezar os pasos desta guía, xa configurou o túnel VPN na dirección que precisa e comprobou o seu rendemento (por exemplo, envolvendo o tráfico alí por defecto ou estático). Se aínda non completaches esta fase, non ten sentido seguir os pasos do artigo. Aínda non teño o meu propio texto sobre isto, pero se buscas en Google "Configuración do servidor OpenVPN" xunto co nome do sistema operativo instalado no VPS e "Configuración do cliente OpenVPN" co nome do teu enrutador, probablemente atopará unha serie de artigos sobre este tema, incluído sobre Habré.

UPD3. Non sacrificado escribiu un código que fai o ficheiro resultante para bird de dump.csv cunha suma opcional de enderezos IP. Polo tanto, a sección "Tramitación de rexistro para o servizo de enrutamento" pódese substituír por unha chamada ao seu programa. https://habr.com/post/354282/#comment_10782712

UPD4. Un pequeno traballo sobre os erros (non contribuíron no texto):
1) en cambio systemctl recarga bird ten sentido usar o comando Birdc configurar.
2) no router Mikrotik, en lugar de cambiar o seguinte salto á IP do segundo lado do túnel /routing filter add action=accept chain=dynamic-in protocol=bgp comment="Establecer nexthop" set-in-nexthop=172.30.1.1 ten sentido especificar a ruta directamente á interface do túnel, sen o enderezo /routing filter add action=accept chain=dynamic-in protocol=bgp comment="Establecer nexthop" set-in-nexthop-direct=<nome da interface>

UPD5. Chegou un novo servizo https://antifilter.download, de onde podes sacar listas preparadas de enderezos IP. Actualizado cada media hora. No lado do cliente, só queda enmarcar as entradas coa correspondente “ruta... rexeitar”.
E iso probablemente sexa suficiente para follar á miña avoa e actualizar o artigo.

UPD6. Unha versión revisada do artigo para aqueles que non queiran entender, pero queren comezar - aquí.

Fonte: www.habr.com

Configurando BGP para evitar o bloqueo ou "Como deixei de ter medo e me namorei de RKN"