| 1.1, ryoken (ok), 10:23, 20/03/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 >>23 тысячи уязвимых TFTP-серверов
Подскажите, с целью повышения уровня образованности. А для каких нужд может понадобиться вывешивать TFTP наружу?
| | |
| |
| |
| 3.17, ryoken (ok), 10:59, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Ты не поверишь, но чего только не вывешивают наружу :-)
Ну да, знаю, какой-нить монстрософт на принтеры в офезе вполне может белых IP наляпать... Но всё же :).
| | |
| |
| |
| 5.46, ryoken (ok), 15:49, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
> у ipv6 белые и пушистые. Не только лишь все вспоминают прикрыть их
> фаерволом.
Подскажите, а TFTP работает по IPv6? :) (мой домашний чисто по IPv4 пашет, про второй вариант я как-то и не думал :) )
| | |
|
|
|
| 2.6, Аноним (6), 10:33, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не для нужд, а в силу "раз-раз-и-поехали-в-продакшн", может кажется любой сервер/протокол вывешен наружу оказаться.
| | |
| 2.9, Аноним (9), 10:39, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Какие-нибудь Микротыки додумаются, чтобы прошивки обновлять через иент сразу в девайс.
| | |
| |
| 3.18, ryoken (ok), 11:00, 20/03/2024 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Какие-нибудь Микротыки додумаются, чтобы прошивки обновлять через иент сразу в девайс.
e-boot в натуральную величину, ага...
| | |
|
| 2.31, Аноним (31), 12:43, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вообще есть сервис загрузки ОС через PXE сразу из интернета, если комп не грузится и под рукой нет ничего кроме инета, то почему бы и нет
| | |
| |
| 3.33, ryoken (ok), 12:49, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Вообще есть сервис загрузки ОС через PXE сразу из интернета, если комп
> не грузится и под рукой нет ничего кроме инета, то почему
> бы и нет
Такое есть у Apple с их Internet Recovery. Но там вроде бы не tftp, посложнее. А вы какой сервис имели ввиду, можно ссылку?
| | |
| |
| 4.52, Аноним (52), 18:26, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну вот у меня был лет шесть, если не семь, публичный PXE/IPXE эндпоинт для загрузки по сети в популярные линуксы. На пике под сотню клиентов в неделю обслуживал. А потом набежали какие-то боты из ЮВА, стали выжирать полосу и всем портить праздник. Сперва боролся, но по итогу надоела эта возня и я его от интернета отрубил.
| | |
| |
| 5.87, tty0 (?), 15:36, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
ОО аноним, вы ещё не видели, как они питание и интернет проводят - сразу бы поняли, что нужно фейс контроль (баним по IP)
| | |
|
|
|
| 2.62, Аноним (62), 20:54, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Довольно глупый вопрос. Для "вывешивания наружу" не нужно прикладывать сил, в отличие от закрытия. Вопрос зачем его закрывать.
| | |
| 2.95, Аноним (95), 04:27, 23/03/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Подскажите, с целью повышения уровня образованности. А для каких нужд может понадобиться вывешивать TFTP наружу?
Потому как это простой способ сделать работу. Без оверинженеринга, недушно достичь иллюзии. На недолгое время.
| | |
|
| |
| |
| |
| 4.92, Я (??), 13:52, 22/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
обеспечивает доступ к противоправной информации..
| | |
|
|
|
| 1.15, ОноНим (?), 10:46, 20/03/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Потому что не нужно использовать протокол не предназначенный для этих целей.
Есть TCP и используйте его для транспорта данных по типа клиент/сервер, а UDP оставьте для медиа/игро-контента "в одну сторону".
А то придумали уже HTTP на UDP переводить, из-за мнимых 0.01% прироста производительности.
Будто никто не помнит проблем с uTorrent-ом, когда они решили гонять торренты по UDP..
| | |
| |
| 2.19, glad_valakas (-), 11:04, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
там не с uTorrentom проблемы были. а кое-с-чем другим. провайдеры халтурно шейпили юзерский трафик.
| | |
| |
| 3.96, Электрон (-), 06:55, 23/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Нет, uTP при высокой загрузке сети начал швырять еще более мелкими пакетами, перегружая оборудование провайдеров аццким PPS.
| | |
|
| 2.20, Аноним (20), 11:09, 20/03/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
TCP крайне уязвим к потерям пакетов. Это называется Head of Line blocking.
UDP этому не подвержен, потому что не соблюдает порядок приёма пакетов.
Поэтому там не мнимые 0.01 прироста, а прирост на порядки, если ваш протокол уровня приложения умеет не ждать переотправки каждого очередного пакета, а либо собирать их в буфер и запрашивать ретрансмит только потерянных, либо просто игнорировать (например, когда это телефонный звонок).
| | |
| |
| 3.21, Аноним (21), 11:19, 20/03/2024 [^] [^^] [^^^] [ответить]
| –7 +/– |
Если у вас теряются пакеты, это не вина протокола, а линии связи.
Вот так смузихлебы захватили весь мир. Может ещё в джаваскрипт и в браузер закниуть всю логику работы юдп и тцп.
ДНС и другие вещи уже забили гвоздями.
| | |
| |
| 4.23, Аноним (23), 11:28, 20/03/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Вина линии связи, но ответственность перез клиентом -- ваша.
В идеальном мире, конечно, пакет, потерянный БС будет ей же и ретрансмитнут. Но тогда возникнет коллизия, когда пакеты "правильных" клиентов ретрансмитятся быстрее и в большем количестве. Вы же этого не хотите?
Значит ретрансмитить будем end-to-end.
А если e2e, то всё равно ваша машина (которая крайне мало знает о состоянии канала) будет заниматься контролем потока, этого не избежать.
А поскольку большинство программистов заниматься контролем потока не хотят (да и не умеют), и трудно за это их винить, у нас появился system-level TCP. Что, вообще говоря, нонсенс, потому что требования всех приложений разные.
| | |
| |
| 5.48, Аноним (21), 16:42, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Какая коллизия? про окна в тцп никто не читал и фрагментацию/дефрагментацию.
С таким подходом приложение всё должно делать. А так то, что в ОС работает - оно же неправильно работает.
| | |
|
| 4.24, Аноним (9), 11:29, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
А у вас есть возможность влиять на линии связи, особенно, если это не ваша последняя миля?
| | |
| 4.27, CAE (ok), 11:48, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Линии связи имеют конечную пропускную способность. Кроме того, случаются ошибки. Поэтому потери пакетов на TCP/IP сетях в общем случае - это норма, а не исключение. Подробнее vk.com/tcpipquality
| | |
| |
| 5.88, tty0 (?), 15:44, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну да, как правило, в локальном периметре потеря пакетов наблюдается раз в сутки (в основном из-за электрики). А интернет - это куда более многогранная вещь, но и там потери минимальны, а причиной тому - древние технологии или кривые ручки. Поэтому строить поверх удп можно, но выглядит странно, т.к. при низких задержках и высоких потерях проблемы явно нужно решать, а не заметать под ковер
| | |
|
| 4.37, Аноним (37), 14:45, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Если у вас теряются пакеты, это не вина протокола, а линии связи.
Линии связи объективно неидеальны и теряют пакеты, и ничего ты с этим не сделаешь.
| | |
| 4.41, Аноним (-), 15:22, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Если у вас теряются пакеты, это не вина протокола, а линии связи.
Расскажи эту мантру беспроводным сетевым технологиям, чудило. Там потери пакетов или всплески латенси совершенно штатное состояние дел. Не свидетельствующее о проблеме.
Зато когда TCP одупляет полчаса по причине "поезд проскочил тоннель" - да, это очень круто. Чтобы от него избавиться везде где можно и нельзя.
| | |
| |
| 5.49, Аноним (21), 16:46, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Проблема беспроводных систем не должно нарушать логику тцп. Оно совсем не про то. Оно про упорядоченную отправку пакетов адресату. Т.е. поток (stream). А вместо этого лепят неупорядоченный юдп и пытаются собирать эти пакеты в буфере там всяких браузеров и всяких поделий. Зато задержки низкие говорят они. Так они в нормальных условиях и на тцп низкие, если нет потерь пакетов.
| | |
| |
| 6.51, Аноним (-), 17:34, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Проблема беспроводных систем не должно нарушать логику тцп.
Кому нужна эта логика, нужно чтобы работало.
> вместо этого лепят неупорядоченный юдп и пытаются собирать эти пакеты в буфере там всяких браузеров и всяких поделий.
Чем это хуже, чем собирать в буфере всяких ядер и всяких сетевых стеков? Или ты думаешь, в тцп пакеты магическим образом приходят в том же порядке, в котором отправлены были?
| | |
| |
| 7.66, Аноним (66), 22:16, 20/03/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Это не магия, это то чем занимается tcp/ip стек ядра. А тут смузихлебы предлагают это всё отбросить и делать свои поделия в приложениях.
Им же нужно юдп гонять для хттп. Задержки низкие говорят они. Днс надо заворачивать в хттп, безопасно говорят они. И вообще всё надо завернуть в хттп и json, так удобней читать говорят они.
| | |
|
|
|
| 4.54, Аноним (52), 18:30, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Если у вас теряются пакеты, это не вина протокола, а линии связи.
Покажешь как данные без потерь передавать или кроме 127.0.0.1 в жизни никуда не коннектился?
| | |
| 4.65, Аноним (65), 21:04, 20/03/2024 [^] [^^] [^^^] [ответить] | +/– | Не обязательно прям потеря Может быть и просто переупорядочивание пакетов и п... большой текст свёрнут, показать | | |
| |
| 5.67, Аноним (66), 22:25, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
И чем в этой ситуации вам поможет обработка в приложении? Будет затык ещё на контекст свиче, а дальше что?
| | |
| |
| 6.68, Аноним (65), 23:38, 20/03/2024 [^] [^^] [^^^] [ответить] | +/– | Дальше может быть переполнение приёмного буфера и потеря пакета Когда-то случит... большой текст свёрнут, показать | | |
| |
| 7.75, Аноним (21), 08:37, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ой видите ли гугол решил, значит это правильно. Ждут не потому что тцп, а потому что ключи ssl надо передать, установить сессию и т.д.
И всё идет к тому, что грубо ломают модель OSI.
| | |
|
|
|
| 4.93, Я (??), 13:54, 22/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
линии связи будут дырявые это можно только принять. помехи и точки отказа с ростом сети только чаще встречаются. поэтому приходится переходить на протоколы менее чуствительные к качеству линии связи.
| | |
| 4.98, Электрон (-), 07:02, 23/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Отбрасывание пакетов - фундаментальный механизм и вообще modus operandi TCP. Congestion control потому что.
| | |
|
| 3.28, robot228 (?), 11:48, 20/03/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
 БРЕД.
