Pull to refresh
136
0
Send message
По-английски бы еще то же самое )
Скорее всего слепой дроп, про который вы пишете, — это как раз блокировка магистральным оператором, а не вашим провайдером, про которую я писал выше. Это началось как раз после визита Медведева во ВГИК. Потом 25-го DDoS Guard развернул трафик рутрекера, и началась вот эта истоиря, про которую пишут в ОП.

Если у вас из Питера (без VPN и надстроек) вдруг наблюдаются симптомы, отличные от ожидаемых, типа стандартной плашки о блокировке вашего провайдера (либо слепые дропы, либо, наоборот, все рабоает), то покажите traceroute, а лучше tcptraceroute на 80-й порт: любопытно.
Отвлекаясь от вопроса, насколько массовой является практика приземления в РФ магистрального конца туннелей для обхода блокировки (признаться, есть сомнения, но вам виднее), очень похоже на то что фильтрация магистрального трафика теперь будет стандартной практикой. Сорока (и не одна) на хвосте принесла, что после истории с Медведевым РКН этого добивается от транзитных операторов.

Проявления этого факта заметны не только на примере ТТК, у которого к тому же и международный транзит попал под блокировку, что противоречит, собственно, персловутому закону о блокировках, из-за чего и поднялся этот хай.

Примерно за неделю до этой истории (сразу после казуса с премьем-министром) появились сообщения о слепых дропах (без показа запретительной плашки) из разных концов российского интернета. Я ковырял один из таких случае — там видно, что фильтрация происходит посредством DPI по хосту в HTTP-запросе. То есть tcptraceroute ходит, пинг, телнет на 80-й порт — все ОК, а в браузере — не открывается. Из тех мест, где блокировки на доступе нету, и должно бы открываться. Народ даже активно предполагал, что это сам рутрекер блокирует «чистый» российский трафик, чтоб всяким премьер-министрам неповадно было.

Дополнительный анализ показал, что такие симптомы наблюдаются у тех, у кого трафик за пределы РФ идет через российский Ретн. Причем у тех, у кого, трафик покидал РФ через ТТК, оно на тот момент как раз еще работало.

Так что надо готовиться к тому, что блокировка (причем слепая, без плашек) в России на магистрале будет (или уже стала) повсеместной нормой.
гонять трафик на очистку куда нибудь в Нидерланды или США означало бы двойные а то и тройные задержки для пользователей в плане скорости

Очень сомнительный аргумент. Из России трафик по пути на Рутрекер вообще-то и так ходит куда-нибудь в Нидерланды или США, потому что его туда тянут средства обхода блокировки. И вот как раз тащить его обратно в Россию не очень логично в том числе и с точки зрения задержек.
гонять трафик на очистку куда нибудь в Нидерланды или США означало бы двойные а то и тройные задержки для пользователей в плане скорости

Очень сомнительный аргумент. Из России трафик по пути на Рутрекер вообще-то и так ходит куда-нибудь в Нидерланды или США, потому что его туда тянут средства обхода блокировки. И вот как раз тащить его обратно в Россию не очень логично в том числе и с точки зрения задержек.
Это тот случай, когда традиционные средства обхода блокировки (FreeGate, VPN) не могли гарантированно помочь, потому что трафик из точки выхода вне России на пути в Рутрекер (который тоже вне России) возвращался уже в чистом виде в Россию, и там фильтровался некоторыми операторами. Поэтому во фригейте, например, работали далеко не все прокси (но некоторые, например эстонский, работали, да).
Чуваки, а ваш уэб-сервачок часом не ждет этот HTTP GET от конкретного адреса? Типа, с которого клиент до этого через другую TCP-сессию авторизовался где-нибудь у вас? А то у опсосов частенько бывает, что нат по недогляду транслирует разные сессии абонента в разные адреса внешнего пула, и может выйти, что одна сессия к вам с одного айпишничка приходит, другая — с другого. И либо МТС включил залипание адреса по-тихому (так бывает ;), или ваши разрабы что-нибудь вроде привязки юзера не к IP, а кукам запилили (что правильно, потому что такой нат к сожалению случается иногда)?
Упс. Сорвалось.

> Это не то же самое, что уверенность в том, что если вы (при наличии префикса)

Это не то же самое, что уверенность в том, что если вы (при наличии префикса A) пошлете трафик назначению A, то он до него дойдет.
Если вспомнить, что роутинг и ричабилти — не одно и тоже, то будет чуть понятнее. Да, отказ от кастом-префиксов — это определенная плата. И вся речь лишь о том, в чем эта плата состоит и за что она.

