ProHoster > Blogs > Administrācija > Apiet ILV bloÄ·Ä“Å”anu, izmantojot DNSTap un BGP

Apiet ILV bloķēŔanu, izmantojot DNSTap un BGP

Apiet ILV bloķēŔanu, izmantojot DNSTap un BGP

Tēma ir diezgan sagrauta, es zinu. Piemēram, ir lieliska raksts, bet tur tiek apskatÄ«ta tikai bloÄ·Ä“Å”anas saraksta IP daļa. Mēs pievienosim arÄ« domēnus.

Sakarā ar to, ka tiesas un RKN bloķē visu pa labi un pa kreisi, un pakalpojumu sniedzēji cenÅ”as nepakļauties Revizorro noteiktajām soda naudām, ar to saistÄ«tie zaudējumi no bloÄ·Ä“Å”anas ir diezgan lieli. Un starp "likumÄ«gi" bloķētajām vietnēm ir daudz noderÄ«gu (sveiki, rutracker)

Es dzÄ«voju ārpus RKN jurisdikcijas, bet mani vecāki, radi un draugi palika mājās. Tāpēc tika nolemts izdomāt vienkārÅ”u veidu, kā cilvēkiem, kas ir tālu no IT, apiet bloÄ·Ä“Å”anu, vēlams vispār bez viņu lÄ«dzdalÄ«bas.

Å ajā piezÄ«mē es neaprakstÄ«Å”u tÄ«kla pamata lietas pa soļiem, bet aprakstÄ«Å”u vispārÄ«gos principus, kā Å”o shēmu var ieviest. Tāpēc zināŔanas par to, kā tÄ«kls darbojas kopumā un jo Ä«paÅ”i Linux, ir obligātas.

Slēdzeņu veidi

Vispirms atsvaidzināsim atmiņu par to, kas tiek bloķēts.

No RKN izlādētajā XML ir vairāki bloÄ·Ä“Å”anas veidi:

  • IP
  • Domēna vārds
  • URL

VienkārŔības labad mēs tos samazināsim lÄ«dz diviem: IP un domēns, un mēs vienkārÅ”i izņemsim domēnu no bloÄ·Ä“Å”anas, izmantojot URL (precÄ«zāk, viņi to jau ir izdarÄ«juÅ”i mÅ«su vietā).

labi cilvēki no Roskomsvoboda sapratu brÄ«niŔķīgu API, caur kuru mēs varam iegÅ«t nepiecieÅ”amo:

Piekļuve bloķētām vietnēm

Lai to izdarÄ«tu, mums ir nepiecieÅ”ams neliels ārzemju VPS, vēlams ar neierobežotu trafiku - tādu ir daudz par 3-5 dolāriem. Jāņem tuvējās ārzemēs, lai ping nebÅ«tu ļoti liels, bet atkal jāņem vērā, ka internets un Ä£eogrāfija ne vienmēr sakrÄ«t. Un tā kā nav SLA par 5 dolāriem, labāk ir ņemt 2+ gabalus no dažādiem pakalpojumu sniedzējiem, lai nodroÅ”inātu kļūdu toleranci.

Tālāk mums ir jāiestata Å”ifrēts tunelis no klienta marÅ”rutētāja uz VPS. Es izmantoju Wireguard kā visātrāk un vienkārŔāk iestatāmo. Man ir arÄ« klientu marÅ”rutētāji, kuru pamatā ir Linux (APU2 vai kaut kas OpenWRT). Dažu Mikrotik / Cisco gadÄ«jumā varat izmantot tajos pieejamos protokolus, piemēram, OpenVPN un GRE-over-IPSEC.

InteresējoŔās satiksmes identificÄ“Å”ana un novirzÄ«Å”ana

Jūs, protams, varat izslēgt visu interneta trafiku caur ārvalstīm. Bet, visticamāk, no tā ļoti cietīs darba ātrums ar vietējo saturu. Turklāt VPS joslas platuma prasības būs daudz augstākas.

