Το θέμα είναι αρκετά μπερδεμένο, το ξέρω. Για παράδειγμα, υπάρχει μια μεγάλη άρθρο, αλλά μόνο το τμήμα IP της λίστας αποκλεισμού λαμβάνεται υπόψη εκεί. Θα προσθέσουμε επίσης τομείς.

Λόγω του γεγονότος ότι τα δικαστήρια και το RKN μπλοκάρουν τα πάντα δεξιά και αριστερά και οι πάροχοι προσπαθούν σκληρά να μην εμπίπτουν στα πρόστιμα που έχει εκδώσει η Revizorro, οι σχετικές απώλειες από τον αποκλεισμό είναι αρκετά μεγάλες. Και μεταξύ των "νόμιμα" αποκλεισμένων τοποθεσιών υπάρχουν πολλοί χρήσιμοι (γεια σας, rutracker)

Ζω εκτός δικαιοδοσίας του RKN, αλλά οι γονείς, οι συγγενείς και οι φίλοι μου παρέμειναν στο σπίτι. Έτσι αποφασίστηκε να βρεθεί ένας εύκολος τρόπος για να παρακάμψουν το μπλοκάρισμα άτομα μακριά από την τεχνολογία, κατά προτίμηση χωρίς τη συμμετοχή τους.

Σε αυτό το σημείωμα, δεν θα περιγράψω τα βασικά πράγματα του δικτύου σταδιακά, αλλά θα περιγράψω τις γενικές αρχές για το πώς μπορεί να εφαρμοστεί αυτό το σχήμα. Επομένως, η γνώση του πώς λειτουργεί το δίκτυο γενικά και στο Linux ειδικότερα είναι απαραίτητη.

Τύποι κλειδαριών

Αρχικά, ας ανανεώσουμε τη μνήμη μας για το τι μπλοκάρεται.

Υπάρχουν διάφοροι τύποι κλειδαριών στο μη φορτωμένο XML από το RKN:

IP
Όνομα τομέα
URL

Για απλότητα, θα τα μειώσουμε σε δύο: IP και domain, και απλώς θα αποσύρουμε τον αποκλεισμό του τομέα μέσω URL (πιο συγκεκριμένα, το έχουν κάνει ήδη για εμάς).

καλοί άνθρωποι από Roskomsvoboda συνειδητοποίησε ένα υπέροχο API, μέσω του οποίου μπορούμε να πάρουμε ότι χρειαζόμαστε:

ΠΕ: https://api.reserve-rbl.ru/api/v2/ips/json
Τομείς: https://api.reserve-rbl.ru/api/v2/domains/json

Πρόσβαση σε αποκλεισμένους ιστότοπους

Για να γίνει αυτό, χρειαζόμαστε μερικά μικρά ξένα VPS, κατά προτίμηση με απεριόριστη κίνηση - υπάρχουν πολλά από αυτά για 3-5 δολάρια. Πρέπει να το πάρετε στο κοντινό εξωτερικό, έτσι ώστε το ping να μην είναι πολύ μεγάλο, αλλά και πάλι, λάβετε υπόψη ότι το Διαδίκτυο και η γεωγραφία δεν συμπίπτουν πάντα. Και επειδή δεν υπάρχει SLA για 5 δολάρια, είναι καλύτερο να πάρετε 2+ κομμάτια από διαφορετικούς παρόχους για ανοχή σφαλμάτων.

Στη συνέχεια, πρέπει να ρυθμίσουμε ένα κρυπτογραφημένο τούνελ από τον δρομολογητή πελάτη στο VPS. Χρησιμοποιώ το Wireguard ως το πιο γρήγορο και εύκολο στη ρύθμιση. Έχω επίσης δρομολογητές πελάτη που βασίζονται σε Linux (APU2 ή κάτι στο OpenWRT). Στην περίπτωση ορισμένων Mikrotik / Cisco, μπορείτε να χρησιμοποιήσετε τα πρωτόκολλα που είναι διαθέσιμα σε αυτά, όπως το OpenVPN και το GRE-over-IPSEC.

Προσδιορισμός και ανακατεύθυνση της κίνησης ενδιαφέροντος