Это как раз таки TCP максимально точный в передаче о чём куча статей от профессионалов написано и я их читал, а UDP как раз-таки с потерями идёт by design.
| | |
| 3.57, Всем Анонимам Аноним (?), 19:28, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Вы путаете. Протокол не уяввим, а congestion algorithm, который за это отвечает, обычно спроектирован в 80х годах и никто не парился особо.
Гугл сделал новый, но до сих пор никто на него не перешел, типа " и так сойдет".
Поэтому им пришлось использовать UDP вроде как временно. Но, похоже, мир настолько консервативный, что придется его оставить надолго
| | |
| 3.71, Аноним (71), 03:57, 21/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Про то, что TCP уже давным давно посылает не по одному пакету и ждёт ACK, а шлёт сразу целую кучу пронумерованных пакетов и ждёт на каждый из них отдельно ACK, сдвигая постепенно окно, конечно же говорить никто не будет, ага. Только не надо утверждать при этом, что HTTP всё равно летать по UDP быстрее будет - вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли. Вы всё равно навесите поверх свою реализацию, только при этом проиграете на том, что не сможете контролировать наполнение канала связи, т.к. UDP просто не способен это делать.
| | |
| |
| 4.73, Аноним (23), 06:29, 21/03/2024 [^] [^^] [^^^] [ответить] | +/– | Можем и сказать, и это хорошая штука, но мера половинчатая То есть, это позво... большой текст свёрнут, показать | | |
| 4.82, Аноним (82), 13:15, 21/03/2024 [^] [^^] [^^^] [ответить] | +/– | TCP строго говоря тоже не способен Он аккуратно разгоняется, чтобы не превыси... большой текст свёрнут, показать | | |
| |
| |
| 6.85, Аноним (82), 14:41, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Можно там всё при желании.
> It is possible to use ECN with protocols layered above UDP. More recent UDP based protocols such as QUIC are using ECN for congestion control.
Вопрос поддержки лучше не поднимать ;) Просто если звёзды сложились неправильно, то про ECN никто никогда и не узнает. Даже в tcp лет 15 ecn готовили к включению в дефолте.
| | |
| |
| 7.86, _oleg_ (ok), 15:22, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
 > Можно там всё при желании.
