Перейти к содержимому
Калькуляторы

почему source address должен быть из пула провайдера

Объясните идиоту, почему он не может ставить на своих пакетиках произвольный source address. Вроде как это же не обязывает анонсировать провайдера данный адрес как свой. А просто показывает куда будет уходить ответу - и это будет другой провайдер, владелец этого самого адреса. По крайней мере после чтения Танненбаума у меня сложилось такое впечатление. Опять же помнится раньше был популярен полуспутниковый асимметричный интернет, который без подобного подхода не представим.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А при полуспутниковом канале разве не надо было поднимать VPN до сервера провайдера? Интерфейс для отправки данных был у него, там же все и растекалось по направлениям.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Приличные провайдеры следят за тем чтобы у уходящих пакетов были адреса их сетей, чтобы вирусы не спуфили во врем доса и чтобы случайно не пропустить чужой трафик. Ещё бывает всякий ошибочный и мусорный, которому на магистралях тоже нечего делать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

потомучто провайдеру это нафиг не надо :) нормальные абоненты (99.9% ) обойдутся своим адресом. а ненормальные - пусть платят деньги за свое желание странного.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Объясните идиоту, почему он не может ставить на своих пакетиках произвольный source address

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

 

А вопрос позабавил. "Почему при покупке в интернет магазине я не могу использовать карту и адрес человека с другого континента?"

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как–раз адрес и карту вполне можешь, плохой пример.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Патамушто!

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вот в сигнальных сетях на уровне SCCP не режут. Что приводит к существованию всяких разных схем..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Ты думаешь, что китайские хостеры себя не уважают? =)

Скорее, им насрать, уважают ли их другие.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

vIv

Почему только китайские хостеры? Существует и европейские ДЦ, которые не режут ip spoof, да и вообще сейчас почти любые "Рога и КОпыта" могут прийти на какой-нибудь IX и баловаться с src_ip.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вот в сигнальных сетях на уровне SCCP не режут. Что приводит к существованию всяких разных схем..

 

Не понял. Поподробней можно? Вы об ОКС7 пишите, или о чем то другом?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета.

rpf нельзя применять в случае наличия bgp :/

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться :)

И он логично выкатит претензию своему второму аплинку

Изменено пользователем DelSt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться

Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей.

Изменено пользователем pliskinsad

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Unicast Reverse Path Forwarding архиполезная фича. Представьте что вы предоставляете доступ в интернет юридическому лицу, у которого своя сеть за натом. И этот нат криво настроен, и постоянно от этого клиента вам летят пакеты с адресов из диапазона RFC 1918. Технически это никому не нужный мусор. Ну и еще отличная защита от DDoS, когда в твоей сети есть кролики, компьютеры которых стали частью ботнета.

rpf нельзя применять в случае наличия bgp :/

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться :)

И он логично выкатит претензию своему второму аплинку

 

RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не понял. Поподробней можно? Вы об ОКС7 пишите, или о чем то другом?

 

Ага, я могу запустить в сеть Telia sccp пакет c cgpa из нашего российского номерного плана и ответ придет через МТТ.

На жаргоне - "треугольник".

 

Имеет большой смысл из-за различий в тарификации сигнального трафика разными операторам - транзитными, большой тройкой и т.д...

Изменено пользователем thodin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться

Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей.

А что не так?

Если я ещё чёто помню, то "не вижу в бестах префикс - не принимаю с него входняк".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

а то кастомер сунул препенд чтобы избавиться от входящего и от него трафик стал дропаться

Чет я тут не совсем понял, препендами кастомер может входящим на себя трафиком управлять. Да и то для своих сетей.

Ну да. Предположим кастомер повесил backup-community которое понижает LP до минимального уровня.

И в таком случае rpf похерит исходящий от клиента трафик

 

RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF...

Печаль. Подпортило мнение о ретне.

 

У меня были мысли о включении rpf на юриков, но в итоге отказался от этой идеи, так ACL и висят (есс-но для тех у кого нет bgp)

Изменено пользователем DelSt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

RETN всем клиентам включал и долгое время отказывался выключать (не знаю, как сейчас). По их словам, нехорошие люди через ix вливали много трафика, не являясь клиентами ретна. Мы в итоге в том числе и поэтому от них отключились - была проблема с одним нашим клиентом, трафик которого частично дропался на нашем стыке с ретном из-за включенного там RPF...

ну разбирали же по полочкам...

Опять? :(

 

Его кто заставлял, имея пир с Ретном, становится клиентом его клиента? Жадность? Экономия? :)))

Напрямую подключиться было западло? :)

Всё очень просто: видишь анонсы сетки от своего даунлинка - автоматом принимаешь с этой сетки входняк. любой.

в том числе идущий на свои аплинки.

Теперь к тебе прилетает от той же сетки исходняк на твои аплинки, но через пировый порт.

В момент входа сеть трафик "теряет цвет" откуда он пришел.

Представь: пришел траф на твой аплинк с /24, которая у тебя прописана уже как валидная клиентская.