Μπορείτε, φυσικά, να απενεργοποιήσετε όλη την κίνηση στο Διαδίκτυο μέσω ξένων χωρών. Αλλά, πιθανότατα, η ταχύτητα εργασίας με τοπικό περιεχόμενο θα υποφέρει πολύ από αυτό. Επιπλέον, οι απαιτήσεις εύρους ζώνης στο VPS θα είναι πολύ υψηλότερες.

Επομένως, θα χρειαστεί να κατανείμουμε με κάποιο τρόπο την επισκεψιμότητα σε αποκλεισμένους ιστότοπους και να την κατευθύνουμε επιλεκτικά στη σήραγγα. Ακόμα κι αν κάποια από την «επιπλέον» κίνηση φτάσει εκεί, είναι ακόμα πολύ καλύτερο από το να οδηγείς τα πάντα μέσα από το τούνελ.

Για τη διαχείριση της κυκλοφορίας, θα χρησιμοποιήσουμε το πρωτόκολλο BGP και θα ανακοινώσουμε διαδρομές προς τα απαραίτητα δίκτυα από το VPS μας στους πελάτες. Ας πάρουμε το BIRD ως έναν από τους πιο λειτουργικούς και βολικούς δαίμονες BGP.

IP

Με τον αποκλεισμό μέσω IP, όλα είναι ξεκάθαρα: απλώς ανακοινώνουμε όλες τις αποκλεισμένες IP με VPS. Το πρόβλημα είναι ότι υπάρχουν περίπου 600 χιλιάδες υποδίκτυα στη λίστα που επιστρέφει το API και η συντριπτική τους πλειοψηφία είναι /32 hosts. Αυτός ο αριθμός διαδρομών μπορεί να προκαλέσει σύγχυση στους αδύναμους δρομολογητές-πελάτες.

Επομένως, κατά την επεξεργασία της λίστας, αποφασίστηκε να συνοψιστεί μέχρι το δίκτυο / 24 εάν έχει 2 ή περισσότερους κεντρικούς υπολογιστές. Έτσι, ο αριθμός των δρομολογίων μειώθηκε σε ~100 χιλιάδες. Θα ακολουθήσει το σενάριο για αυτό.

τομείς

Είναι πιο περίπλοκο και υπάρχουν διάφοροι τρόποι. Για παράδειγμα, μπορείτε να εγκαταστήσετε ένα διαφανές Squid σε κάθε δρομολογητή πελάτη και να κάνετε υποκλοπή HTTP εκεί και να παρακολουθήσετε τη χειραψία TLS για να λάβετε το ζητούμενο URL στην πρώτη περίπτωση και τον τομέα από το SNI στη δεύτερη.

Όμως, λόγω όλων των ειδών καινούριων TLS1.3 + eSNI, η ανάλυση HTTPS γίνεται όλο και λιγότερο πραγματική κάθε μέρα. Ναι, και η υποδομή στην πλευρά του πελάτη γίνεται πιο περίπλοκη - θα πρέπει να χρησιμοποιήσετε τουλάχιστον το OpenWRT.

Ως εκ τούτου, αποφάσισα να ακολουθήσω τον δρόμο της υποκλοπής απαντήσεων σε αιτήματα DNS. Και εδώ, οποιοδήποτε DNS-over-TLS / HTTPS αρχίζει να αιωρείται πάνω από το κεφάλι σας, αλλά μπορούμε (προς το παρόν) να ελέγξουμε αυτό το τμήμα στον πελάτη - είτε να το απενεργοποιήσουμε είτε να χρησιμοποιήσουμε τον δικό σας διακομιστή για DoT / DoH.

Πώς να υποκλέψει DNS;

Και εδώ, επίσης, μπορεί να υπάρχουν διάφορες προσεγγίσεις.

Υποκλοπή κίνησης DNS μέσω PCAP ή NFLOG
Και οι δύο αυτές μέθοδοι υποκλοπής εφαρμόζονται στο βοηθητικό πρόγραμμα sidmat. Αλλά δεν υποστηρίζεται εδώ και πολύ καιρό και η λειτουργικότητα είναι πολύ πρωτόγονη, επομένως πρέπει ακόμα να γράψετε μια ζώνη για αυτό.
Ανάλυση αρχείων καταγραφής διακομιστή DNS
Δυστυχώς, οι γνωστοί σε εμένα αναδρομείς δεν μπορούν να καταγράφουν απαντήσεις, αλλά μόνο αιτήματα. Κατ 'αρχήν, αυτό είναι λογικό, δεδομένου ότι, σε αντίθεση με τα αιτήματα, οι απαντήσεις έχουν πολύπλοκη δομή και είναι δύσκολο να γραφτούν σε μορφή κειμένου.
DNSTap
Ευτυχώς, πολλά από αυτά υποστηρίζουν ήδη το DNSTap για αυτόν τον σκοπό.

