Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Кроссавчеги -)) 28.04.07 09:33 Число просмотров: 1813
Автор: HandleX <Александр М.> Статус: The Elderman
|
> > клиентов. Хотя... Вот скажите положа руку на сердце, если
> > NAT предлагает по сути кэширующий DNS сервер, вы бы
> > отказались от его услуг внутри локалки? ;-)
> Тогда это будет уже внутренний DNS, причём с вероятно
> недостоверной информацией ;)
Ответы DNS серверов ВСЕГДА "вероятно недостоверны", обычно после смены параметров на сервере, ответственного за тот или иной домен, это некоторое время (часа 3) "ползёт" на корневые сервера, а через какое время нижележащие сервера "соизволят" обратится к ним -- один Бог и админы, которые их настраивали, ведают. Этот как свет звёзд, который летит к нам годы, и никто не знает, что там "на самом деле" происходит.
> Тут божий дар, как грится, с яичницей мешать не следует (по
> крайней мере известные мне вендоры этого не делают, могу
> ошибаться).
Гы-гы, DNS сервер провайдера — не истина в последней инстанции -))
> > Это грязные трюки, которые работают, но если исходить из
> > того, что клиентская программа и методы коммуницирования по
> > UDP суть "чёрный ящик" для шлюза, т.е. шлюзы не должны
> > лезть в пользовательские части UDP пакета, иными словами. в
> > поле "Data" UDP-пакета. Простейший пример — клиент и сервер
> > шифруют UDP пакеты, что тогда делать шлюзу? И описания
> > "'лезет на тот порт, на этот порт ответы" нету, или они по
> > сложно реверсируемому закону... Всё, шлюз не при делах.
> Если мы шифруем все поля датаграммы\сегмента (IP и порт в т.ч),
Я не говорил того, что шифруем ПОЛЯ пакета, там речь идёт не о полях, а о пользовательской части данных датаграммы.
> Шлюз с натом не при делах, как я себе
> понимаю, только потому что после подмены не удаётся
> расшифровать данные.
Нет, он остаётся ни при делах только потому, что не знает КОМУ во внутренней сету доставить данные ОБРАТНО, потому что в UDP не заложен механизм "обратно", его реализуют на уровне приложений программеры. Со своими собственными жирными тараканами в бошках -))
> > Хех, откуда ушло туда пришло... А теперь сценарий — два
> > хоста внутри локалки лезут по UDP на сервер C в инете на
> > порт 10000... Нат действует по предложенному тобой
> > принципу... И что прикажешь ему делать — дублировать
> > "обратно" принятые от С пакеты для каждого из этих двух
> > хостов на порт 10000? Или только первому? Или только второму? ;-)
> Элементарно ;)
> Исходных пакетов 2:
> (A:A1 - C:10000) - с хоста А с порта А1 идёт пакет на
> С:10000 и
> (B:B1 - C:10000) - с хоста B с порта B1 идёт пакет на
> С:10000.
Начнём с того, что A1 и B1 в заголовке UDP опциональны. Прикольно, да? -))
> Пусть есть шлюз D с натом и A1=B1. Тогда по пришествии на
> шлюз NAT подменит исходные пакеты до вида
> (D:D1 - C:10000) и (D:D2 - C:10000), причём D1 != D2,
> сделав 2 соответствующие записи в натной таблице: типа если
> придёт пакет с C:10000 на D:D1, отослать его на A:A1 и
> грохнуть запись, время жизни такое-то (это будет
> инициализация NAT исходящим пакетом).
Очень хорошо. Но вы думаете за разработчиков. А они не обязаны и чаще всего не шлют обратный пакет на тот порт, что был указан в заголовке датаграммы, могут его не указывать, более того, часто там что-то вроде этого: "софтина пуляет серваку на порт xxxx, оно отвечает ему на yyyy" и всё. Кранты, наш хитрый план натченья UDP провалился, если мы не знаем подробностей "протокола" на уровне приложений.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