Tāpēc mums bÅ«s kaut kādā veidā jāpieŔķir satiksme bloķētajām vietnēm un selektÄ«vi jānovirza uz tuneli. Pat ja daļa "papildu" satiksmes tur nonāk, tas joprojām ir daudz labāk, nekā braukt visu caur tuneli.

Lai pārvaldÄ«tu trafiku, mēs izmantosim BGP protokolu un izziņosim marÅ”rutus uz nepiecieÅ”amajiem tÄ«kliem no mÅ«su VPS klientiem. Ņemsim BIRD kā vienu no funkcionālākajiem un ērtākajiem BGP dēmoniem.

IP

Izmantojot IP bloÄ·Ä“Å”anu, viss ir skaidrs: mēs vienkārÅ”i paziņojam par visiem bloķētajiem IP, izmantojot VPS. Problēma ir tā, ka sarakstā, ko atgriež API, ir aptuveni 600 tÅ«kstoÅ”i apakÅ”tÄ«klu, un lielākā daļa no tiem ir /32 saimniekdatori. Å is marÅ”rutu skaits var sajaukt vājus klientu marÅ”rutētājus.

Tāpēc, apstrādājot sarakstu, tika nolemts apkopot lÄ«dz tÄ«klam / 24, ja tajā ir 2 vai vairāk saimniekdatoru. LÄ«dz ar to marÅ”rutu skaits tika samazināts lÄ«dz ~100 tÅ«kst. Skripts tam sekos.

Domains

Tas ir sarežģītāk, un ir vairāki veidi. Piemēram, jÅ«s varat instalēt caurspÄ«dÄ«gu Squid katrā klienta marÅ”rutētājā un veikt HTTP pārtverÅ”anu un ieskatÄ«ties TLS rokasspiedienā, lai pirmajā gadÄ«jumā iegÅ«tu pieprasÄ«to URL un otrajā gadÄ«jumā domēnu no SNI.

Bet visu veidu jaunizveidoto TLS1.3 + eSNI dēļ HTTPS analÄ«ze katru dienu kļūst arvien mazāk reāla. Jā, un infrastruktÅ«ra klienta pusē kļūst sarežģītāka ā€“ bÅ«s jāizmanto vismaz OpenWRT.

Tāpēc es nolēmu pārtvert atbildes uz DNS vaicājumiem. ArÄ« Å”eit jebkurÅ” DNS-over-TLS / HTTPS sāk virzÄ«ties virs jÅ«su galvas, taču mēs varam (pagaidām) kontrolēt Å”o klienta daļu - vai nu to atspējot, vai izmantot savu serveri DoT / DoH.

Kā pārtvert DNS?

Arī Ŕeit var būt vairākas pieejas.

  • DNS trafika pārtverÅ”ana, izmantojot PCAP vai NFLOG
    Abas Ŕīs pārtverÅ”anas metodes ir ieviestas utilÄ«tprogrammā sidmat. Bet tas nav atbalstÄ«ts ilgu laiku un funkcionalitāte ir ļoti primitÄ«va, tāpēc jums joprojām ir jāraksta uzkabe.
  • DNS servera žurnālu analÄ«ze
    Diemžēl man zināmie rekursori nespēj reÄ£istrēt atbildes, bet tikai pieprasÄ«jumus. Principā tas ir loÄ£iski, jo atŔķirÄ«bā no pieprasÄ«jumiem atbildēm ir sarežģīta struktÅ«ra un ir grÅ«ti tās uzrakstÄ«t teksta formā.
  • DNSTap
    Par laimi, daudzi no viņiem jau atbalsta DNSTap Å”im nolÅ«kam.

Kas ir DNSTap?

Apiet ILV bloķēŔanu, izmantojot DNSTap un BGP