Τι είναι το DNSTap;

Είναι ένα πρωτόκολλο πελάτη-διακομιστή που βασίζεται σε Protocol Buffers και Frame Stream για μεταφορά από έναν διακομιστή DNS σε έναν συλλέκτη δομημένων ερωτημάτων και απαντήσεων DNS. Ουσιαστικά, ο διακομιστής DNS μεταδίδει μεταδεδομένα ερωτημάτων και απαντήσεων (τύπος μηνύματος, IP πελάτη/διακομιστή, κ.λπ.) καθώς και πλήρη μηνύματα DNS στη (δυαδική) μορφή στην οποία συνεργάζεται μαζί τους μέσω του δικτύου.

Είναι σημαντικό να κατανοήσουμε ότι στο παράδειγμα DNSTap, ο διακομιστής DNS λειτουργεί ως πελάτης και ο συλλέκτης ως διακομιστής. Δηλαδή, ο διακομιστής DNS συνδέεται με τον συλλέκτη και όχι το αντίστροφο.

Σήμερα το DNSTap υποστηρίζεται σε όλους τους δημοφιλείς διακομιστές DNS. Αλλά, για παράδειγμα, το BIND σε πολλές διανομές (όπως το Ubuntu LTS) δημιουργείται συχνά για κάποιο λόγο χωρίς την υποστήριξή του. Ας μην ασχοληθούμε λοιπόν με την επανασυναρμολόγηση, αλλά ας πάρουμε έναν ελαφρύτερο και ταχύτερο αναδρομέα - Χωρίς περιορισμούς.

Πώς να πιάσω το DNSTap;

Υπάρχει μερικοί αριθμός Βοηθητικά προγράμματα CLI για εργασία με μια ροή συμβάντων DNSTap, αλλά δεν είναι κατάλληλα για την επίλυση του προβλήματός μας. Ως εκ τούτου, αποφάσισα να εφεύρω το δικό μου ποδήλατο που θα κάνει ό,τι είναι απαραίτητο: dnstap-bgp

Αλγόριθμος εργασίας:

Κατά την εκκίνηση, φορτώνει μια λίστα τομέων από ένα αρχείο κειμένου, τους αντιστρέφει (habr.com -> com.habr), εξαιρεί διακεκομμένες γραμμές, διπλότυπα και υποτομείς (δηλ. εάν η λίστα περιέχει habr.com και www.habr.com, θα φορτωθεί μόνο το πρώτο) και δημιουργεί ένα δέντρο προθέματος για γρήγορη αναζήτηση σε αυτήν τη λίστα
Λειτουργώντας ως διακομιστής DNSTap, περιμένει για σύνδεση από διακομιστή DNS. Κατ 'αρχήν, υποστηρίζει υποδοχές UNIX και TCP, αλλά οι διακομιστές DNS που γνωρίζω μπορούν να χρησιμοποιούν μόνο υποδοχές UNIX
Τα εισερχόμενα πακέτα DNSTap αποσυναρμολογούνται πρώτα σε μια δομή Protobuf και, στη συνέχεια, το ίδιο το δυαδικό μήνυμα DNS, που βρίσκεται σε ένα από τα πεδία Protobuf, αναλύεται στο επίπεδο των εγγραφών DNS RR
Ελέγχεται εάν ο αιτούμενος κεντρικός υπολογιστής (ή ο γονικός τομέας του) βρίσκεται στη λίστα φορτωμένων, εάν όχι, η απάντηση αγνοείται
Από την απάντηση επιλέγονται μόνο RR A/AAAA/CNAME και εξάγονται από αυτές οι αντίστοιχες διευθύνσεις IPv4/IPv6
Οι διευθύνσεις IP αποθηκεύονται στην κρυφή μνήμη με ρυθμιζόμενο TTL και διαφημίζονται σε όλα τα διαμορφωμένα ομότιμα BGP
Όταν λαμβάνετε μια απάντηση που δείχνει σε μια ήδη αποθηκευμένη στην κρυφή μνήμη IP, το TTL ενημερώνεται
Μετά τη λήξη του TTL, η καταχώρηση αφαιρείται από την κρυφή μνήμη και από τις ανακοινώσεις BGP