Если вы не держите полной таблицы — вы не знаете, ходит ли префикс от назначения A к вашему провайдеру по BGP. Это не то же самое, что уверенность в том, что если вы (при наличии префикса)

Если префикса нет, значит связности (ричабилити) нету. Но. Если префикс есть — это вообще ни о чем не говорит. В боевых ситуациях бывает сколько угодно примеров, когда префикс есть, а трафик не ходит. Потому где-то у ISP линк перегружен например, или потому что у него в сети флэппинг или какая-нибудь еще нестабильность, от которой наличие FullView на вашей стороне никак не страхует.

Что касается же FullView, то любой мало-мальски вменяемый ISP имеет несколько внешних линков. И ситуация, при которой у него нету связности с какими-то префиксами, и он не даст вам полной таблицы — экстраординарная. Если она происходит — это повод задуматься о смене ISP в любом случае.

Теперь про то, за что это (отказ от FV) плата. Ну, собственно, вся статья про это. Вы существенно экономите (деньги) на оборудовании.

То есть, еще раз. Тип отказов, от которых вас страхует полная таблица на вашей стороне — не единственный и не самый страшный. По хорошему задача инженера в том, чтобы четко понимать, от каких типов отказов страхует его FullView, что она дает чего нет, и уметь доносить это до бизнеса. А решать, выкладывать ли за страховку от такого-то типа раска приличную сумму — вопрос не технический, а про бизнес.

Примерно в 90% случаях, когда я работаю таким консультантом для случая корпоративной сети, моя рекомендация — потратить эти деньги на что-нибудь более полезное.

Мы в каментах тут про все это много раз поговорили со всех сторон. Вот например дельная веточка:
habrahabr.ru/post/113906/?reply_to=7045634#comment_3703216

>чем-то вроде Dynamic DNS и при падении ISP менять IP-адреса внешних ресурсов.

Для интерактивных приложений типа web — нет. А для неинтерактивных (типа SMTP) реализация как правило поддерживает возможность резервирования средствами протокола (если недоступен один MX, идем на другой). В сущности, да, корпоративной сети AS и PI-блок нужна в первую очередь для обеспечения отказоустойчивости web-сервисов. Все остальное по большому счету сегодня можно сделать не парясь этим.

Для связности интернета, транзитных AS и т. д. — там да, там полные таблицы во все стороны нужны.
Конечно, если человек в работе использует продукцию компании X, то ему придется изучить концепцию, которые компания X использует в своих продуктах. Если это хвосты классовой адресации — значит надо знать про хвосты классовой адресации, если свитки Торы — надо знать про свитки Торы, принцип запрета Паули — придется и его освоить. При этом осознавая, что компания Y может на все это наплевать и пользоваться противоположными принципами.

Еще, например, цискины экзамены полны вопросов про EIGRP и FrameRelay. Да и слава тебе господи, пусть люди, которые сдают те экзамены, с этим и возятся, причем тут я и моя статья? Ведь ниоткуда не следует, что она предназначена для людей, которые собираются стать специалистами по продуктам Cisco.

Вообще, я выше в каментах где-то писал, что если кто-то воспринимает мои посты в бложике как единственный источник знаний о профессии, то ему лучше бы сразу поискать себе работу в другой области. Я даже не считаю нужным делать дисклеймер на этот счет, потому что нормальным людям и так очевидно, что это не руководство по подготовке к CCIE и даже — к JNCIA.

>Почему для подсетей всегда рисуется нечто, что очень напоминает классовую сеть? А ведь 21
>век на дворе!!!

Основная причина — бабло. Никакая циска ни в каком веке не станет просто так выкидывать на ветер миллионы ради исправления проблемы, которая проблемой не является (плевать на самом деле, как именно отсортированы маршруты в выводе, лишь бы можно было найти нужный не слишком напрягаясь). Всем понятно, что у нее в выводе написано — понятно. Принципы странные? — да и хрен бы с ними. Маркетологи говорят, что если поменять, то продажи возрастут на на миллиард? — не говорят. Есть опасения, что если это поменять, то у людей сломаются говноскрипты и много всякой другой херни, из-за чего начнется вой, нагрузка на TAC и недовольство ключевых заказчиков? — есть. Значит оставляем все как есть.

Логика структуры вывода цискиного show ip route — это повод для анекдотов уже лет десять как. Ее большинство инженеров внутри самой Cisco не понимают, и ничего — живут как-то. Вообще, ахинея такого вот рода

     82.0.0.0/32 is subnetted, 1 subnets
S        82.94.230.130 [1/0] via 129.143.103.77

это лучшая иллюстрация тезиса, что про классы адресов давно пора бы забыть.