Tas ir klienta-servera protokols, kura pamatā ir protokolu buferi un kadru straumes, lai pārsūtītu no DNS servera uz strukturētu DNS vaicājumu un atbilžu savācēju. Būtībā DNS serveris tīklā pārsūta vaicājumu un atbilžu metadatus (ziņojuma veidu, klienta/servera IP utt.), kā arī pilnīgus DNS ziņojumus (binārajā) formā, kādā tas darbojas ar tiem.

Ir svarīgi saprast, ka DNSTap paradigmā DNS serveris darbojas kā klients un savācējs darbojas kā serveris. Tas nozīmē, ka DNS serveris izveido savienojumu ar kolektoru, nevis otrādi.

MÅ«sdienās DNSTap tiek atbalstÄ«ts visos populārajos DNS serveros. Bet, piemēram, BIND daudzos izplatÄ«jumos (piemēram, Ubuntu LTS) kādu iemeslu dēļ bieži tiek veidots bez tā atbalsta. Tāpēc neuzbāzÄ«simies ar atkārtotu montāžu, bet ņemsim vieglāku un ātrāku rekursoru - Bez saistÄ«Å”anas.

Kā noķert DNSTap?

Ir daži numurs CLI utilÄ«tas darbam ar DNSTap notikumu straumi, taču tās nav piemērotas mÅ«su problēmas risināŔanai. Tāpēc es nolēmu izgudrot savu velosipēdu, kas darÄ«s visu nepiecieÅ”amo: dnsap-bgp

Darba algoritms:

  • Palaižot, tas ielādē domēnu sarakstu no teksta faila, apvērÅ” tos (habr.com -> com.habr), izslēdz lauztās lÄ«nijas, dublikātus un apakÅ”domēnus (t.i., ja sarakstā ir habr.com un www.habr.com, tas tiks ielādēts tikai pirmais) un izveido prefiksu koku ātrai meklÄ“Å”anai Å”ajā sarakstā
  • Darbojoties kā DNSTap serveris, tas gaida savienojumu no DNS servera. Principā tas atbalsta gan UNIX, gan TCP ligzdas, bet man zināmie DNS serveri var izmantot tikai UNIX ligzdas
  • IenākoŔās DNSTap paketes vispirms tiek deserializētas Protobuf struktÅ«rā, un pēc tam pats binārais DNS ziņojums, kas atrodas vienā no Protobuf laukiem, tiek parsēts DNS RR ierakstu lÄ«menÄ«.
  • Tiek pārbaudÄ«ts, vai pieprasÄ«tais resursdators (vai tā vecākais domēns) ir ielādētajā sarakstā, ja nē, atbilde tiek ignorēta
  • No atbildes tiek atlasÄ«ti tikai A/AAAA/CNAME RR, un no tiem tiek izvilktas atbilstoŔās IPv4/IPv6 adreses.
  • IP adreses tiek saglabātas keÅ”atmiņā ar konfigurējamu TTL un tiek reklamētas visiem konfigurētajiem BGP partneriem
  • Saņemot atbildi, kas norāda uz jau keÅ”atmiņā saglabātu IP, tā TTL tiek atjaunināts
  • Pēc TTL termiņa beigām ieraksts tiek noņemts no keÅ”atmiņas un no BGP paziņojumiem

Papildu funkcionalitāte:

  • SIGHUP atkārtoti izlasa domēnu sarakstu
  • KeÅ”atmiņas sinhronizÄ“Å”ana ar citiem gadÄ«jumiem dnsap-bgp izmantojot HTTP/JSON
  • Dublējiet keÅ”atmiņu diskā (BoltDB datu bāzē), lai pēc restartÄ“Å”anas atjaunotu tās saturu
  • Atbalsts pārslēgÅ”anai uz citu tÄ«kla nosaukumvietu (kāpēc tas ir nepiecieÅ”ams, tiks aprakstÄ«ts tālāk)
  • IPv6 atbalsts