Πρόσθετη λειτουργικότητα:

Ξαναδιάβασμα της λίστας των τομέων από το SIGHUP
Διατήρηση της προσωρινής μνήμης σε συγχρονισμό με άλλες παρουσίες dnstap-bgp μέσω HTTP/JSON
Αντιγράψτε τη μνήμη cache στο δίσκο (στη βάση δεδομένων BoltDB) για να επαναφέρετε τα περιεχόμενά της μετά από επανεκκίνηση
Υποστήριξη για εναλλαγή σε διαφορετικό χώρο ονομάτων δικτύου (γιατί αυτό χρειάζεται θα περιγραφεί παρακάτω)
Υποστήριξη IPv6

Περιορισμοί:

Οι τομείς IDN δεν υποστηρίζονται ακόμη
Λίγες ρυθμίσεις BGP

συγκέντρωσα RPM και DEB πακέτα για εύκολη εγκατάσταση. Θα πρέπει να λειτουργεί σε όλα τα σχετικά πρόσφατα λειτουργικά συστήματα με systemd. δεν έχουν εξαρτήσεις.

Το σχέδιο

Λοιπόν, ας αρχίσουμε να συναρμολογούμε όλα τα εξαρτήματα μαζί. Ως αποτέλεσμα, θα πρέπει να λάβουμε κάτι σαν αυτή την τοπολογία δικτύου:

Η λογική της εργασίας, νομίζω, είναι ξεκάθαρη από το διάγραμμα:

Ο πελάτης έχει διαμορφώσει τον διακομιστή μας ως DNS και τα ερωτήματα DNS πρέπει επίσης να περάσουν από το VPN. Αυτό είναι απαραίτητο ώστε ο πάροχος να μην μπορεί να χρησιμοποιήσει την παρακολούθηση DNS για αποκλεισμό.
Κατά το άνοιγμα του ιστότοπου, ο πελάτης στέλνει ένα ερώτημα DNS όπως "τι είναι οι IP του xxx.org"
Χωρίς περιορισμούς επιλύει το xxx.org (ή το παίρνει από την κρυφή μνήμη) και στέλνει μια απάντηση στον πελάτη "Το xxx.org έχει τέτοια IP", αντιγράφοντας το παράλληλα μέσω DNSTap
dnstap-bgp ανακοινώνει αυτές τις διευθύνσεις στο ΠΟΥΛΙ μέσω BGP εάν ο τομέας βρίσκεται στη λίστα αποκλεισμένων
ΠΟΥΛΙ διαφημίζει μια διαδρομή προς αυτές τις IP με next-hop self δρομολογητής πελάτη
Τα επόμενα πακέτα από τον πελάτη σε αυτές τις IP περνούν μέσα από τη σήραγγα

Στον διακομιστή, για διαδρομές σε αποκλεισμένους ιστότοπους, χρησιμοποιώ έναν ξεχωριστό πίνακα μέσα στο BIRD και δεν τέμνεται με το λειτουργικό σύστημα με κανέναν τρόπο.

Αυτό το σχήμα έχει ένα μειονέκτημα: το πρώτο πακέτο SYN από τον πελάτη, πιθανότατα, θα έχει χρόνο να φύγει μέσω του εγχώριου παρόχου. το δρομολόγιο δεν ανακοινώνεται άμεσα. Και εδώ είναι δυνατές επιλογές ανάλογα με τον τρόπο με τον οποίο ο πάροχος κάνει τον αποκλεισμό. Αν απλώς ρίξει την κυκλοφορία, τότε δεν υπάρχει πρόβλημα. Και αν το ανακατευθύνει σε κάποιο DPI, τότε (θεωρητικά) είναι πιθανά τα ειδικά εφέ.

Είναι επίσης πιθανό οι πελάτες να μην σέβονται τα θαύματα του DNS TTL, γεγονός που μπορεί να κάνει τον πελάτη να χρησιμοποιήσει κάποιες παλιές εγγραφές από την σάπια κρυφή μνήμη του αντί να ρωτήσει το Unbound.

Στην πράξη, ούτε το πρώτο ούτε το δεύτερο μου δημιούργησαν προβλήματα, αλλά τα χιλιόμετρα σας μπορεί να διαφέρουν.

Συντονισμός διακομιστή

Για ευκολία στην κύλιση, έγραψα ρόλος για τον Ansible. Μπορεί να διαμορφώσει τόσο διακομιστές όσο και πελάτες με βάση το Linux (σχεδιασμένο για διανομές που βασίζονται σε deb). Όλες οι ρυθμίσεις είναι αρκετά προφανείς και έχουν ρυθμιστεί απογραφή.yml. Αυτός ο ρόλος έχει αποκοπεί από το μεγάλο μου βιβλίο, επομένως μπορεί να περιέχει σφάλματα - pull requests καλώς ήρθες 🙂

Ας περάσουμε από τα κύρια στοιχεία.

Bgp

Η εκτέλεση δύο δαιμόνων BGP στον ίδιο κεντρικό υπολογιστή έχει ένα θεμελιώδες πρόβλημα: το BIRD δεν θέλει να ρυθμίσει το BGP peering με τον localhost (ή οποιαδήποτε τοπική διεπαφή). Από τη λέξη καθόλου. Το γκουγκλάρισμα και η ανάγνωση λιστών αλληλογραφίας δεν βοήθησαν, ισχυρίζονται ότι αυτό οφείλεται στο σχεδιασμό. Ίσως υπάρχει κάποιος τρόπος, αλλά δεν τον βρήκα.

Μπορείτε να δοκιμάσετε έναν άλλο δαίμονα BGP, αλλά μου αρέσει το BIRD και χρησιμοποιείται παντού από εμένα, δεν θέλω να παράγω οντότητες.

Επομένως, έκρυψα το dnstap-bgp μέσα στον χώρο ονομάτων του δικτύου, ο οποίος συνδέεται με τη ρίζα μέσω της διεπαφής veth: είναι σαν ένας σωλήνας, τα άκρα του οποίου προεξέχουν σε διαφορετικούς χώρους ονομάτων. Σε κάθε ένα από αυτά τα άκρα, κρεμάμε ιδιωτικές διευθύνσεις IP p2p που δεν υπερβαίνουν τον κεντρικό υπολογιστή, ώστε να μπορούν να είναι οτιδήποτε. Αυτός είναι ο ίδιος μηχανισμός που χρησιμοποιείται για την πρόσβαση σε διαδικασίες στο εσωτερικό αγαπητό σε όλους Docker και άλλα εμπορευματοκιβώτια.

Για αυτό γράφτηκε γραφή και η λειτουργικότητα που περιγράφηκε ήδη παραπάνω για να σύρετε τον εαυτό σας από τα μαλλιά σε άλλο χώρο ονομάτων προστέθηκε στο dnstap-bgp. Εξαιτίας αυτού, πρέπει να εκτελεστεί ως root ή να εκδοθεί στο δυαδικό αρχείο CAP_SYS_ADMIN μέσω της εντολής setcap.

Παράδειγμα σεναρίου για τη δημιουργία χώρου ονομάτων

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

πουλί.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

Από προεπιλογή, στο Ubuntu, το δυαδικό Unbound συσφίγγεται από το προφίλ AppArmor, το οποίο του απαγορεύει τη σύνδεση σε όλα τα είδη υποδοχών DNSTap. Μπορείτε είτε να διαγράψετε αυτό το προφίλ είτε να το απενεργοποιήσετε:

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

Αυτό μάλλον θα πρέπει να προστεθεί στο playbook. Είναι ιδανικό, φυσικά, να διορθώσω το προφίλ και να εκδίδω τα απαραίτητα δικαιώματα, αλλά ήμουν πολύ τεμπέλης.

αδέσμευτο.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

Λήψη και επεξεργασία λιστών

Σενάριο για λήψη και επεξεργασία λίστας διευθύνσεων IP
Κατεβάζει τη λίστα, συνοψίζει στο πρόθεμα pfx. Σε dont_add и dont_summarize μπορείτε να πείτε στις IP και τα δίκτυα να παραλείψουν ή να μην συνοψίσουν. το χρειαζόμουν. το υποδίκτυο του VPS μου ήταν στη λίστα αποκλεισμού 🙂

Το αστείο είναι ότι το RosKomSvoboda API μπλοκάρει αιτήματα με τον προεπιλεγμένο παράγοντα χρήστη Python. Φαίνεται ότι το σενάριο-παιδί το κατάλαβε. Επομένως, το αλλάζουμε σε Ognelis.

Μέχρι στιγμής, λειτουργεί μόνο με IPv4. το μερίδιο του IPv6 είναι μικρό, αλλά θα είναι εύκολο να διορθωθεί. Εκτός αν πρέπει να χρησιμοποιήσετε και το 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)

Σενάριο για ενημέρωση
Το τρέχω στο στέμμα μια φορά την ημέρα, ίσως αξίζει να το τραβάω κάθε 4 ώρες. αυτή, κατά τη γνώμη μου, είναι η περίοδος ανανέωσης που απαιτεί το RKN από τους παρόχους. Επιπλέον, έχουν κάποιο άλλο υπερ-επείγον μπλοκάρισμα, το οποίο μπορεί να φτάσει πιο γρήγορα.

Κάνει τα εξής:

Εκτελεί το πρώτο σενάριο και ενημερώνει τη λίστα των διαδρομών (rkn_routes.list) για BIRD
Επαναφόρτωση BIRD
Ενημερώνει και καθαρίζει τη λίστα των τομέων για dnstap-bgp
Επαναφόρτωση dnstap-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

Γράφτηκαν χωρίς πολλή σκέψη, οπότε αν δείτε κάτι που μπορεί να βελτιωθεί - προχωρήστε.

Ρύθμιση πελάτη

Εδώ θα δώσω παραδείγματα για δρομολογητές Linux, αλλά στην περίπτωση των Mikrotik / Cisco θα πρέπει να είναι ακόμα πιο εύκολο.

Αρχικά, ρυθμίσαμε το BIRD:

πουλί.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;
}

Έτσι, θα συγχρονίσουμε τις διαδρομές που λαμβάνονται από το BGP με τον πίνακα δρομολόγησης του πυρήνα με αριθμό 222.

Μετά από αυτό, αρκεί να ζητήσετε από τον πυρήνα να κοιτάξει αυτό το πιάτο πριν κοιτάξει το προεπιλεγμένο:

# 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

Όλα, απομένει να ρυθμίσετε τις παραμέτρους του DHCP στο δρομολογητή για τη διανομή της διεύθυνσης IP της σήραγγας του διακομιστή ως DNS και το σχήμα είναι έτοιμο.

Περιορισμοί

Με τον τρέχοντα αλγόριθμο για τη δημιουργία και την επεξεργασία της λίστας των τομέων, περιλαμβάνει, μεταξύ άλλων, youtube.com και τα CDN του.

Και αυτό οδηγεί στο γεγονός ότι όλα τα βίντεο θα περάσουν από το VPN, το οποίο μπορεί να φράξει ολόκληρο το κανάλι. Ίσως αξίζει να συντάξουμε μια λίστα με δημοφιλείς τομείς-εξαιρέσεις που μπλοκάρουν το RKN προς το παρόν, τα κότσια είναι λεπτά. Και παραλείψτε τα κατά την ανάλυση.

Συμπέρασμα

Η περιγραφόμενη μέθοδος σάς επιτρέπει να παρακάμψετε σχεδόν κάθε αποκλεισμό που εφαρμόζουν επί του παρόντος οι πάροχοι.

Κατ 'αρχήν, dnstap-bgp μπορεί να χρησιμοποιηθεί για οποιονδήποτε άλλο σκοπό όπου απαιτείται κάποιο επίπεδο ελέγχου κυκλοφορίας με βάση το όνομα τομέα. Απλώς έχετε κατά νου ότι στην εποχή μας, χίλιοι ιστότοποι μπορούν να κρέμονται στην ίδια διεύθυνση IP (πίσω από κάποιο Cloudflare, για παράδειγμα), επομένως αυτή η μέθοδος έχει μάλλον χαμηλή ακρίβεια.

Αλλά για τις ανάγκες παράκαμψης κλειδαριών, αυτό είναι αρκετά.

Προσθήκες, επεξεργασίες, αιτήματα έλξης - καλώς ήρθατε!

Πηγή: www.habr.com

Παράκαμψη αποκλεισμού ILV με DNSTAp και BGP