Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Тогда это будет уже внутренний DNS, причём с вероятно недостоверной информацией... 28.04.07 00:03 Число просмотров: 1637
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 28.04.07 00:11 Количество правок: 1
|
to networking?
> Может и так. Но скорее всего, они просто тщательно изучили
> стандарт DNS и именно из-за того, что формат и протокол
> жёстко стандартизированы, делают всё корректно, что не
> всегда удаётся для зоопарка реализаций UDP
> коммуницирования. Это возможно, но проще самому шлюзу
> представлятся эдаким виртуальным сервером DNS, хотя та
> реализация, о которой Вы говорите, более гибче для
> клиентов. Хотя... Вот скажите положа руку на сердце, если
> NAT предлагает по сути кэширующий DNS сервер, вы бы
> отказались от его услуг внутри локалки? ;-)
Тогда это будет уже внутренний DNS, причём с вероятно недостоверной информацией ;)
Тут божий дар, как грится, с яичницей мешать не следует (по крайней мере известные мне вендоры этого не делают, могу ошибаться).
> Это грязные трюки, которые работают, но если исходить из
> того, что клиентская программа и методы коммуницирования по
> UDP суть "чёрный ящик" для шлюза, т.е. шлюзы не должны
> лезть в пользовательские части UDP пакета, иными словами. в
> поле "Data" UDP-пакета. Простейший пример — клиент и сервер
> шифруют UDP пакеты, что тогда делать шлюзу? И описания
> "'лезет на тот порт, на этот порт ответы" нету, или они по
> сложно реверсируемому закону... Всё, шлюз не при делах.
Если мы шифруем все поля датаграммы\сегмента (IP и порт в т.ч), то для того, чтобы это куда-нибудь ушло, необходимо инкапсулировать шифровку во что-то доставляемое, иначе нас убьёт первый же маршрутизатор ;) В IPSec это будет инкапсуляция IP в IP и передача UDP датаграммы между концами туннеля. Шлюз с натом не при делах, как я себе понимаю, только потому что после подмены не удаётся расшифровать данные.
> Хех, откуда ушло туда пришло... А теперь сценарий — два
> хоста внутри локалки лезут по UDP на сервер C в инете на
> порт 10000... Нат действует по предложенному тобой
> принципу... И что прикажешь ему делать — дублировать
> "обратно" принятые от С пакеты для каждого из этих двух
> хостов на порт 10000? Или только первому? Или только
> второму? ;-)
Элементарно ;)
Исходных пакетов 2:
(A:A1 - C:10000) - с хоста А с порта А1 идёт пакет на С:10000 и
(B:B1 - C:10000) - с хоста B с порта B1 идёт пакет на С:10000.
Пусть есть шлюз D с натом и A1=B1. Тогда по пришествии на шлюз NAT подменит исходные пакеты до вида
(D:D1 - C:10000) и (D:D2 - C:10000), причём D1 != D2, сделав 2 соответствующие записи в натной таблице: типа если придёт пакет с C:10000 на D:D1, отослать его на A:A1 и грохнуть запись, время жизни такое-то (это будет инициализация NAT исходящим пакетом). Далее сервер C сформирует 2 ответа (C:10000 - D:D1) и (C:10000 - D:D2), которые благополучно дойдут до D (если не дойдут, то никто ни о чём не узнает, UDP протокол не гарантирует доставку => обработку потерь и дублирований ДОЛЖЕН взять на себя клиент). D берёт запись из таблицы NAT, подменяет хост\порт и благополучно роутит по назначению.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