Ierobežojumi:

  • IDN domēni vēl netiek atbalstÄ«ti
  • Daži BGP iestatÄ«jumi

Es savācu RPM un DEB paketes ērtai uzstādÄ«Å”anai. Jāstrādā visās salÄ«dzinoÅ”i jaunākajās OS ar systemd. viņiem nav nekādu atkarÄ«bu.

Shēma

Tātad, sāksim montēt visas sastāvdaļas kopā. Rezultātā mums vajadzētu iegÅ«t kaut ko lÄ«dzÄ«gu Å”ai tÄ«kla topoloÄ£ijai:
Apiet ILV bloķēŔanu, izmantojot DNSTap un BGP

Darba loģika, manuprāt, ir skaidra no diagrammas:

  • Klientam mÅ«su serveris ir konfigurēts kā DNS, un arÄ« DNS vaicājumiem ir jāiet pāri VPN. Tas ir nepiecieÅ”ams, lai pakalpojumu sniedzējs nevarētu izmantot DNS pārtverÅ”anu bloÄ·Ä“Å”anai.
  • Atverot vietni, klients nosÅ«ta DNS vaicājumu, piemēram, "kas ir xxx.org IP"
  • Nav saistÄ«bu atrisina xxx.org (vai paņem to no keÅ”atmiņas) un nosÅ«ta klientam atbildi ā€œxxx.org ir tāds un tāds IPā€, paralēli dublējot to caur DNSTap
  • dnsap-bgp paziņo Ŕīs adreses BIRD izmantojot BGP, ja domēns ir bloķēto sarakstā
  • BIRD reklamē marÅ”rutu uz Ŕīm IP ar next-hop self klienta marÅ”rutētājs
  • Turpmākās paketes no klienta uz Ŕīm IP iet caur tuneli

ServerÄ« marÅ”rutiem uz bloķētām vietnēm izmantoju atseviŔķu tabulu iekŔā BIRD un tā nekādā veidā nekrustojas ar OS.

Å ai shēmai ir trÅ«kums: pirmajai SYN paketei no klienta, visticamāk, bÅ«s laiks iziet caur vietējo pakalpojumu sniedzēju. marÅ”ruts netiek paziņots uzreiz. Un Å”eit ir iespējamas iespējas atkarÄ«bā no tā, kā pakalpojumu sniedzējs veic bloÄ·Ä“Å”anu. Ja viņŔ vienkārÅ”i samazina satiksmi, tad problēmu nav. Un ja viņŔ to novirza uz kādu DPI, tad (teorētiski) ir iespējami specefekti.

Iespējams arÄ«, ka klienti neievēro DNS TTL brÄ«numus, kas var likt klientam izmantot dažus novecojuÅ”us ierakstus no tās sapuvuŔās keÅ”atmiņas, nevis jautāt Unbound.

Praksē ne pirmais, ne otrais man problēmas nesagādāja, bet jÅ«su nobraukums var atŔķirties.

Servera noskaņoÅ”ana

Lai atvieglotu ripināŔanu, es uzrakstÄ«ju lomu Ansible. Tas var konfigurēt gan serverus, gan klientus, pamatojoties uz Linux (paredzēts uz deb balstÄ«tiem izplatÄ«jumiem). Visi iestatÄ«jumi ir diezgan skaidri un ir iestatÄ«ti inventārs.yml. Å Ä« loma ir izgriezta no manas lielās rokasgrāmatas, tāpēc tajā var bÅ«t kļūdas. vilkÅ”anas pieprasÄ«jumi laipni lÅ«dzam šŸ™‚

Apskatīsim galvenās sastāvdaļas.

BGP

Divu BGP dēmonu darbināŔanai vienā un tajā paŔā resursdatorā ir bÅ«tiska problēma: BIRD nevēlas iestatÄ«t BGP peering ar localhost (vai jebkuru vietējo saskarni). No vārda vispār. GooglÄ“Å”ana un adresātu sarakstu lasÄ«Å”ana nepalÄ«dzēja, viņi apgalvo, ka tas ir izstrādāts. VarbÅ«t ir kāds veids, bet es to neatradu.

