От цены же зависит многое. Если условно за ту же цену брендового сервера можно взять две супермикры — почему бы и не взять? Да, есть риски брака, но замена то уже рядом.
Опять же в случае поломок мгновенная замена из склада а не "курьером на следующий день". Если брать однотипное железо — не надо держать огромный склад, скорее небольшое помещение. В чем я рассуждаю неправильно?
Так ведь проблема в том что эти самые другие ломают большую часть усилий тех кому не пофигу. Атака со включением AS жертвы в свой анонс будет успешно проведена через сети аналогичные AS701. И подобных AS немало, т.к. наткнулся еще на пару штук бездумчиво переходя по записям в apnic.
Еще как и проверяется. Ждать маршрут на вашу АС будут только от ваших export аплинков, т.е. от AS-UP-LINK
Не уверен что проверяется рекурсивно а не слепо поверит содержимому твоего export, но спорить не буду.
Проверка пути анонса давно реализована, ее просто не делают.
А разве export/import policy обязательны? Вроде только в ripe все относительно неплохо организовано. Вот не из ripe. Первая попавшаяся крупная AS701. Не нашел там никаких политик.
Также смотрю на маршруты которые она анонсит и не могу найти роут-объектов и какая AS должна их анонсить. 63.48.0.0/12
Как в таких условиях что-то валидировать мне абсолютно непонятно.
Эта та, которая описывает какой as-set он может анонсить? Так а что мешает ему в этот as-set добавить нужную AS? Она же принадлежит ему. А рекурсивно вроде также не проверяется. (поправьте если это не так).
И вообще для конечных клиентов — это 95% только белый список сетей.
Не всегда. Тот же hurican electric не проверяет. В сетях обмена трафиком тоже не всегда.
Для чего нужен RKPI вполне понятно. Чтобы роут-объект в том же ripedb был гарантировано изначально анонсирован той AS которая указана в БД. И да, RKPI нужен. Но он не обеспечивает безопасность. Говорить что RKPI = безопасность и защита от hijack — вешать лапшу на уши.
Мое личное мнение — RPKI решение по духу из двухтысячных годов. Сейчас могли бы сделать решение с проверкой пути анонса.
upd: Наверное погорячился, защита от hijack роут-объектов есть. То есть гвоздями прибито соответствия маршрута и AS. И чтобы что-то поломать случайно (как часто и происходит) надо очень постараться.
Безопасный в кавычках?
Насколько я понял не особо полезная штука от хакеров. Защищает только от совсем случайной ошибки (или сильно крупные сети, которые пирятся со всеми). Валидируется только origin (что данная AS может анонсить данный маршрут). Путь никак не валидируется и не защищается. Хаки типа вырезания своей AS из машрута остаются актуальными.
С точки зрения злоумышленика — что мешает хакеру анонсить маршрут через свою AS? Похоже что ничего
1) Не факт что складываться. Надо смотреть распределение по возрастам. Я бы предположил что вместо 8 мы получим 12.
2) Даже если будут складываться. Если размазать пик смертность падает до 0.5%. И на фоне естественной смертности смертность от короновируса выделяться не будет.
Смысл сообщения в том что сильно паниковать не стоит. Даже если не найдут лекарства.
Продолжу тему наглядности: предположим что средняя продолжительность жизни 70 лет. За год в вашем доме умрут те же 8 человек просто потому что превысят 70 лет.
В стране например за год умирает 2 миллиона. И за день 5.5 тысяч.
Зачем на поднимать на машине? Уже есть CoreDNS.
Как сделано сейчас:
для сервиса foo в namespace hello создается одна запись: foo.hello.svc.cluster.local.
В подах в resolv.conf такое: search hello.svc.cluster.local svc.cluster.local cluster.local.
foo 1 запрос.
foo.hello 2 запроса
foo.hello.svc 3 запроса
mrkaran.dev 4 запроса (3 лишних).
Варианты уменьшения лишних запросов.
1) Добавлять записи днс для каждого пути из search. (самый простой и некостыльный)
Для foo в namespace hello создавать записи в днс.
foo.hello.svc.cluster.local.
foo.hello.svc.
foo.hello.
Search при этом обрезать до search hello.svc.cluster.local
foo 1 запрос.
foo.hello 2 запроса
foo.hello.svc 2 запроса
mrkaran.dev 2 запроса (1 лишний).
Уже значительно легче для приложений которые интенсивно ходят в интернет. Без сильного оверхеда.
2) отказаться от search полностью. В дополнение предыдущему варианту добавлять запись в днс без namespace. Но тут надо либо поднимать инстанс DNS в каждом namespace, либо пилить костыли опирающиеся на сеть (source ip, destination ip).
у вас проблему смягчает
1) часть ваших пользователей использует кеширующие DNS сервера (провайдера или гугла)
2) часть пользователей может использовать впн для доступа
3) часть пользователей может использовать DNS over HTTPS
То есть по факту ваш сервис доступен, плюс спокойно можете перетащить днс кдругому днс провайдеру. Есть доступ к данным. Сравнивать с полной недоступностью и невозможностью получить доступ к данным для переноса в другой ДЦ очень странно.
Добавлю что ndots=1 скорее всего не поломает резолв внутри кластера. Сначала будет сделан запрос без добавления элементов из search и, если он не вернет результатов, будет использоваться путь поиска. ndots=5 сделали чтобы не перегружать корневые dns сервера и чтобы избежать потенциальной mitm атаки.
Но по мне красивее было бы логику поиска перекинуть на локальный dns server (где есть информация о ресурсах) и тем самым избежать лишнего сетевого трафика.
Да тут еще осложняет эксперимент то что ощущения проявлялись не сразу, а спустя минуты три. Я проведу эксперимент позже и отпишусь. Ноутбук отворачивать не думаю не стоит, т.к. крышка металлическая. Думаю соберу наколенный стенд с iperf + логи.
Вполне может быть и воображение, т.к. ощущения слабые (и проявляется не сразу). За идею с тестом спасибо.
Слепой тест сейчас сделать не смогу, т.к. при такой скорости передачи начинает ощутимо подлагивать беспроводная мышь. Причем что интересно — даже если приемник воткнуть в другой ноут стоящий рядом подлагивание сохраняется.
Так оракловое облако по сети в 10 раз дешевле, логично что перешли. У них наверное основные траты это сеть.
От цены же зависит многое. Если условно за ту же цену брендового сервера можно взять две супермикры — почему бы и не взять? Да, есть риски брака, но замена то уже рядом.
Опять же в случае поломок мгновенная замена из склада а не "курьером на следующий день". Если брать однотипное железо — не надо держать огромный склад, скорее небольшое помещение. В чем я рассуждаю неправильно?
Так ведь проблема в том что эти самые другие ломают большую часть усилий тех кому не пофигу. Атака со включением AS жертвы в свой анонс будет успешно проведена через сети аналогичные AS701. И подобных AS немало, т.к. наткнулся еще на пару штук бездумчиво переходя по записям в apnic.
Не уверен что проверяется рекурсивно а не слепо поверит содержимому твоего export, но спорить не буду.
А разве export/import policy обязательны? Вроде только в ripe все относительно неплохо организовано. Вот не из ripe. Первая попавшаяся крупная AS701. Не нашел там никаких политик.
Также смотрю на маршруты которые она анонсит и не могу найти роут-объектов и какая AS должна их анонсить.
63.48.0.0/12Как в таких условиях что-то валидировать мне абсолютно непонятно.
Эта та, которая описывает какой as-set он может анонсить? Так а что мешает ему в этот as-set добавить нужную AS? Она же принадлежит ему. А рекурсивно вроде также не проверяется. (поправьте если это не так).
Не всегда. Тот же hurican electric не проверяет. В сетях обмена трафиком тоже не всегда.
Для чего нужен RKPI вполне понятно. Чтобы роут-объект в том же ripedb был гарантировано изначально анонсирован той AS которая указана в БД. И да, RKPI нужен. Но он не обеспечивает безопасность. Говорить что RKPI = безопасность и защита от hijack — вешать лапшу на уши.
Мое личное мнение — RPKI решение по духу из двухтысячных годов. Сейчас могли бы сделать решение с проверкой пути анонса.
upd: Наверное погорячился, защита от hijack роут-объектов есть. То есть гвоздями прибито соответствия маршрута и AS. И чтобы что-то поломать случайно (как часто и происходит) надо очень постараться.
Безопасный в кавычках?
Насколько я понял не особо полезная штука от хакеров. Защищает только от совсем случайной ошибки (или сильно крупные сети, которые пирятся со всеми). Валидируется только origin (что данная AS может анонсить данный маршрут). Путь никак не валидируется и не защищается. Хаки типа вырезания своей AS из машрута остаются актуальными.
С точки зрения злоумышленика — что мешает хакеру анонсить маршрут через свою AS? Похоже что ничего
Токен можно вытащить при помощи mitm на телефон. Я использовал sslsplit. Тоже не хотелось запариваться с бэкапом.
1) Не факт что складываться. Надо смотреть распределение по возрастам. Я бы предположил что вместо 8 мы получим 12.
2) Даже если будут складываться. Если размазать пик смертность падает до 0.5%. И на фоне естественной смертности смертность от короновируса выделяться не будет.
Смысл сообщения в том что сильно паниковать не стоит. Даже если не найдут лекарства.
Продолжу тему наглядности: предположим что средняя продолжительность жизни 70 лет. За год в вашем доме умрут те же 8 человек просто потому что превысят 70 лет.
В стране например за год умирает 2 миллиона. И за день 5.5 тысяч.
Upd: первый вариант + ndots:1 решает все проблемы.
Также если хотите ужаснуться — в гугл клаудде в кубере в search 5 записей по умолчанию (3 куберовские, 2 от гуглового проекта)
Зачем на поднимать на машине? Уже есть CoreDNS.
Как сделано сейчас:
для сервиса foo в namespace hello создается одна запись:
foo.hello.svc.cluster.local.В подах в
resolv.confтакое:search hello.svc.cluster.local svc.cluster.local cluster.local.foo1 запрос.foo.hello2 запросаfoo.hello.svc3 запросаmrkaran.dev4 запроса (3 лишних).Варианты уменьшения лишних запросов.
1) Добавлять записи днс для каждого пути из search. (самый простой и некостыльный)
Для
fooв namespacehelloсоздавать записи в днс.foo.hello.svc.cluster.local.foo.hello.svc.foo.hello.Search при этом обрезать до
search hello.svc.cluster.localfoo1 запрос.foo.hello2 запросаfoo.hello.svc2 запросаmrkaran.dev2 запроса (1 лишний).Уже значительно легче для приложений которые интенсивно ходят в интернет. Без сильного оверхеда.
2) отказаться от search полностью. В дополнение предыдущему варианту добавлять запись в днс без namespace. Но тут надо либо поднимать инстанс DNS в каждом namespace, либо пилить костыли опирающиеся на сеть (source ip, destination ip).
у вас проблему смягчает
1) часть ваших пользователей использует кеширующие DNS сервера (провайдера или гугла)
2) часть пользователей может использовать впн для доступа
3) часть пользователей может использовать DNS over HTTPS
То есть по факту ваш сервис доступен, плюс спокойно можете перетащить днс кдругому днс провайдеру. Есть доступ к данным. Сравнивать с полной недоступностью и невозможностью получить доступ к данным для переноса в другой ДЦ очень странно.
Добавлю что
ndots=1скорее всего не поломает резолв внутри кластера. Сначала будет сделан запрос без добавления элементов из search и, если он не вернет результатов, будет использоваться путь поиска.ndots=5сделали чтобы не перегружать корневые dns сервера и чтобы избежать потенциальной mitm атаки.Но по мне красивее было бы логику поиска перекинуть на локальный dns server (где есть информация о ресурсах) и тем самым избежать лишнего сетевого трафика.
Да тут еще осложняет эксперимент то что ощущения проявлялись не сразу, а спустя минуты три. Я проведу эксперимент позже и отпишусь. Ноутбук отворачивать не думаю не стоит, т.к. крышка металлическая. Думаю соберу наколенный стенд с iperf + логи.
Вполне может быть и воображение, т.к. ощущения слабые (и проявляется не сразу). За идею с тестом спасибо.
Слепой тест сейчас сделать не смогу, т.к. при такой скорости передачи начинает ощутимо подлагивать беспроводная мышь. Причем что интересно — даже если приемник воткнуть в другой ноут стоящий рядом подлагивание сохраняется.
Ну я например ощущаю что-то типа щекотки когда на ноутбуке передается что-то через wifi на скорости около 50 mbit. Отодвигаешься — ощущение пропадает.
Только что понял что запрос был к tvr. Можете сделать скриншот с надписью что ресурс заблокирован?
Нет, у него то же самое.
Конечно, вот. Это со стороны отправителя.