Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Прочитал мануал... Потестил... 27.04.07 18:13 Число просмотров: 1517
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 27.04.07 18:29 Количество правок: 1
|
На клиенте за нат адрес DNS и прописывают равным адресу шлюза???
Это не так! Всё работает обычным port natом, пример тому - zyxel omni adsl мопеды.
Модем роутит пакеты, на внешнике поднят нат TCP&UDP+ICMP (это реализовано в железке). Прописываем ДНС провайдера на виндовой тачке и всё работает. Ещё более "прямой" эксперимент: tcpdump udp port 53, все пакеты строго согласованы по портам.
> > > При UDP сервер не обязан отвечать на какой порт
> принимать
> > > "обратные" пакеты, там нет понятия соединений,
> нет
> > > подтверждений, и нету "туда-обратно".
Это уже надо рассматривать протокол, например FTP в пассивном режиме, как я себе понимаю, тоже представляет определённые трудности для разработчиков NAT. В этих случаях делается "инспектор протокола" в терминологии Kerio.
> Нет... Сервер может не отвечать на UDP запросы, а может
> отвечать, но на другой порт... Всё определяю правила,
> прописываемые вручную для тяжких случаев, но бывает, что
> разработчики прокси предоставляют шаблоны для популярных
> программ и их проприетарным протоколам.
Согласен
>Ещё бывают такие
> случаи, когда проброс "обратно" для какой-нибудь софтины
> внутри локалки возможен ТОЛЬКО ДЛЯ ОДНОГО ХОСТА внутри этой
> сети.
Согласен, когда таблица NAT инициализируется руками ;)
А что мешает реализовать "правильный" обмен (откуда-пришло-туда-ушло)? Как я понял из прочтения 9 и 20 глав 1 тома "Сети TCP/IP" Д.Камера, такая конструкция не требует инспектора протокола и будет отлично работать из-за любого стандартного NAT.
PS: извиняюсь, что не в тему...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