Jūs varat izmēģināt citu BGP dēmonu, bet man patīk BIRD, un es to izmantoju visur, es nevēlos radīt entītijas.

Tāpēc es paslēpu dnsap-bgp tÄ«kla nosaukumvietā, kas ir savienota ar sakni caur veth interfeisu: tā ir kā caurule, kuras gali izceļas dažādās nosaukumvietās. Katrā no Å”iem galiem mēs piekarinām privātas p2p IP adreses, kas nepārsniedz resursdatoru, tāpēc tās var bÅ«t jebkas. Tas ir tas pats mehānisms, ko izmanto, lai piekļūtu iekŔējiem procesiem visu mÄ«lēja Docker un citi konteineri.

Par to tika rakstÄ«ts skripts un dnsap-bgp tika pievienota jau iepriekÅ” aprakstÄ«tā funkcionalitāte aiz mata vilkÅ”anai citā nosaukumvietā. Å Ä« iemesla dēļ tas ir jāpalaiž kā root vai jāizdod binārajam failam CAP_SYS_ADMIN, izmantojot komandu setcap.

Skripta piemērs nosaukumvietas izveidei

#!/bin/bash

NS="dtap"

IP="/sbin/ip"
IPNS="$IP netns exec $NS $IP"

IF_R="veth-$NS-r"
IF_NS="veth-$NS-ns"

IP_R="192.168.149.1"
IP_NS="192.168.149.2"

/bin/systemctl stop dnstap-bgp || true

$IP netns del $NS > /dev/null 2>&1
$IP netns add $NS

$IP link add $IF_R type veth peer name $IF_NS
$IP link set $IF_NS netns $NS

$IP addr add $IP_R remote $IP_NS dev $IF_R
$IP link set $IF_R up

$IPNS addr add $IP_NS remote $IP_R dev $IF_NS
$IPNS link set $IF_NS up

/bin/systemctl start dnstap-bgp

dnstap-bgp.conf

namespace = "dtap"
domains = "/var/cache/rkn_domains.txt"
ttl = "168h"

[dnstap]
listen = "/tmp/dnstap.sock"
perm = "0666"

[bgp]
as = 65000
routerid = "192.168.149.2"

peers = [
    "192.168.149.1",
]

putns.conf

router id 192.168.1.1;

table rkn;

# Clients
protocol bgp bgp_client1 {
    table rkn;
    local as 65000;
    neighbor 192.168.1.2 as 65000;
    direct;
    bfd on;
    next hop self;
    graceful restart;
    graceful restart time 60;
    export all;
    import none;
}

# DNSTap-BGP
protocol bgp bgp_dnstap {
    table rkn;
    local as 65000;
    neighbor 192.168.149.2 as 65000;
    direct;
    passive on;
    rr client;
    import all;
    export none;
}

# Static routes list
protocol static static_rkn {
    table rkn;
    include "rkn_routes.list";
    import all;
    export none;
}

rkn_routes.list

route 3.226.79.85/32 via "ens3";
route 18.236.189.0/24 via "ens3";
route 3.224.21.0/24 via "ens3";
...

DNS

Pēc noklusējuma Ubuntu nesaistÄ«to bināro failu ierobežo AppArmor profils, kas aizliedz tam izveidot savienojumu ar visa veida DNSTap ligzdām. Varat dzēst Å”o profilu vai atspējot to:

# cd /etc/apparmor.d/disable && ln -s ../usr.sbin.unbound .
# apparmor_parser -R /etc/apparmor.d/usr.sbin.unbound

Tas droŔi vien būtu jāpievieno rokasgrāmatai. Ideāli, protams, izlabot profilu un izsniegt nepiecieŔamās tiesības, bet man bija slinkums.

unbound.conf

