Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
аки медведы ;) 28.04.07 10:03 Число просмотров: 1494
Автор: Ustin <Ustin> Статус: Elderman
|
> Ответы DNS серверов ВСЕГДА "вероятно недостоверны", обычно
> после смены параметров на сервере, ответственного за тот
> или иной домен, это некоторое время (часа 3) "ползёт" на
> корневые сервера, а через какое время нижележащие сервера
> "соизволят" обратится к ним -- один Бог и админы, которые
> их настраивали, ведают. Этот как свет звёзд, который летит
> к нам годы, и никто не знает, что там "на самом деле"
> происходит.
В нормальных ДНС серверах есть механизм обновления. В предлагаемом варианте его НЕТ (в противном счае это нат и днс отдельно, поднятые на одном хосте, или мы ходим каждый раз наверх, что отменяет слово "кеширующий"), => достоверность данных такой поделухи относительно регулярного DNS сервера объективно ниже.
> Гы-гы, DNS сервер провайдера — не истина в последней
> инстанции -))
Не спорю ;)
> Я не говорил того, что шифруем ПОЛЯ пакета, там речь идёт
> не о полях, а о пользовательской части данных датаграммы.
А если так, то что? Шифруем на уровне приложений - значит контрольная сумма считается от "правильных" данных.
Во всех книгах написано и жизнь показывает, что СОВОКУПНОСТЬ ХОСТ\ПОРТ ЯВЛЯЕТСЯ НЕОТЪЕМЛЕМОЙ ЧАСТЬЮ UDP ДАТАГРАММЫ! Это к вопросу о красавчегах.
> > Шлюз с натом не при делах, как я себе
> > понимаю, только потому что после подмены не удаётся
> > расшифровать данные.
> Нет, он остаётся ни при делах только потому, что не знает
> КОМУ во внутренней сету доставить данные ОБРАТНО, потому
> что в UDP не заложен механизм "обратно", его реализуют на
> уровне приложений программеры. Со своими собственными
> жирными тараканами в бошках -))
NAT aka Network adress translation является механизмом трансляции сетевых адресов, одним из способов взаимодействия частной и глобальной сети. И в данные он лезет (за искл контрольных сумм) в случае трансляции ICMP датаграмм. В случае ICMP никакого "port" нет, и вот тет-то и надо применить недюжинные усилия для сохранения "прозрачности" NAT.
> Начнём с того, что A1 и B1 в заголовке UDP опциональны.
> Прикольно, да? -))
Угу, читаем ман, убиваем такой пакет как некорректный, пока он не повесил наш роутер ;)
> Очень хорошо. Но вы думаете за разработчиков. А они не
> обязаны и чаще всего не шлют обратный пакет на тот порт,
> что был указан в заголовке датаграммы, могут его не
> указывать, более того, часто там что-то вроде этого:
> "софтина пуляет серваку на порт xxxx, оно отвечает ему на
> yyyy" и всё. Кранты, наш хитрый план натченья UDP
> провалился, если мы не знаем подробностей "протокола" на
> уровне приложений.
UDP - протокол транспортного уровня, причём тут уровень приложений?
Если слать ответ на порт yyyy, никак не фигурирующий в исходной посылке, на клиентской тачке надо поднимать _серверный сокет_, слушающий этот самый yyyy. Собсно в аське этот механизм есть, юзается для p2p коннектов. Как я понял, исходная задача этого не требовала.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