P. S. По существу — вы второй коммент подряд порете херню, извините. То подкрепляете доводы цитатой, в которой написано прямо обратное, то вывод всей таблицы маршрутизации на экран называете наиважнейшиим навыком. Причем делаете это в довольно-таки хамском и чересчур надменном, простите, тоне.

Если вы хотите сообщить мне, что вы не последний человек в профессии — дык я вам и так верю, можно так не напрягаться. А вот выступать потребителем вашего самовыражения — извините, скучновато.
Я ничего из ваших рассуждений про определение CIDR-блока не понял. И совершенно не чувствую, чтоб мне это как-то мешало жить :) Приведите точную цитату, может.

Про RIPng тоже был разговор в каментах к этому топику:
habrahabr.ru/post/129664/?reply_to=6951594#comment_4311694
Стр. 14 доклада по моей ссылке там. Доклад этот Стинберген делал на NANOG49, 2009 год. На дату RFC2080 сами поглядите.

Цитата про BGP autosummary объясняет как работает команда, а не зачем нужна автосуммаризация в BGP (заметьте, я говорю не про суммаризацию BGP-префиксов вообще, а про АВТО-суммаризацю). Так вот эта циата — она про то и говорит, что если автосаммари включено, то вместо реального префикса 10.100.50/24 в BGP уйдет 10/8. Это и есть бред сивой кобылы. =В данном случе разговор про суммаризацию по границе класса.

И даже если бы она была бесклассовой, а некий другой «умный» механизм бы из двух соседних префиксов 10.100.50/24 и 10.100.51.0/24 автоматически бы по умолчанию всегда делал 10.100.50.0/23, то это все равно было бредом сивой кобылы. Например потому что BGP — протокол предназначенный для передачи очень большого количество маршрутов (сотен тысяч и миллионов). И выдергивание нескольких префиксов /24 из таблицы, в которой автоматически сделана такая суммаризация, может привести к неадекватно большим вычислительным затратам. Впрочем, это далеко не единственная причина.

Циска — один из немногих вендоров, реализации которой что-то знают про классы адресов. Делает она это не потому что так уж любит классовую адресацию, а потому что выкидывание фич, пусть даже устаревших, из огромной промышленной машины с заказчиками, привычками, миллионо специфический внедренй, документацией (внешней и внутренней), книгами и т. д. — это гораздо сложнее (читай: очень дорого), чем сохранять эти фичи, не трогая их.

Большинство же вендоров вообще не употребляют такие слова как «класс адресов» и «CIDR-блок», потому что никаких других кроме CIDR блоков адресов давно уже нету. И это совершенно никому не мешает.

Знать про все это, в принципе, нужно, для кругозора и вообще, чтоб читать всякие такие старинные RFC и уметь поддержать беседу про RIP.
Про автосаммари мы выше разговаривали. См. чего sahe пишет в частности в этой ветке: habrahabr.ru/post/129664/#comment_4311895 Если хоротко, то это где-то в диапазоне между «говно мамонта» до «причуды реализации одного вендора». С RIP то же самое. Я еще в 2003 году учился в Cisco Academy и ребята там балуясь на доске рисовали могилку и писали «RIP RIP». 10 лет прошло.

То есть ретроспективно, для общего развития, рассказов внукам, пугания детей и проч. — про все это имеет смысл иметь какое-то представление. Если говорить о ликбезе, то нахрен это оно не сдалось.

Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.

Никакой классовой адресации нету. Нету. Забудьте. Есть вендоры, экзамены, книжки, люди, которые это слово употребляют. Да, есть. Ну есть еще люди, которые говорят «лóжить» и «звóнить». Ну есть. Ну говорят.
Про автосаммари мы выше разговаривали. См. чего sahe пишет в частности в этой ветке: habrahabr.ru/post/129664/#comment_4311895 Если хоротко, то это где-то в диапазоне между «говно мамонта» до «причуды реализации одного вендора». С RIP то же самое. Я еще в 2003 году учился в Cisco Academy и ребята там балуясь на доске рисовали могилку и писали «RIP RIP». 10 лет прошло.

То есть ретроспективно, для общего развития, рассказов внукам, пугания детей и проч. — про все это имеет смысл иметь какое-то представление. Если говорить о ликбезе, то нахрен это оно не сдалось.

Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.

Никакой классовой адресации нету. Нету. Забудьте. Есть вендоры, экзамены, книжки, люди, которые это слово употребляют. Да, есть. Ну есть еще люди, которые говорят «лóжить» и «звóнить». Ну есть. Ну говорят.
Ой. Я не это совсем имел в виду. Ну, т. е. использовать EoL и БУ оборудование — это вполне себе бизнесс-стратегия, успех которой обсуждать мне, честно говоря, лень. Скажу лишь, что для данной конкретной задачи 2950 ничем не лучше, чем третьесортный китайский OEM. Но мне, честно говоря, показалось, что автор их использовал просто потому что они у него под рукой были — типа, лаба.