server:
    chroot: ""
    port: 53
    interface: 0.0.0.0
    root-hints: "/var/lib/unbound/named.root"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    access-control: 192.168.0.0/16 allow

remote-control:
    control-enable: yes
    control-use-cert: no

dnstap:
    dnstap-enable: yes
    dnstap-socket-path: "/tmp/dnstap.sock"
    dnstap-send-identity: no
    dnstap-send-version: no

    dnstap-log-client-response-messages: yes

Sarakstu lejupielāde un apstrāde

Skripts IP adreŔu saraksta lejupielādei un apstrādei
Tas lejupielādē sarakstu, apkopo prefiksu pfx. Uz nepievienot Šø dont_summarize varat norādÄ«t IP un tÄ«klus, lai tie izlaistu vai neveic kopsavilkumu. Man to vajadzēja. mana VPS apakÅ”tÄ«kls bija bloÄ·Ä“Å”anas sarakstā šŸ™‚

Smieklīgākais ir tas, ka RosKomSvoboda API bloķē pieprasījumus ar noklusējuma Python lietotāja aģentu. Šķiet, ka skripts to saprata. Tāpēc mainām uz Ognelis.

Līdz Ŕim tas darbojas tikai ar IPv4. IPv6 daļa ir neliela, taču to būs viegli salabot. Ja vien nav jāizmanto arī bird6.

rkn.py

#!/usr/bin/python3

import json, urllib.request, ipaddress as ipa

url = 'https://api.reserve-rbl.ru/api/v2/ips/json'
pfx = '24'

dont_summarize = {
    # ipa.IPv4Network('1.1.1.0/24'),
}

dont_add = {
    # ipa.IPv4Address('1.1.1.1'),
}

req = urllib.request.Request(
    url,
    data=None, 
    headers={
        'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.47 Safari/537.36'
    }
)

f = urllib.request.urlopen(req)
ips = json.loads(f.read().decode('utf-8'))

prefix32 = ipa.IPv4Address('255.255.255.255')

r = {}
for i in ips:
    ip = ipa.ip_network(i)
    if not isinstance(ip, ipa.IPv4Network):
        continue

    addr = ip.network_address

    if addr in dont_add:
        continue

    m = ip.netmask
    if m != prefix32:
        r[m] = [addr, 1]
        continue

    sn = ipa.IPv4Network(str(addr) + '/' + pfx, strict=False)

    if sn in dont_summarize:
        tgt = addr
    else:
        tgt = sn

    if not sn in r:
        r[tgt] = [addr, 1]
    else:
        r[tgt][1] += 1

o = []
for n, v in r.items():
    if v[1] == 1:
        o.append(str(v[0]) + '/32')
    else:
        o.append(n)

for k in o:
    print(k)

Atjaunināmais skripts
Es to palaistu uz vainaga reizi dienā, varbÅ«t ir vērts to vilkt ik pēc 4 stundām. Å”is, manuprāt, ir atjaunoÅ”anas periods, ko RKN pieprasa no pakalpojumu sniedzējiem. Turklāt tiem ir kāda cita Ä«paÅ”i steidzama bloÄ·Ä“Å”ana, kas var notikt ātrāk.

Veic Ŕādas darbības:

  • Palaiž pirmo skriptu un atjaunina marÅ”rutu sarakstu (rkn_routes.list) par PUTNU
  • Pārlādēt BIRD
  • Atjaunina un notÄ«ra dnsap-bgp domēnu sarakstu
  • Pārlādēt dnsap-bgp

rkn_update.sh

#!/bin/bash

ROUTES="/etc/bird/rkn_routes.list"
DOMAINS="/var/cache/rkn_domains.txt"

# Get & summarize routes
/opt/rkn.py | sed 's/(.*)/route 1 via "ens3";/' > $ROUTES.new

if [ $? -ne 0 ]; then
    rm -f $ROUTES.new
    echo "Unable to download RKN routes"
    exit 1
fi

if [ -e $ROUTES ]; then
    mv $ROUTES $ROUTES.old
fi

mv $ROUTES.new $ROUTES

/bin/systemctl try-reload-or-restart bird

# Get domains
curl -s https://api.reserve-rbl.ru/api/v2/domains/json -o - | jq -r '.[]' | sed 's/^*.//' | sort | uniq > $DOMAINS.new

if [ $? -ne 0 ]; then
    rm -f $DOMAINS.new
    echo "Unable to download RKN domains"
    exit 1
fi

if [ -e $DOMAINS ]; then
    mv $DOMAINS $DOMAINS.old
fi

mv $DOMAINS.new $DOMAINS

/bin/systemctl try-reload-or-restart dnstap-bgp

Tie tika rakstÄ«ti bez Ä«paÅ”as domāŔanas, tāpēc, ja redzat kaut ko, ko var uzlabot - dodieties uz to.

Klienta iestatīŔana

Å eit es sniegÅ”u piemērus Linux marÅ”rutētājiem, bet Mikrotik / Cisco gadÄ«jumā tam vajadzētu bÅ«t vēl vienkārŔākam.

Pirmkārt, mēs iestatījām BIRD:

putns.conf

router id 192.168.1.2;
table rkn;

protocol device {
    scan time 10;
};

# Servers
protocol bgp bgp_server1 {
    table rkn;
    local as 65000;
    neighbor 192.168.1.1 as 65000;
    direct;
    bfd on;
    next hop self;
    graceful restart;
    graceful restart time 60;
    rr client;
    export none;
    import all;
}

protocol kernel {
    table rkn;
    kernel table 222;
    scan time 10;
    export all;
    import none;
}

Tādējādi mēs sinhronizēsim no BGP saņemtos marÅ”rutus ar kodola marÅ”rutÄ“Å”anas tabulu ar numuru 222.

Pēc tam pietiek palÅ«gt kodolam apskatÄ«t Å”o plāksni, pirms skatāties uz noklusējuma:

# ip rule add from all pref 256 lookup 222
# ip rule
0:  from all lookup local
256:    from all lookup 222
32766:  from all lookup main
32767:  from all lookup default

Viss, atliek marÅ”rutētājā konfigurēt DHCP, lai izplatÄ«tu servera tuneļa IP adresi kā DNS, un shēma ir gatava.

Ierobežojumi

Izmantojot paÅ”reizējo domēnu saraksta Ä£enerÄ“Å”anas un apstrādes algoritmu, tas cita starpā ietver youtube.com un tā CDN.

Un tas noved pie tā, ka visi videoklipi tiks pārraidÄ«ti caur VPN, kas var aizsprostot visu kanālu. VarbÅ«t ir vērts sastādÄ«t sarakstu ar populāriem domēniem-izņēmumiem, kas pagaidām bloķē RKN, iekÅ”as ir plānas. Un izlaidiet tos parsÄ“Å”anas laikā.

Secinājums

AprakstÄ«tā metode ļauj apiet gandrÄ«z jebkuru bloÄ·Ä“Å”anu, ko pakalpojumu sniedzēji paÅ”laik Ä«steno.

Principā, dnsap-bgp var izmantot jebkuram citam mērÄ·im, kur ir nepiecieÅ”ama noteikta lÄ«meņa trafika kontrole, pamatojoties uz domēna nosaukumu. VienkārÅ”i paturiet prātā, ka mÅ«su laikā tÅ«kstoÅ” vietņu var karāties vienā IP adresē (piemēram, aiz kāda Cloudflare), tāpēc Å”ai metodei ir diezgan zema precizitāte.

Bet slēdzeņu apieÅ”anas vajadzÄ«bām ar to pilnÄ«gi pietiek.

Papildinājumi, labojumi, izvilkŔanas pieprasījumi - laipni lūdzam!

Avots: www.habr.com

Pievieno komentāru