Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
До сих пор полностью автоматически нигде не реализовано. 27.04.07 18:41 Число просмотров: 1688
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 27.04.07 18:48 Количество правок: 3
|
> На клиенте за нат адрес DNS и прописывают равным адресу
> шлюза???
> Это не так! Всё работает обычным port natом, пример тому -
> zyxel omni adsl мопеды.
> Модем роутит пакеты, на внешнике поднят нат
> TCP&UDP+ICMP (это реализовано в железке). Прописываем
> ДНС провайдера на виндовой тачке и всё работает, или
> прошивка модема "вылавливает" днс запросы и модифицирует
> их?
Может и так. Но скорее всего, они просто тщательно изучили стандарт DNS и именно из-за того, что формат и протокол жёстко стандартизированы, делают всё корректно, что не всегда удаётся для зоопарка реализаций UDP коммуницирования. Это возможно, но проще самому шлюзу представлятся эдаким виртуальным сервером DNS, хотя та реализация, о которой Вы говорите, более гибче для клиентов. Хотя... Вот скажите положа руку на сердце, если NAT предлагает по сути кэширующий DNS сервер, вы бы отказались от его услуг внутри локалки? ;-)
> Это уже надо рассматривать протокол, например FTP в
> пассивном режиме, как я себе понимаю, тоже представляет
> определённые трудности для разработчиков NAT. В этих
> случаях делается "инспектор протокола" в терминологии
> Kerio.
Это грязные трюки, которые работают, но если исходить из того, что клиентская программа и методы коммуницирования по UDP суть "чёрный ящик" для шлюза, т.е. шлюзы не должны лезть в пользовательские части UDP пакета, иными словами. в поле "Data" UDP-пакета. Простейший пример — клиент и сервер шифруют UDP пакеты, что тогда делать шлюзу? И описания "'лезет на тот порт, на этот порт ответы" нету, или они по сложно реверсируемому закону... Всё, шлюз не при делах.
> Согласен, когда таблица NAT инициализируется руками ;)
> А что мешает реализовать "правильный" обмен
> (откуда-пришло-туда-ушло)? Как я понял из прочтения 9 и 20
> глав 1 тома "Сети TCP/IP" Д.Камера, такая конструкция не
> требует инспектора протокола и будет отлично работать из-за
> любого стандартного NAT.
Хех, откуда ушло туда пришло... А теперь сценарий — два хоста внутри локалки лезут по UDP на сервер C в инете на порт 10000... Нат действует по предложенному тобой принципу... И что прикажешь ему делать — дублировать "обратно" принятые от С пакеты для каждого из этих двух хостов на порт 10000? Или только первому? Или только второму? ;-)
|
|
|
подробно о проекте
Анализ криптографических сетевых... 