Я скорее про техническую часть. Вообще сеть под ШПД-подписку из одних только коммутаторов такого рода (не обязательно c2950, вообще любых энтерпрайзных свичей) — это сомнительная затея с точки зрения масштабируемости, управляемости, устойчивости к отказу и проч. Точнее, она более-менее ОК, когда между BRAS-ом и абонентом не больше двух коммутаторов. Дальше начинается подземелье.
Ну типа про option82 — да (хотя имхо 1:1 VLAN веселее), но строить провайдерский доступ, обставив город каталистами 2950 — о-хо-хо, написал бы вот кто-нибудь о том, почему так делать не надо :)
Ну, то есть, я правильно понимаю, что все рассуждения про оптимизацию здесь справедливы только для частного случая морфлогического анализа и описываемый подход может оказаться неприемлем, если задача расширяется до синтаксиса?
Складывается ощущение, что все описанное имеет отношение только к морфологии.

Но ведь очевидным желанием является хранить внутри представлений слов как минимум синтаксические свойства слов (ок, на следующем этапе и т. д.) Ведь в конце концов ваш пример с «мама мыла раму» — он про синтаксис. В конечном итоге задача сведется к ответу на вопрос «мыла» — это «мыло» или «мыть». Да и ссылки на примеры систем автоматической обработки текстов — они как минимум не про чистую морфологию.

Соответственно, у переходов в дереве состояний должны быть какие-то веса/вероятности/etc, сигнализирующие морфологические изменения в зависимости от синтаксической роли. Ну или как-то еще структура должна позволять (в будущем) хранить эту (а возможно и другие типы) информации о словах.

Получается, что весь разговор про оптимизацию структур нужно вести в контексте возможности масштабирования и возможности «навески» дополнительных аспектов. Иначе может получиться, что оптимизированное представление, рассчитанное только на морфологическую информацию, не позволит использовать словарь для более-менее реальных прикладных задач.

Ну или по крайней мере хочется понять, зачем нужен словарь, которые содержит только морфологические данные.
Я прекрасно понимаю, о чем вы.

Но только еще раз повторюсь, что пакет, прежде чем вообще быть скоммутированным свичем, который передает трафик с плат коммутации в RE, должен пролезть через систему файрвольных фильтров внутри комплекса коммутации. В случае с eBGP это должен быть пакет только от пира, и только с TTL 1. То есть это способ защититься в том числе от этой уязвимости, и это должно быть сделано, на любом маршрутизаторе, RE которого общается с недоверенными сетями.

И если этого не сделано, то бессмысленно вообще говорить о каких-либо уязвимостях, потому что, если кто-то хочет выставить свою задницу в интернет, вопрос о том, каким именно способом его могут трахнуть, приобретает вторичное значение.

SSH с web-менеджментом, если он у вас есть, на время до апгрейда можно и вовсе отключить из интернета. Другие TCP, адресованные в RE, надо просто выкидывать у помойку не глядя. И до того, как этот косяк обнаружили, так и после.

Так что никакой страшной неопределеннсти и вот этого вот «ах, неизвестно к чему это можно привести. Вдруг нам нужно какие-нибудь еще TCP-порты слушать, а мы не знаем, какие» — ничего этого нету. Все вполне известно и определенно. И защититься в данном конкретном случае вполне можно и нужно.

А то что уязвимость и баги это плохо — ну, можно и попалакать, конечно, но мне лень, если честно. Далеко не самая страшная это проблема, в т. ч. из встречающихся в JUNOS.
Ну, я с вашего позволения, повторю свой первоначальный тезис:

Если так случилось, что конфигурация уязвима в отношении данного экспойта, то с большой вероятностью она уязвима к массе других возможных атак на тот же BGP, о которых известно давно и подробно. И наоборот: если вы раньше думали головой и все делали правильно, то от этой проблемы вы защищены — проапгрейдиться все же стоит, но скорее в плановом режиме, чем сломя голову.

А дальше каждый сам решает, разумеется.
Ну, то есть, поймите правильно мой спич. Задуматься об апгрейде надо, нет вопросов. Но вот прям паниковать и сломя голову менять софт, нарушив стандартные правила этого дела (как минимум чтение Release Notes плюс соотнесение номера релиза со здравым смыслом) — по-моему не стоит. Лучше проверить, чего у вас в части стандартных механизмов защиты сделано.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity