Skłoniło mnie to do tego wpisu .
Cytuję to tutaj:
Dziś 18: 53
Byłem dzisiaj zadowolony z dostawcy. Wraz z aktualizacją systemu blokowania stron zablokowano jego pocztę mail.ru.Od rana dzwonię do pomocy technicznej, ale nic nie mogą zrobić. Dostawca jest mały i najwyraźniej dostawcy wyższej rangi go blokują. Zauważyłem też spowolnienie otwierania wszystkich stron, może zainstalowali jakiś krzywy DLP? Wcześniej nie było problemów z dostępem. Zagłada RuNet dzieje się na moich oczach...
Fakt jest taki, że wygląda na to, że jesteśmy tym samym dostawcą :)
I rzeczywiście, Prawie odgadłem przyczynę problemów z mail.ru (chociaż przez długi czas nie wierzyliśmy w coś takiego).
Poniższe informacje zostaną podzielone na dwie części:
- przyczyny naszych obecnych problemów z mail.ru i ekscytujące poszukiwanie ich znalezienia
- istnienie ISP w dzisiejszych realiach, stabilność suwerennego RuNet.
Problemy z dostępnością w mail.ru
Och, to dość długa historia.
Faktem jest, że aby zrealizować wymagania państwa (więcej szczegółów w drugiej części) zakupiliśmy, skonfigurowaliśmy i zainstalowaliśmy pewien sprzęt - zarówno do filtrowania zabronionych zasobów, jak i do wdrażania abonentów.
Jakiś czas temu w końcu przebudowaliśmy rdzeń sieci w taki sposób, aby cały ruch abonencki przechodził przez ten sprzęt ściśle w dobrym kierunku.
Kilka dni temu włączyliśmy na nim zabronione filtrowanie (pozostawiając stary system działający) - wszystko wydawało się działać dobrze.
Następnie stopniowo zaczęto włączać NAT na tym sprzęcie dla różnych części abonentów. Wyglądało na to, że wszystko poszło dobrze.
Ale dzisiaj, po włączeniu NAT na sprzęcie dla kolejnej części abonentów, od samego rana spotkaliśmy się z pokaźną liczbą skarg na niedostępność lub częściową dostępność i inne zasoby grupy Mail Ru.
Zaczęli sprawdzać: coś gdzieś czasami, sporadycznie wysyła w odpowiedzi na prośby kierowane wyłącznie do sieci mail.ru. Co więcej, wysyła błędnie wygenerowany (bez ACK), oczywiście sztuczny TCP RST. Tak to wyglądało:
Naturalnie pierwsze myśli dotyczyły nowego sprzętu: fatalne DPI, brak zaufania do niego, nigdy nie wiadomo, co potrafi - wszak TCP RST to dość powszechna rzecz wśród narzędzi blokujących.
Założenie Wysunęliśmy również pomysł, że ktoś „przełożony” filtruje, ale natychmiast go odrzuciliśmy.
Po pierwsze, mamy na tyle rozsądne uplinki, żebyśmy nie musieli tak cierpieć :)
Po drugie, jesteśmy połączeni z kilkoma w Moskwie i przez nie przechodzi ruch do mail.ru - i nie mają oni ani obowiązków, ani żadnego innego powodu, aby filtrować ruch.
Kolejną połowę dnia spędziliśmy na tym, co zwykle nazywa się szamanizmem - razem ze sprzedawcą sprzętu, za co im dziękujemy, nie poddali się :)
- filtrowanie zostało całkowicie wyłączone
- NAT został wyłączony przy użyciu nowego schematu
- testowy komputer PC umieszczono w oddzielnej izolowanej puli
- Adresowanie IP zostało zmienione
Po południu przydzielono maszynę wirtualną, która podłączyła się do sieci według schematu zwykłego użytkownika, a przedstawiciele dostawcy otrzymali dostęp do niej i sprzętu. Szamanizm trwał :)
W końcu przedstawiciel producenta z przekonaniem stwierdził, że sprzęt nie ma z tym nic wspólnego: te pierwsze pochodzą skądś wyżej.
OperacjaW tym miejscu ktoś może powie: ale dużo łatwiej było zrobić zrzut nie z testowego peceta, a z autostrady powyżej DPI?
Nie, niestety zrobienie zrzutu (a nawet po prostu utworzenie kopii lustrzanej) 40+Gbps nie jest wcale trywialne.
Po tym wieczorem nie pozostało już nic innego jak wrócić do założenia o dziwnej filtracji gdzieś na górze.
Sprawdziłem, przez który IX przechodzi teraz ruch do sieci MRG i po prostu anulowałem sesje bgp do niego. I – oto i oto! - wszystko od razu wróciło do normy 🙁
Z jednej strony szkoda, że cały dzień spędziliśmy na szukaniu problemu, mimo że został on rozwiązany w pięć minut.
Z drugiej strony:
— w mojej pamięci jest to rzecz bezprecedensowa. Jak już pisałem powyżej - IX naprawdę nie ma sensu filtrować ruchu tranzytowego. Zwykle mają setki gigabitów/terabitów na sekundę. Po prostu do niedawna nie mogłem sobie wyobrazić czegoś takiego.
— niezwykle szczęśliwy zbieg okoliczności: nowy, złożony sprzęt, któremu nie można ufać szczególnie i nie wiadomo, czego można się po nim spodziewać — dostosowany specjalnie do blokowania zasobów, w tym TCP RST
NOC tej centrali internetowej szuka obecnie problemu. Według nich (a ja im wierzę) nie mają żadnego specjalnie rozmieszczonego systemu filtracji. Ale dzięki Bogu, dalsze poszukiwania nie są już naszym problemem :)
To była taka mała próba usprawiedliwienia się, proszę o zrozumienie i wybaczenie :)
PS: Celowo nie wymieniam producenta DPI/NAT ani IX (właściwie nie mam nawet do nich żadnych specjalnych skarg, najważniejsze jest, aby zrozumieć, co to było)
Dzisiejsza (a także wczorajsza i przedwczorajsza) rzeczywistość z punktu widzenia dostawcy Internetu
Ostatnie tygodnie spędziłem na znacznej przebudowie rdzenia sieci, wykonując szereg manipulacji „dla zysku”, co wiąże się z ryzykiem znaczącego wpływu na ruch użytkowników na żywo. Biorąc pod uwagę cele, rezultaty i konsekwencje tego wszystkiego, moralnie jest to dość trudne. Zwłaszcza – po raz kolejny słuchając pięknych przemówień na temat ochrony stabilności Runeta, suwerenności itp. i tak dalej.
W tej części postaram się opisać „ewolucję” rdzenia sieci typowego dostawcy usług internetowych na przestrzeni ostatnich dziesięciu lat.
Dziesięć lat temu.
W tych błogosławionych czasach rdzeń sieci dostawcy może być tak prosty i niezawodny jak korek uliczny:
Na tym bardzo, bardzo uproszczonym obrazie nie ma łączy trunkingowych, ringów ani routingu IP/mpls.
Jego istotą jest to, że ruch użytkowników ostatecznie docierał do przełączania na poziomie jądra – skąd trafiał , skąd z reguły wracają do przełączania rdzenia, a następnie „na zewnątrz” - przez jedną lub więcej bram granicznych do Internetu.
Taki schemat jest bardzo, bardzo łatwy do zarezerwowania zarówno na L3 (routing dynamiczny), jak i na L2 (MPLS).
Możesz zainstalować N+1 dowolnego elementu: serwerów dostępowych, przełączników, granic - i w ten czy inny sposób zarezerwować je na potrzeby automatycznego przełączania awaryjnego.
Po kilku latach Dla wszystkich w Rosji stało się jasne, że nie da się już tak żyć: pilnie należy chronić dzieci przed zgubnym wpływem Internetu.
Istniała pilna potrzeba znalezienia sposobów filtrowania ruchu użytkowników.
Istnieją tutaj różne podejścia.
W niezbyt dobrym przypadku coś zostaje umieszczone „w luce”: pomiędzy ruchem użytkowników a Internetem. Ruch przechodzący przez to „coś” jest analizowany i w stronę abonenta wysyłany jest np. fałszywy pakiet z przekierowaniem.
W nieco lepszym przypadku – jeśli natężenie ruchu na to pozwala – możesz zrobić małą sztuczkę swoim uszom: wysłać do filtrowania tylko ruch pochodzący od użytkowników tylko na te adresy, które wymagają filtrowania (w tym celu możesz albo pobrać adresy IP tam określone z rejestru, lub dodatkowo rozwiązać istniejące domeny w rejestrze).
Kiedyś w tym celu napisałem prosty - choć nawet nie śmiem go tak nazywać. Jest to bardzo proste i mało produktywne - pozwoliło jednak nam i dziesiątkom (jeśli nie setkom) innych dostawców nie od razu wydać miliony na przemysłowe systemy DPI, ale dało kilka dodatkowych lat czasu.
Nawiasem mówiąc, o ówczesnym i obecnym DPISwoją drogą, wielu, którzy zakupili dostępne wówczas na rynku układy DPI, już je wyrzuciło. Cóż, nie są do tego przeznaczone: setki tysięcy adresów, dziesiątki tysięcy adresów URL.
A jednocześnie krajowi producenci bardzo mocno weszli na ten rynek. Nie mówię o komponencie sprzętowym - tutaj wszystko jest jasne dla wszystkich, ale oprogramowanie - to, co najważniejsze, że ma DPI - jest być może dzisiaj, jeśli nie najbardziej zaawansowane na świecie, to z pewnością a) rozwija się skokowo, oraz b) w cenie produktu pudełkowego - po prostu nieporównywalnej z zagraniczną konkurencją.
Chciałbym być dumny, ale trochę smutny =)
Teraz wszystko wyglądało tak:
Za kilka kolejnych lat wszyscy mieli już audytorów; Zasobów w rejestrze było coraz więcej. W przypadku niektórych starszych urządzeń (na przykład Cisco 7600) schemat „filtrowania bocznego” po prostu nie miał zastosowania: liczba tras na 76 platformach jest ograniczona do około dziewięćset tysięcy, podczas gdy liczba samych tras IPv4 zbliża się obecnie do 800 tysiąc. A jeśli to także ipv6... A także... ile tego jest? 900000 XNUMX indywidualnych adresów w zakazie RKN? =)
Ktoś przeszedł na schemat z dublowaniem całego ruchu szkieletowego na serwer filtrujący, który powinien przeanalizować cały przepływ i w przypadku wykrycia czegoś złego wysłać RST w obie strony (nadawca i odbiorca).
Jednak im większy ruch, tym mniej odpowiedni jest ten schemat. Jeśli wystąpi najmniejsze opóźnienie w przetwarzaniu, ruch lustrzany po prostu przemknie niezauważony, a dostawca otrzyma dokładny raport.
Coraz więcej dostawców jest zmuszonych do instalowania na autostradach systemów DPI o różnym stopniu niezawodności.
Rok lub dwa lata temu według plotek prawie cała FSB zaczęła domagać się faktycznej instalacji sprzętu (wcześniej większość dostawców zarządzała za zgodą władz planu SORM - plan działań operacyjnych na wypadek konieczności znalezienia czegoś gdzieś)
Oprócz pieniędzy (niezbyt wygórowanych, ale wciąż milionów) SORM wymagał wielu innych manipulacji w sieci.
- SORM musi zobaczyć „szare” adresy użytkowników przed translacją NAT
- SORM ma ograniczoną liczbę interfejsów sieciowych
Dlatego w szczególności musieliśmy mocno przebudować fragment jądra - po prostu po to, aby zebrać gdzieś w jednym miejscu ruch użytkowników do serwerów dostępowych. Aby odzwierciedlić to w SORM za pomocą kilku linków.
Oznacza to, że w dużym uproszczeniu było (po lewej) vs stało się (po prawej):
Teraz Większość dostawców wymaga także implementacji SORM-3 – która obejmuje m.in. logowanie transmisji nat.
W tym celu musieliśmy także dodać do powyższego schematu osobny sprzęt do NAT (dokładnie to omówiliśmy w pierwszej części). Ponadto dodaj w określonej kolejności: ponieważ SORM musi „widzieć” ruch przed translacją adresów, ruch musi przebiegać ściśle w następujący sposób: użytkownicy -> przełączanie, jądro -> serwery dostępu -> SORM -> NAT -> przełączanie, jądro - > Internetu. Aby to zrobić, dla zysku musieliśmy dosłownie „skręcić” przepływ ruchu w drugą stronę, co również było dość trudne.
Podsumowując: w ciągu ostatnich dziesięciu lat podstawowa konstrukcja przeciętnego dostawcy stała się wielokrotnie bardziej złożona, a liczba dodatkowych punktów awarii (zarówno w postaci sprzętu, jak i pojedynczych linii rozdzielczych) znacznie wzrosła. Właściwie już samo wymaganie „widzieć wszystko” implikuje sprowadzenie tego „wszystko” do jednego punktu.
Myślę, że można to dość przejrzyście ekstrapolować na obecne inicjatywy mające na celu suwerenizację Runeta, jego ochronę, stabilizację i ulepszenie :)
A Yarovaya wciąż jest przed nami.
Źródło: www.habr.com