>> It is possible to use ECN with protocols layered above UDP. More recent UDP based protocols such as QUIC are using ECN for congestion control.
> Вопрос поддержки лучше не поднимать ;) Просто если звёзды сложились неправильно, то
> про ECN никто никогда и не узнает. Даже в tcp лет
> 15 ecn готовили к включению в дефолте.
ECN в UDP это круто, но, если я правильно понял, тут нужна поддержка именно на уровне приложения, в любом случае (даже когда датут этим порулить с этого уровня). В то время, когда с tcp, если оно настроено в ОС, то будет работать для всех.
| | |
| |
| 8.89, Аноним (82), 16:43, 21/03/2024 [^] [^^] [^^^] [ответить] | +/– | Про application level правильное замечание Все эти протоколы нужны для обслужив... большой текст свёрнут, показать | | |
| |
| 9.90, _oleg_ (ok), 16:58, 21/03/2024 [^] [^^] [^^^] [ответить] | +/– | Ну хз что там подходит, что нет Понятно, что чем ждать стандартизации и распрос... текст свёрнут, показать | | |
|
|
|
|
|
| 4.97, Электрон (-), 06:59, 23/03/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли.
Нет, если используется multiplexing потоков внутри этого одного соединения. Следует из высказывания выше про Head of Line Blocking. А QUIC это делает, только не знаю на каком уровне это задействовано в браузерах.
| | |
|
| 3.83, _oleg_ (ok), 13:20, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Если у тебя работает SACK и протокол приложения не умеет работать с потерей части инфы (например http-запрос против видеовещания), то разницы быть заметной не должно между udp и tcp. Один хрен, что там, что там надо ждать дополучения опоздавших перед началом обработки.
Плюс, tcp в отличии от udp имеет window и всякие congestion control алгоритмы, что позволяет не добивать канал, когда он уже и так забит. udp же, если не реализовывать это в приложении, этого не умеет. Если реализовывать, то какой смысл? В итоге получится tcp в userspace.
| | |
|
| 2.22, Аноним (9), 11:26, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
TCP в сообщения заданного размера не может. Тогда уж SCTP. Может и в поток, и в дейтаграммы.
| | |
| |
| 3.76, Аноним (37), 10:53, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
SCTP был бы неплох, если бы не требовал замены полинтернета. Ибо железки его на L4 не умеют.
| | |
|
| 2.26, robot228 (?), 11:47, 20/03/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ты что бобо?
Для игро контента.
Ты зайди в CSGO и поной с тикрейта из-за того что UDP это НЕНАДЁЖНОЕ доставко пакетов.
UDP в целом это как сжатие с потерями. Где-то что-то заглючит.
| | |
| |
| 3.43, Аноним (-), 15:32, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Ты зайди в CSGO и поной с тикрейта из-за того что UDP это НЕНАДЁЖНОЕ доставко пакетов.
> UDP в целом это как сжатие с потерями. Где-то что-то заглючит.
Расскажи это какому-нибудь QUIC ака HTTP/3. Тебе не приходило в голову что из ненадежного слоя всегда можно сделать - надежный? Переотправкой пакетов как раз.
А вот отказаться от медвежьих услуг TCP в вопросах congestion control - роняющим скорость и латенси конекции в плинтус при минимальной потере пакетов или задержке (типичных для беспроводки) - удачи. За это TCP и выпадает постепенно из фавора. Если в Linux еще появились алгоритмы которые сносно живут и с таким, то в какой-нибудь винде оно будет так как сделает какой-нибудь майкрософт своими криворукими индусами, и фиг оспоришь.
| | |
| |
| 4.72, Аноним (71), 04:00, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> А вот отказаться от медвежьих услуг TCP в вопросах congestion control - роняющим скорость и латенси конекции в плинтус при минимальной потере пакетов или задержке (типичных для беспроводки) - удачи
Ага, если не контролировать наполнение канала, то и никаких проблем с ронянием скорости не будет, верим. Может проблема в том, что ваша система настроена через одно место и можно было бы выбрать алгоритм congestion control более подходящий для вашей сети? Спойлер: они есть, и много, и в том числе для минимальных задержек, и их тоже больше чем один.
| | |
| |
| 5.91, Аноним (-), 01:09, 22/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Ага, если не контролировать наполнение канала, то и никаких проблем с ронянием
> скорости не будет, верим. Может проблема в том, что ваша система
> настроена через одно место и можно было бы выбрать алгоритм congestion
> control более подходящий для вашей сети? Спойлер: они есть, и много,
Вот и сделай ЗБС. Всем хомячкам с андроидом. Чо-чо, всего пару миллиардов окучать? Во, приступай. И еще эвон сколько юзеров винды, удачи в настройке.
А, да, если ютуб-плеер не может послать запрос на чанк видео со своей стороны - потому что у винды хзкакая там логика туповэйтинга - окей, а сервер чанков не телепат, и даже если нарулит со своей стороны более другой congestion - то это ему не поможет. Ибо какой чанк захочет юзер он заранее не знает. А в винде - см. про майкрософт и индусов.
| | |
|
|
|
| 2.58, Всем Анонимам Аноним (?), 19:31, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
они перешли на UDP из-за того, что народ congestion algo не могут поменять по-умолчанию, тормозят.
фактически это TCP по UDP с нормальным congestion algorithm
И дает он не всегда 0.01%, а в зависимости от условий. Если ваш провайдер жадный и у него внешний канал до 100% доходит, то там он вообще незаменим будет. (А такие провайдеры есть, например Центртелеком в Сочи).
| | |
| 2.64, Аноним (62), 20:58, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Потому что не нужно использовать протокол не предназначенный для этих целей
Нет никаких предназначений протоколов, вы это придумали в силу неграмотности. UDP от TCP отличается не дуплексностью и не клиент-серверностью, а упорядочиванием пакетов и ретраями. Там где последние не нужны или там где в TCP они работают не подходязим под задачу образом будет использоваться UDP, и вас не спросят.
| | |
| |
| 3.94, Я (??), 14:01, 22/03/2024 [^] [^^] [^^^] [ответить]
| +/– | |
протокол предназначения..
Выяснить, не на Скеллиге ли пакеты
Выяснить, не в Велене ли пакеты
Выяснить, не в Новиграде ли пакеты
| | |
|
| 2.69, Аноним (52), 23:58, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Потому что не нужно использовать протокол не предназначенный для этих целей.
В RFC 768 во введении чётко указано для чего нужен UDP. Прочитай, там всего пять предложений, много времени не займёт. После этого можешь начинать объяснять, что не так с HTTP по UDP.
| | |
|
| 1.29, ИмяХ (ok), 12:25, 20/03/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 >>UDP
>>вернёт ответ
Что за бред я сейчас прочитал? UPD протокол в принципе не подразумевает ответов.
| | |
| |
| 2.32, 1 (??), 12:47, 20/03/2024 [^] [^^] [^^^] [ответить]
| +5 +/– |
UDP не подразамевает, а сервис совсем даже требует (например DNS).
| | |
| 2.35, Big Robert TheTables (?), 13:18, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
не совсем относится к данному случаю, но вообще UDP в 99% случаев имеет статусный ответ, просто он приходит по ICMP. Повторная отправка на непрослушиваемый порт вернет отправителю ошибку в linux. Это интересная системная специфика, описана в man 7 udp.
| | |
| 2.38, Аноним (38), 14:45, 20/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Пожалуйста почитайте и попытайтесь понять статью прежде чем комментировать.
| | |
| |
| 3.79, Аноним (79), 12:27, 21/03/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Скорее всего вы со своим ответом мимо кассы. Человек формально рассуждает (в доказательном ИТ так),
что протокол UDP сам по себе не отвечает, а отвечают багованные сервисы.
На бытовом уровне все понятно, но любой формальный ревью тех. документации статья не пройдет.
Я бы предложил всем вам и топикстартеру быть более лояльными, но понимаю, что бесполезно.
| | |
|
| 2.59, Sem (??), 19:33, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Не надо путать "ответные пакеты" и подтверждающие пакеты (ACT).
| | |
|
| 1.34, Big Robert TheTables (?), 13:08, 20/03/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Друзья, пришлите бригаду разъяснительную по вот этому моменту в рфц3704:
RFC 2827 recommends that ISPs police their customers' traffic by
dropping traffic entering their networks that is coming from a source
address not legitimately in use by the customer network.
Как же так - дропать трафик, который не из твоей сетки. Если хост на периметре, у него весь трафик извне. Что имеется в виду?
| | |
| |
| 2.40, Аноним (37), 14:53, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Здесь "their" относится к ISP. Т.е. если от клиента (к провайдеру) идёт трафик с адресов, которые не выделены провайдером для этого клиента, то такой трафик дропать.
| | |
| |
| 3.77, Big Robert TheTables (?), 11:46, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Здесь "their" относится к ISP. Т.е. если от клиента (к провайдеру) идёт
> трафик с адресов, которые не выделены провайдером для этого клиента, то
> такой трафик дропать.
отлично, логично. Тут получается как бы вопрос сетевого этикета. "Социальный рейтинг" клиентов вести, кто чаще косячит - тому выговор
| | |
| |
| 4.99, Аноним (52), 00:40, 24/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Не надо изобретать никакого социального рейтинга и выговоров. Учёт трафика для биллинга надо делать до фильрации. Если клиенту хочется посылать какую-то хрень, пусть шлёт. Я-то со своей стороны и алерт отправлю, и даже может быть какую-то часть счёта прощу в случае серьёзных проблем или взлома у клиента, но пока не изобретут роутеры с неограниченной пропускную способностью, иначе не имеет смысла делать.
| | |
|
|
| 2.47, Фняк (?), 16:41, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Это значит что ты как isp знаешь какие адреса ты выделил клиенту. И если от клиента идёт трафик с исходящими адресами не из диапазона данного клиента, то надо бы этот трафик дропать. Более того, говорится что делать это нужно на стыке твоей сети с клиентской
| | |
| |
| 3.78, Big Robert TheTables (?), 11:47, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Это значит что ты как isp знаешь какие адреса ты выделил клиенту.
> И если от клиента идёт трафик с исходящими адресами не из
> диапазона данного клиента, то надо бы этот трафик дропать. Более того,
> говорится что делать это нужно на стыке твоей сети с клиентской
Да, разобрались, благодарю, это направление исходящего трафика обозначено.
| | |
|
|
| 1.36, Аноним (36), 14:19, 20/03/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Про RFC 3704 Стандартная рекомендация уже лет тридцать:
Правило: any мойсервер протокол
Должно быть заменено на:
(Всё кроме моей сети) мойсервер протокол
Как раз во избежании атак такого типа
| | |
| |
| |
| 3.56, Аноним (55), 18:34, 20/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
пока не будет наказания за халатное отношение, так и будем все участвовать в ддосах.
| | |
|
|
| |
| 2.80, Аноним (79), 12:31, 21/03/2024 [^] [^^] [^^^] [ответить]
| +/– |
Зачем дуплекс для одной строки текстовой?
UDP здесь - верный выбор.
| | |
|
|
