ayvango Опубликовано 8 марта, 2012 Объясните идиоту, почему он не может ставить на своих пакетиках произвольный source address. Вроде как это же не обязывает анонсировать провайдера данный адрес как свой. А просто показывает куда будет уходить ответу - и это будет другой провайдер, владелец этого самого адреса. По крайней мере после чтения Танненбаума у меня сложилось такое впечатление. Опять же помнится раньше был популярен полуспутниковый асимметричный интернет, который без подобного подхода не представим. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 8 марта, 2012 А при полуспутниковом канале разве не надо было поднимать VPN до сервера провайдера? Интерфейс для отправки данных был у него, там же все и растекалось по направлениям. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 8 марта, 2012 Приличные провайдеры следят за тем чтобы у уходящих пакетов были адреса их сетей, чтобы вирусы не спуфили во врем доса и чтобы случайно не пропустить чужой трафик. Ещё бывает всякий ошибочный и мусорный, которому на магистралях тоже нечего делать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
woddy Опубликовано 8 марта, 2012 потомучто провайдеру это нафиг не надо :) нормальные абоненты (99.9% ) обойдутся своим адресом. а ненормальные - пусть платят деньги за свое желание странного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LionSprings Опубликовано 8 марта, 2012 Объясните идиоту, почему он не может ставить на своих пакетиках произвольный source address Почему не может? Может. Ставьте на здоровье. Только провайдер их выкинет, потому что это пакетики с какого-то левого адреса, не клиентского ниразу. А вопрос позабавил. "Почему при покупке в интернет магазине я не могу использовать карту и адрес человека с другого континента?" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 8 марта, 2012 Как–раз адрес и карту вполне можешь, плохой пример. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Прохожий Опубликовано 8 марта, 2012 Патамушто! Собственно, это совершенно исчерпывающий ответ. Спецам очевидно, а неспецам - долго и не нужно объяснять. Технически это возможно, практически это формально запрещено, но фэйковые адреса все уважающие себя люди режут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
thodin Опубликовано 8 марта, 2012 А вот в сигнальных сетях на уровне SCCP не режут. Что приводит к существованию всяких разных схем.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 8 марта, 2012 Спецам очевидно, а неспецам - долго и не нужно объяснять. Технически это возможно, практически это формально запрещено, но фэйковые адреса все уважающие себя люди режут. Ты думаешь, что китайские хостеры себя не уважают? =) Скорее, им насрать, уважают ли их другие. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 8 марта, 2012 vIv Почему только китайские хостеры? Существует и европейские ДЦ, которые не режут ip spoof, да и вообще сейчас почти любые "Рога и КОпыта" могут прийти на какой-нибудь IX и баловаться с src_ip. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pliskinsad Опубликовано 8 марта, 2012 Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlexBT Опубликовано 8 марта, 2012 А вот в сигнальных сетях на уровне SCCP не режут. Что приводит к существованию всяких разных схем.. Не понял. Поподробней можно? Вы об ОКС7 пишите, или о чем то другом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DelSt Опубликовано 8 марта, 2012 (изменено) Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета. rpf нельзя применять в случае наличия bgp :/ а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться :) И он логично выкатит претензию своему второму аплинку Изменено 8 марта, 2012 пользователем DelSt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pliskinsad Опубликовано 8 марта, 2012 (изменено) DelSt так точно. На магистралях нельзя, а вот конечному провайдеру нужно озаботиться такой фичей. а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей. Изменено 8 марта, 2012 пользователем pliskinsad Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Savaoff Опубликовано 8 марта, 2012 Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета. rpf нельзя применять в случае наличия bgp :/ а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться :) И он логично выкатит претензию своему второму аплинку RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
thodin Опубликовано 8 марта, 2012 (изменено) Не понял. Поподробней можно? Вы об ОКС7 пишите, или о чем то другом? Ага, я могу запустить в сеть Telia sccp пакет c cgpa из нашего российского номерного плана и ответ придет через МТТ. На жаргоне - "треугольник". Имеет большой смысл из-за различий в тарификации сигнального трафика разными операторам - транзитными, большой тройкой и т.д... Изменено 8 марта, 2012 пользователем thodin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Janus Опубликовано 8 марта, 2012 DelSt так точно. На магистралях нельзя, а вот конечному провайдеру нужно озаботиться такой фичей. а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей. А что не так? Если я ещё чёто помню, то "не вижу в бестах префикс - не принимаю с него входняк". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DelSt Опубликовано 8 марта, 2012 (изменено) DelSt так точно. На магистралях нельзя, а вот конечному провайдеру нужно озаботиться такой фичей. а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей. Ну да. Предположим кастомер повесил backup-community которое понижает LP до минимального уровня. И в таком случае rpf похерит исходящий от клиента трафик RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF... Печаль. Подпортило мнение о ретне. У меня были мысли о включении rpf на юриков, но в итоге отказался от этой идеи, так ACL и висят (есс-но для тех у кого нет bgp) Изменено 8 марта, 2012 пользователем DelSt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Janus Опубликовано 8 марта, 2012 RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF... ну разбирали же по полочкам... Опять? :( Его кто заставлял, имея пир с Ретном, становится клиентом его клиента? Жадность? Экономия? :))) Напрямую подключиться было западло? :) Всё очень просто: видишь анонсы сетки от своего даунлинка - автоматом принимаешь с этой сетки входняк. любой. в том числе идущий на свои аплинки. Теперь к тебе прилетает от той же сетки исходняк на твои аплинки, но через пировый порт. В момент входа сеть трафик "теряет цвет" откуда он пришел. Представь: пришел траф на твой аплинк с /24, которая у тебя прописана уже как валидная клиентская. Как отличить первый траф от второго? Кому-то хотелось поискать в Ретне "дырки" и решили гнать исходняк на его аплинки бесплатно - через пир. Какое средство борьбы предложишь? А так да... во всем виноват Ретн. А "умники" такие белые и пушистые. С такими только так и можно - на входе юрпфом по хитрой рыжей морде! :))) Печаль. Подпортило мнение о ретне. Ты не спешил бы с выводами. Пусть тебе Савва ВСЮ историю раскажет, вместе с названием клиента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DelSt Опубликовано 8 марта, 2012 (изменено) Его кто заставлял, имея пир с Ретном, становится клиентом его клиента? Жадность? Экономия? :))) Напрямую подключиться было западло? :) Всё очень просто: видишь анонсы сетки от своего даунлинка - автоматом принимаешь с этой сетки входняк. любой. в том числе идущий на свои аплинки. Теперь к тебе прилетает от той же сетки исходняк на твои аплинки, но через пировый порт. В момент входа сеть трафик "теряет цвет" откуда он пришел. Представь: пришел траф на твой аплинк с /24, которая у тебя прописана уже как валидная клиентская. Как отличить первый траф от второго? ОК, случай такой: У RETN 2 клиента - х и у. ООО Рога и Копыта включается в х и у. И в какой-то момент у них сильно перекосился трафик и они на часть своих анонсов в х сунули препенд. Исходняк который прет через х подропается. p.s. Кстати это одна из причин по которой я против присутствия на IX. Изменено 8 марта, 2012 пользователем DelSt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 8 марта, 2012 Janus Тогда объясните почему РЕТН не пожаловался на участника, который вливал в него трафик через ix? Вычислить мак-адрес подлеца и отправить жалобу администрации IX. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Savaoff Опубликовано 8 марта, 2012 (изменено) Пусть тебе Савва ВСЮ историю раскажет, вместе с названием клиента. Да пожалуйста. МФТИ. Дело было давно, поэтому я уже не помню, почему именно РЕТН по крайней мере часть их анонсов видел не через нас (мы были клиентами ретна, а мфти - нашим). По-моему, МФТИ тупо часть сетей нам не анонсили по каким-то своим причинам, и надо сказать - имели полное право этого не делать. В любом случае, DelSt привел достаточно примеров, когда применение rpf на BGP линках приводит к проблемам. Изменено 8 марта, 2012 пользователем Savaoff Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 8 марта, 2012 ОК, случай такой: У RETN 2 клиента - х и у. ООО Рога и Копыта включается в х и у. И в какой-то момент у них сильно перекосился трафик и они на часть своих анонсов в х сунули препенд. Исходняк который прет через х подропается. Нифига не дропается. И никогда не дропался при наличии анонса на клиентском стыке. То, что он не best - пофиг, при включённой на Джуне опции 'urpf feasible-paths' Но Janus прав, от клиента надо пропускать любой трафик. Впрочем, не совсем любой. Фейковые source ip типа приватных, то есть вообще не предполагающие ответного трафика, есть мусор, который надо давить на первом же хопе. С этим хорошо справляется urpf loose mode, которым и тирваны не брезгуют p.s. Кстати это одна из причин по которой я против присутствия на IX. Были случаи, когда клиент, отдавая на аплинковом стыке агрегат и на ix-е его морспецифики, нимало этим не смущался, будучи в полной уверенности, что это его неотъемлемое право. Но urpf - не самый убедительный способ указать такому поборнику "свободы анонсов" на его неправоту. Потому от этого средства убеждения уже очень давно отказались Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DelSt Опубликовано 8 марта, 2012 Нифига не дропается. И никогда не дропался при наличии анонса на клиентском стыке. То, что он не best - пофиг, при включённой на Джуне опции 'urpf feasible-paths' Не анонсировать свои префиксы аплинку есть святое право клиента. Но Janus прав, от клиента надо пропускать любой трафик. Впрочем, не совсем любой. Фейковые source ip типа приватных, то есть вообще не предполагающие ответного трафика, есть мусор, который надо давить на первом же хопе. С этим хорошо справляется urpf loose mode, которым и тирваны не брезгуют Для клиентов без bgp я ACL'ем убиваю трафик сорс-адрес которого не из диапазона клиента - об этом и тема. Были случаи, когда клиент, отдавая на аплинковом стыке агрегат и на ix-е его морспецифики, нимало этим не смущался, будучи в полной уверенности, что это его неотъемлемое право. Но urpf - не самый убедительный способ указать такому поборнику "свободы анонсов" на его неправоту. Потому от этого средства убеждения уже очень давно отказались Такой трафик надо дропать однозначно :) А как теперь боритесь с этим? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 8 марта, 2012 Janus Тогда объясните почему РЕТН не пожаловался на участника, который вливал в него трафик через ix? Вычислить мак-адрес подлеца и отправить жалобу администрации IX. Администрация IX не является третейским судьей в спорах его members на предмет routing policy. Принимать какие бы то ни было меры в отношении "виновного" у него нет никаких прав. Да и технических средств доказать его "неправоту" у IX-а нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...