Zainspirował mnie do tego posta .
Przytaczam go tutaj:
dziś o 18:53
Dzisiaj dostawca internetowy mnie zaskoczył. Wraz z aktualizacją systemu blokowania stron, mail.ru znalazł się na czarnej liście. Od rana dzwonię na wsparcie techniczne, nic nie mogą zrobić. Dostawca jest mały, a najwyraźniej blokują ich więksi dostawcy. Zauważyłem też spowolnienie otwierania wszystkich stron, może nałożyli jakieś dziwne DLP? Wcześniej nie było żadnych problemów z dostępem. Zniszczenie Runetu dzieje się na moich oczach…
Chodzi o to, że to chyba my jesteśmy tym dostawcą 🙁
I rzeczywiście, prawie zgadłem przyczynę problemów z mail.ru (choć długo w to wątpiliśmy).
Dalsza część będzie podzielona na dwie części:
- przyczyny naszych dzisiejszych problemów z mail.ru oraz fascynująca misja ich poszukiwania
- istnienie ISP w dzisiejszej rzeczywistości, stabilność suwerennego Runetu.
Problemy z dostępnością mail.ru
Och, to dość długa historia.
Chodzi o to, że w celu spełnienia wymogów państwowych (szczegóły w drugiej części) nabyliśmy, skonfigurowaliśmy, zainstalowaliśmy pewne urządzenie — zarówno do filtracji zakazanych zasobów, jak i do realizacji abonentów.
Jakiś czas temu w końcu przebudowaliśmy rdzeń sieci w taki sposób, aby cały ruch abonentów przechodził przez to urządzenie w ściśle określonym kierunku.
Kilka dni temu włączyliśmy na nim filtrację zakazanych treści (jednocześnie pozostawiając w działaniu starą systematyzację) — na pierwszy rzut oka wszystko poszło dobrze.
Następnie stopniowo zaczęliśmy włączać NAT dla różnych grup abonentów na tym urządzeniu. Na pierwszy rzut oka również wszystko wydawało się działać dobrze.
Jednak dzisiaj, włączając na urządzeniu NAT dla kolejnej grupy abonentów — od samego rana napotkaliśmy znacznie więcej skarg na niedostępność lub częściową dostępność i innych zasobów Mail Ru Group.
Zaczęliśmy sprawdzać: coś gdzieś czasami, rzadko wysyła w odpowiedzi na zapytania wyłącznie do sieci mail.ru. Co więcej — wysyła niepoprawnie wygenerowany (bez ACK), jednoznacznie sztuczny TCP RST. Tak to mniej więcej wyglądało:
Oczywiście, pierwsze myśli krążyły wokół nowego sprzętu: straszny DPI, brak zaufania do niego, co za dziwne rzeczy może zrobić — w końcu TCP RST to dość powszechne zjawisko w narzędziach blokujących.
Przypuszczenie o tym, że filtruje ktoś „wyższy”, również zgłaszaliśmy — ale zaraz to odrzuciliśmy.
Po pierwsze, mamy wystarczająco przyzwoite uplinki, żeby nie mieć takich problemów 🙂
Po drugie, jesteśmy podłączeni do kilku w Moskwie, a ruch do mail.ru przechodzi właśnie przez nie — a oni nie mają ani obowiązków, ani żadnego innego motywu, żeby filtrować ruch.
Kolejna połowa dnia została poświęcona na to, co zazwyczaj nazywa się szamanizmem — razem z dostawcą sprzętu, za co im dziękujemy, nie zostawili nas w trudnej sytuacji 🙂
- całkowicie wyłączono filtrację
- wyłączono NAT według nowego schematu
- testowy komputer był przeniesiony do osobnej izolowanej puli
- zmieniła się adresacja IP
W drugiej połowie dnia przydzielono wirtualną maszynę, która wychodziła do sieci według schematu zwykłego użytkownika, a do niej oraz do sprzętu uzyskali dostęp przedstawiciele dostawcy. Szamanizm trwał 🙂
Ostatecznie przedstawiciel dostawcy stanowczo stwierdził, że sprzęt nie ma z tym nic wspólnego: rst'y przychodzą skądś z góry.
UwagaW tym miejscu ktoś może powiedzieć: ależ znacznie łatwiej było zrobić zrzut nie z testowego komputera, a z magistrali powyżej DPI?
Niestety wykonanie zrzutu (a nawet po prostu odmirrorowanie) 40+gbps — wcale nie jest trywialne.
Po tym, już wieczorem — nie było nic innego, jak wrócić do przypuszczenia o dziwnej filtracji gdzieś wyżej.
Sprawdziłem, przez jaki IX obecnie przechodzi ruch do sieci MRG i po prostu wygasiłem sesje BGP. I — o cud! — wszystko natychmiast się unormowało 🙁
Z jednej strony — bardzo szkoda, że na poszukiwanie problemu poświęcono cały dzień, podczas gdy rozwiązał się w pięć minut.
Z drugiej strony:
— w mojej pamięci to precedensowa sytuacja. Jak już pisałem wcześniej — IX'om naprawdę nie ma sensu filtrować ruchu tranzytowego. Zazwyczaj mają setki gigabitów / terabitów na sekundę. Po prostu do ostatniej chwili nie mogłem sobie poważnie tego wyobrazić.
— niesamowicie szczęśliwy zbieg okoliczności: nowy skomplikowany sprzęt, któremu nie ufamy zbytnio i nie wiadomo, czego można się po nim spodziewać — zaprojektowany właśnie do blokowania zasobów, w tym TCP RST'ami.
Obecnie NOC tej giełdy internetowej poszukuje problemu. Według ich zapewnień (i wierzę im) nie mają żadnego specjalnie uruchomionego systemu filtrowania. Jednak, dzięki niebu, dalsza przygoda — już nie jest naszym problemem 🙂
To była niewielka próba usprawiedliwienia, prosimy o zrozumienie i wybaczenie 🙂
P.S.: celowo nie podaję producenta DPI/NAT ani IX (właściwie to nie mam do nich szczególnych pretensji, głównie chodzi o to, żeby zrozumieć, co się stało)
Dzisiejsza (a także wczorajsza i przedwczorajsza) rzeczywistość z perspektywy dostawcy internetu
Ostatnie tygodnie spędziłem na znacznym przekształcaniu rdzenia sieci, wykonując mnóstwo manipulacji „na żywo”, z ryzykiem znacznego zakłócenia ruchu użytkowników. Biorąc pod uwagę cele, wyniki i konsekwencje tego wszystkiego — moralnie to wszystko jest dość ciężkie. Szczególnie — słuchając po raz kolejny pięknych przemówień o ochronie stabilności runetu, suwerenności itd.
W tej sekcji postaram się opisać „ewolucję” rdzenia sieci typowego dostawcy internetu w ciągu ostatniej dekady.
Dziesięć lat temu.
W tych błogosławionych czasach rdzeń sieci dostawcy mógł być prosty i niezawodny jak korek:
Na tym bardzo, bardzo uproszczonym rysunku brakuje magistrali, ringów, routingu ip/mpls.
Jej istota polega na tym, że ruch użytkowników ostatecznie docierał do przełączania na poziomie rdzenia — skąd szedł do , skąd zazwyczaj — z powrotem do przełączania rdzenia, a następnie „na wyjście” — przez jeden lub kilka bramek w internet.
Taka схема jest bardzo, bardzo łatwa do zarezerwowania zarówno na L3 (dynamiczne routowanie), jak i na L2 (MPLS).
Można postawić N+1 czegokolwiek: serwerów dostępowych, przełączników, bram — i w ten czy inny sposób je zarezerwować dla automatycznego przełączania awaryjnego.
Po kilku latach wszystkim w Rosji stało się jasne, że dalej żyć tak nie można: konieczne jest pilne ochronienie dzieci przed zgubnym wpływem sieci.
Zaistniała konieczność pilnego znalezienia sposobów filtrowania ruchu użytkowników.
Istnieją różne podejścia.
W niezbyt dobrym przypadku — coś jest wstawiane „w przecięciu”: między ruchem użytkownika a internetem. Przechodzący przez to „coś” ruch jest analizowany i, na przykład, w kierunku abonenta wysyłany jest fałszywy pakiet z przekierowaniem.
W nieco lepszym przypadku — jeśli wolumeny ruchu na to pozwalają — można zastosować mały trik: filtrować tylko wychodzący ruch od użytkowników tylko na te adresy, które należy filtrować (można to zrobić na podstawie zapisanych w rejestrze adresów IP lub dodatkowo rozwiązywać istniejące w rejestrze domeny).
W swoim czasie napisałem prosty — chociaż nawet język nie chce go tak nazwać. Jest bardzo prosty i niezbyt wydajny — jednak zarówno nam, jak i dziesiątkom (jeśli nie setkom) innych dostawców pozwolił nie wydawać od razu milionów na przemysłowe systemy DPI, a zyskaliśmy dodatkowe lata czasu.
Przy okazji, o dawnych i obecnych systemach DPIWarto dodać, że wielu, którzy wtedy kupili dostępne na rynku systemy DPI — już je wyrzuciło. No bo nie były przystosowane do takich warunków: setki tysięcy adresów, dziesiątki tysięcy URL-i.
I jednocześnie, w tym rynku mocno wzrosło znaczenie krajowych producentów. Nie mówię tu o sprzęcie — to wszystko jasne, jednak oprogramowanie — to, co jest najważniejsze w DPI — mogłoby być, jeśli nie najnowocześniejsze na świecie, to na pewno a) rozwija się w zawrotnym tempie, i b) w cenie pudełkowej — po prostu nieporównywalne z zagranicznymi konkurentami.
Chciałbym się tym pochwalić, ale jest to trochę smutne =)
Teraz wszystko wyglądało tak:
Jeszcze po paru latach wszyscy mieli już rewizory; zasoby w rejestrze rosły w szybkim tempie. Dla niektórych starych urządzeń (na przykład Cisco 7600) schemat z „filtracją z boku” stawał się po prostu nieadekwatny: liczba tras na platformach 76 jest ograniczona do około dziewięciuset tysięcy, podczas gdy liczba tylko tras IPv4 dzisiaj zbliża się do 800 tysięcy. A jeśli jeszcze ipv6… A ile tam? 900000 oddzielnych adresów w banie rkn? =)
Niektórzy przeszli na schemat z mirrorowaniem całego ruchu magistralnego na serwer filtrujący, który miał analizować cały strumień i w przypadku wykrycia czegoś niepożądanego wysyłać w obie strony (do nadawcy i odbiorcy) RST.
Jednak im więcej ruchu, tym mniej taki schemat się sprawdza. Przy najmniejszym opóźnieniu w przetwarzaniu — mirrorowany ruch po prostu niepostrzeżenie przeleci w nicość, a dostawca dostanie protokół o karze.
Coraz więcej dostawców musi wprowadzać systemy DPI o różnych poziomach niezawodności w przekroju magistrali.
Rok lub dwa temu wg plotek, praktycznie wszyscy zaczęli wymagać od FSB rzeczywistego zainstalowania sprzętu (wcześniej większość dostawców ograniczała się do uzgodnień z organami planu SORM — planu działań operacyjnych na wypadek potrzeby znalezienia czegoś gdzieś)
Oprócz pieniędzy (nie aż tak, żeby były to kwoty astronomiczne, ale jednak — miliony), SORM wymagał od wielu kolejnych działań z siecią.
- SORMa musi widzieć «szare» adresy użytkowników przed translacją NAT
- SORMa ma ograniczoną liczbę interfejsów sieciowych
Dlatego musieliśmy między innymi znacznie przebudować część jądra — po to, aby zebrać gdzieś w jednym miejscu ruch użytkowników do serwerów dostępu. Aby odzwierciedlić go w SORM za pomocą kilku łączy.
To znaczy, bardzo uproszczono, było (po lewej) vs stało się (po prawej):
Teraz większość dostawców wymaga także wprowadzenia SORM-3 — który obejmuje również logowanie translacji NAT.
W tych celach musieliśmy dodać do powyższego schematu jeszcze oddzielny sprzęt dla NAT (jest to to, o czym mowa w pierwszej części). Co więcej, musieliśmy to dodać 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 -> internet. W tym celu musieliśmy dosłownie «odwrócić» strumienie ruchu w przeciwną stronę na żywo, co również było dość skomplikowane.
Podsumowując: przez dziesięć lat schemat jądra średniego dostawcy znacznie się skomplikował, a dodatkowe punkty awarii (zarówno w postaci sprzętu, jak i jednorodnych linii przełączających) znacznie przybyły. Właściwie samo w sobie wymaganie «widzieć wszystko» oznacza złożenie tego «wszystkiego» w jedną całość.
Myślę, że to można całkiem przejrzyście ekstrapolować na obecne inicjatywy dotyczące suwerenności Runetu, jego ochrony, stabilizacji i poprawy 🙂
A przed nami jeszcze Jarowa.
Źródło: habr.com