Как отличить первый траф от второго?

 

Кому-то хотелось поискать в Ретне "дырки" и решили гнать исходняк на его аплинки бесплатно - через пир.

Какое средство борьбы предложишь?

 

А так да... во всем виноват Ретн.

А "умники" такие белые и пушистые.

С такими только так и можно - на входе юрпфом по хитрой рыжей морде! :)))

 

Печаль. Подпортило мнение о ретне.

Ты не спешил бы с выводами.

Пусть тебе Савва ВСЮ историю раскажет, вместе с названием клиента.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Его кто заставлял, имея пир с Ретном, становится клиентом его клиента? Жадность? Экономия? :)))

Напрямую подключиться было западло? :)

Всё очень просто: видишь анонсы сетки от своего даунлинка - автоматом принимаешь с этой сетки входняк. любой.

в том числе идущий на свои аплинки.

Теперь к тебе прилетает от той же сетки исходняк на твои аплинки, но через пировый порт.

В момент входа сеть трафик "теряет цвет" откуда он пришел.

Представь: пришел траф на твой аплинк с /24, которая у тебя прописана уже как валидная клиентская.

Как отличить первый траф от второго?

ОК, случай такой:

У RETN 2 клиента - х и у.

ООО Рога и Копыта включается в х и у.

И в какой-то момент у них сильно перекосился трафик и они на часть своих анонсов в х сунули препенд. Исходняк который прет через х подропается.

 

p.s. Кстати это одна из причин по которой я против присутствия на IX.

Изменено пользователем DelSt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Janus

Тогда объясните почему РЕТН не пожаловался на участника, который вливал в него трафик через ix? Вычислить мак-адрес подлеца и отправить жалобу администрации IX.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пусть тебе Савва ВСЮ историю раскажет, вместе с названием клиента.

 

Да пожалуйста. МФТИ. Дело было давно, поэтому я уже не помню, почему именно РЕТН по крайней мере часть их анонсов видел не через нас (мы были клиентами ретна, а мфти - нашим). По-моему, МФТИ тупо часть сетей нам не анонсили по каким-то своим причинам, и надо сказать - имели полное право этого не делать. В любом случае, DelSt привел достаточно примеров, когда применение rpf на BGP линках приводит к проблемам.

Изменено пользователем Savaoff

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ОК, случай такой:

У RETN 2 клиента - х и у.

ООО Рога и Копыта включается в х и у.

И в какой-то момент у них сильно перекосился трафик и они на часть своих анонсов в х сунули препенд. Исходняк который прет через х подропается.

Нифига не дропается. И никогда не дропался при наличии анонса на клиентском стыке. То, что он не best - пофиг, при включённой на Джуне опции 'urpf feasible-paths'

 

Но Janus прав, от клиента надо пропускать любой трафик. Впрочем, не совсем любой. Фейковые source ip типа приватных, то есть вообще не предполагающие ответного трафика, есть мусор, который надо давить на первом же хопе. С этим хорошо справляется urpf loose mode, которым и тирваны не брезгуют

 

p.s. Кстати это одна из причин по которой я против присутствия на IX.

Были случаи, когда клиент, отдавая на аплинковом стыке агрегат и на ix-е его морспецифики, нимало этим не смущался, будучи в полной уверенности, что это его неотъемлемое право. Но urpf - не самый убедительный способ указать такому поборнику "свободы анонсов" на его неправоту. Потому от этого средства убеждения уже очень давно отказались

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нифига не дропается. И никогда не дропался при наличии анонса на клиентском стыке. То, что он не best - пофиг, при включённой на Джуне опции 'urpf feasible-paths'

Не анонсировать свои префиксы аплинку есть святое право клиента.

 

Но Janus прав, от клиента надо пропускать любой трафик. Впрочем, не совсем любой. Фейковые source ip типа приватных, то есть вообще не предполагающие ответного трафика, есть мусор, который надо давить на первом же хопе. С этим хорошо справляется urpf loose mode, которым и тирваны не брезгуют

Для клиентов без bgp я ACL'ем убиваю трафик сорс-адрес которого не из диапазона клиента - об этом и тема.

 

Были случаи, когда клиент, отдавая на аплинковом стыке агрегат и на ix-е его морспецифики, нимало этим не смущался, будучи в полной уверенности, что это его неотъемлемое право. Но urpf - не самый убедительный способ указать такому поборнику "свободы анонсов" на его неправоту. Потому от этого средства убеждения уже очень давно отказались

Такой трафик надо дропать однозначно :) А как теперь боритесь с этим?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Janus

Тогда объясните почему РЕТН не пожаловался на участника, который вливал в него трафик через ix? Вычислить мак-адрес подлеца и отправить жалобу администрации IX.

Администрация IX не является третейским судьей в спорах его members на предмет routing policy. Принимать какие бы то ни было меры в отношении "виновного" у него нет никаких прав. Да и технических средств доказать его "неправоту" у IX-а нет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.