Подвиг мене на цю посаду .
Наводжу його тут:
сьогодні о 18:53
Мене сьогодні порадував провайдер. Разом з оновленням системи блокування сайтів, у нього під бан потрапив поштовик mail.ru З ранку смикаю техпідтримку, нічого зробити не можуть. Провайдер маленький, і блокують мабуть вищі провайдери. Ще помітив уповільнення відкриття всіх сайтів, може, якесь криве DLP навісили? Раніше жодних проблем із доступом не було. Знищення рунету йде прямо на моїх очах.
Справа в тому, що, схоже, ми і є цей провайдер 🙁
І справді, майже вгадав із причиною проблем з mail.ru (хоча ми довго відмовлялися вірити в подібне).
Подальше буде поділено на дві частини:
- причини наших сьогоднішніх проблем з mail.ru та захоплюючий квест з їх пошуку
- існування ISP у сьогоднішніх реаліях, стабільність суверенного рунета.
Проблеми з доступністю mail.ru
О, це досить довга історія.
Справа в тому, що для реалізації вимог держави (докладніше у другій частині) нами було придбано, налаштовано, встановлено деяке обладнання як для фільтрації заборонених ресурсів, так і для здійснення абонентів.
Якийсь час тому ми нарешті перебудували ядро мережі таким чином, щоб весь трафік абонентів проходив через це обладнання строго в потрібному напрямку.
Декілька днів тому включили на ньому фільтрацію заборони (одночасно залишивши працювати і стару систему) — на вигляд все пройшло добре.
Далі поступово почали включати для різних частин абонентів NAT на цьому устаткуванні. На вигляд - теж все, начебто, пішло непогано.
Але сьогодні, включивши на обладнанні NAT для чергової частини абонентів, з самого ранку зіткнулися з пристойною кількістю скарг про недоступність або часткову доступність. та інших ресурсів Mail Ru Group.
Почали перевіряти: щось десь іноді, зрідка шле у відповідь на запити виключно до мереж mail.ru. Більше того - шле неправильно згенерований (без ACK), явно штучний TCP RST. Приблизно так це виглядало:
Природно, перші думки були про нове обладнання: страшний DPI, довіри до нього ніякого, мало що може вчути — адже TCP RST — це досить поширена штука серед засобів блокувань.
припущення про те, що фільтрує хтось «вищий», ми теж висунули — але одразу відкинули.
По-перше, у нас досить осудні аплінки, щоб подібним не страждати 🙂
По-друге, ми підключені до кількох в Москві, і трафік до mail.ru йде саме через них - а вже у них немає обов'язків, ні будь-якого іншого мотиву фільтрувати трафік.
Наступна половина дня була витрачена на те, що зазвичай називають шаманством — разом із вендором обладнання, за що їм дякую, не кинули 🙂
- повністю відключалася фільтрація
- відключався NAT за новою схемою
- тестовий ПК виносився в окремий ізольований пул
- змінювалася IP-адресація
У другій половині дня була виділена віртуалка, що виходить у мережу за схемою звичайного користувача, і до неї та обладнання було надано доступ представникам вендора. Шаманство тривало 🙂
Зрештою представник вендора впевнено заявив, що залізниця абсолютно точно ні до чого: rst`и приходять звідкись вище.
ПриміткаУ цьому місці хтось може заявити: але набагато простіше було зняти дамп не з тестового ПК, а з магістралі вище DPI?
Ні, на жаль, зняти дамп (і навіть просто відмирорити) 40 + gbps зовсім не тривіально.
Після цього вже ввечері не залишалося нічого іншого, як повернутися до припущення про дивну фільтрацію десь вище.
Я подивився, через який IX зараз ходить трафік до мереж МРГ та просто погасив до нього bgp-сесії. І — о диво! - Все негайно нормалізувалося 🙁
З одного боку, дуже шкода, що на пошук проблеми було витрачено весь день, хоча вирішувалася вона за п'ять хвилин.
З іншого боку:
- На моїй пам'яті це безпрецедентна штука. Як я вже писав вище - IX `ам дійсно немає жодного сенсу фільтрувати транзитний трафік. У них його зазвичай сотні гігабіт/терабіти за секунду. Я просто до останнього не міг серйозно припустити.
— неймовірно вдалий збіг обставин: нове складне залізо, якому немає особливої довіри і від якого незрозуміло, на що можна чекати — заточене саме під блокування ресурсів, у тому числі TCP RST`ами
На даний момент NOC цього internet exchange шукає проблему. За їх твердженням (і я їм вірю) ніякої спеціально розгорнутої системи фільтрації у них немає. Але, подяка небу, подальший квест уже не наша проблема 🙂
Це була невелика спроба виправдатися, просимо зрозуміти та пробачити 🙂
PS: я навмисно не називаю ні виробника DPI/NAT, ні IX (у мене, власне, навіть немає до них особливих претензій, головне зрозуміти, що це було)
Сьогоднішня (а також вчорашня та позавчорашня) реальність з погляду інтернет-провайдера
Останні тижні я провів, значно перебудовуючи ядро мережі, виробляючи купу маніпуляцій «наживу», з ризиком значно торкнутися живого користувальницького трафіку. З огляду на цілі, результати та наслідки всього цього морально все це досить важко. Особливо — в черговий раз слухаючи чудові промови про захист стабільності рунету, суверенітет тощо. і т.п.
У цьому розділі спробую розповісти «еволюцію» ядра мережі типового інтернет-провайдера за останній десяток років.
Десяток років тому.
У ті благословенні часи ядро провайдерської мережі могло бути простим і надійним, як корок:
На цій спрощеній картинці відсутні магістралі, кільця, ip/mpls маршрутизація.
Її суть у тому, що трафік користувачів зрештою приходив у комутацію рівня ядра — звідки йшов у , звідки, як правило - назад у комутацію ядра, і далі "на вихід" - через один або кілька border gateway в інтернет.
Подібна схема дуже легко резервується як на L3 (динамічної маршрутизацією), так і на L2 (MPLS).
Можна поставити N+1 будь-чого: серверів доступу, комутаторів, бордерів - і так чи інакше їх зарезервувати для автоматичного фейловера.
Через кілька років всім у Росії стало зрозуміло, що так далі жити не можна: необхідно терміново захистити дітей від згубного впливу мережі.
Виникла необхідність терміново шукати способи фільтрувати користувальницький трафік.
Тут є різні підходи.
У не дуже хорошому випадку — щось ставиться «в розріз»: між трафіком користувача та інтернетом. Трафік, що проходить через це, «щось» піддається аналізу і, наприклад, у бік абонента відправляється підроблений пакет з редиректом.
У трохи кращому випадку — якщо об'єми трафіку дозволяють — можна зробити невеликий фінт вухами: відправляти на фільтрацію тільки трафік, що виходить від користувачів, тільки на ті адреси, які необхідно фільтрувати (для цього можна або брати з реєстру вказані там IP-адреси, або додатково резолвувати наявні у реєстрі домени).
Свого часу для цих цілей я написав простенький — хоч навіть язик не повертається його так називати. Він дуже простий і не дуже продуктивний — однак і нам, і десяткам (якщо не сотням) інших провайдерів він дозволив не викладати одразу мільйони на промислові DPI-системи, а дав кілька років.
До речі, про тодішні та нинішні DPIДо речі, багато хто придбав наявні на той момент на ринку DPI-системи — вже їх викинули. Ну, не заточені вони під подібне: сотні тисяч адрес, десятки тисяч URL.
І водночас під цей ринок дуже піднялися вітчизняні виробники. Я не говорю про апаратну складову - тут усім все зрозуміло, проте софт - головне, що є в DPI - можливо, на сьогодні якщо не найпросунутіший у світі, то точно а) розвивається семимильними кроками, і б) за ціною коробкового - просто непорівнянний із зарубіжними конкурентами.
Хотілося б похизуватися, але трохи сумно =)
Тепер все виглядало так:
Ще через кілька років у всіх уже стояли ревізори; ресурсів у реєстрі ставало дедалі більше. Для деякого старого обладнання (наприклад, cisco 7600) ставала просто незастосовною схема з «фільтрацією збоку»: кількість маршрутів на 76 платформах обмежена близько дев'ятисот тисяч, у той час, як число тільки IPv4-маршрутів сьогодні вже підбирається до 800 тисяч. А якщо ще й ipv6… А ще й… скільки там? 900000 окремих адрес в лазні РКН? =)
Хтось переходив на схему з дзеркалюванням всього магістрального трафіку на фільтруючий сервер, який повинен аналізувати весь потік і при знаходженні чогось поганого надсилати в обидві сторони (відправнику та одержувачу) RST.
Проте що більше трафіку, то менш застосовна подібна схема. За найменшої затримки в обробці — дзеркальний трафік просто непомітно пролетить унікуди, а провайдеру прилетить протокол про штраф.
Дедалі більше провайдерів змушено ставити DPI-системи різного ступеня надійності у розріз магістралей.
Рік-два тому з чуток, практично у всіх ФСБ почало вимагати реальну установку обладнання (Раніше більшість провайдерів обходилася погодженням з органами плану СОРМ — планом оперативних заходів на випадок необхідності десь знайти)
Крім грошей (не так, щоб просто зовсім захмарних, але все ж таки — мільйонів), СОРМ у багатьох зажадав чергових маніпуляцій з мережею.
- СОРМ необхідно бачити «сірі» адреси користувачів, до nat-транслювання
- У СОРМу обмежена кількість мережевих інтерфейсів
Тому нам, зокрема, довелося чудово перебудувати шматок ядра — просто для того, щоб зібрати десь в одному місці трафік користувачів до серверів доступу. Для того, щоб кількома лінками віддзеркалювати його в СОРМ.
Тобто, дуже спрощено, було (ліворуч) vs стало (праворуч):
Зараз у більшості провайдерів вимагають впровадження також і СОРМ-3 — який включає, в тому числі, і логування нат-трансляцій.
З цією метою у схему вище нам довелося додати ще й окреме обладнання для NAT`а (якраз те, про яке йдеться у першій частині). Причому додати у певному порядку: оскільки СОРМ повинен «бачити» трафік до транслювання адрес — трафік повинен йти строго таким чином: користувачі -> комутація, ядро -> сервери доступу -> СОРМ -> НАТ -> комутація, ядро -> інтернет. Для цього нам довелося буквально «розгортати» потоки трафіку в інший бік наживу, що теж було досить непросто.
Разом: за десяток років схема ядра середнього провайдера ускладнилася в рази, а додаткових точок відмови (як у вигляді обладнання, так і у вигляді єдиних комутаційних ліній) значно побільшало. Власне, сама собою вимога «бачити все» має на увазі зведення цього «всього» в одну точку.
Думається мені, це цілком прозоро можна екстраполювати на поточні ініціативи щодо суверенізації рунету, його захисту, стабілізації та покращення 🙂
А попереду ще Ярова.
Джерело: habr.com