Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1
RSS
Настройка работы traceroute через FW(NAT)
 
Пользуюсь Checkpoint FW-1 и в нем для работы локалки естественно работает NAT.
В общем проблема в том что traceroute не показывает промежуточные хосты при запуске с локального адреса. Теоретически и не должен, поскольку ICMP ответ от промежуточного хоста FW не знает куда пересылать.
Но есть ли какой-то способ настроить Checkpoint чтобы он догадывался кому пересылать ответы от промежуточных хостов?

Вот например как выглядит tracert www.ru из локалки.

Трассировка маршрута к www.ru [194.87.0.50]
с максимальным числом прыжков 30:

  1    <1   мс &nbs p;   *     1  мс  10.254.1.1
      2     ;  ;*       *     *    &nb sp;Превышен  интервал ожидания для запроса
      3     ;  ;*       *        *     Превышен интервал ожидания для запроса
      4     ;  ;*       *        *     Превышен интервал ожидания для запроса
    5     *   *        *     Превышен интервал ожидания для запроса
    6     *    *        *     Превышен интервал ожидания для запроса
    7     *     *        *     Превышен интервал ожидания для запроса
    8     *     *        *     Превышен интервал ожидания для запроса
    9     *    *        *     Превышен интервал ожидания для запроса
 10     *      *        *     Превышен интервал ожидания для запроса
11    35 ms    40 ms    30 ms  www.ru [194.87.0.50]

Трассировка завершена.
 
сама теория непонятна. то есть допустим идет от хоста 10.1.1.100 пакет UDP с полем TTL 5 на хост 195.1.1.1 через FW. FW(NAT) подменяет адрес пакета на свой, и отсылает дальше, запоминая откуда пакет пришел и куда ушел.
На пятом маршрутизаторе поле становится нулем. и маршрутизатор кидает ICMP пакет на FW типа - не дошло. FW  получает и кому он должен перенаправить то?
он запомннил что от хоста 10.1.1.100 ушел пакет на хост 195.1.1.1. а ответ приходит от левого хоста на FW. Как сопоставить что надо перенаправить этот ICMP на 10.1.1.100?
 
fw получает icmp time exided, лезет его данные. в данных находится ip заголовок убитого icmp пакета.
чекпойнт просматривает свою таблицу трансляции и смотрит, что да - действительно, отсылался такой пакет от 10.1.1.100, после чего натит адреса в пакете и в поле данных. но как написано в <линк смотри в аське>, он неправильно подсчитывает контрольную сумму icmp. соответсвенно принимающая сторона его не обрабатывает. но пакет реально доходит до отправителя icmp запроса.

солюшен #0 - забить, и трейсить с чекпойнта.
солющен #1 - написать патч для cp fw-1.
солюшен #2 - написать патч для трейаса (или трейс на сырых сокетах), который бы плевал на ошибку crc в icmp.
солюшен #4 - забить и пойти попить пива ;-)
 
В icmp пакете типа "кончился ТТЛ" вложен кусок оригинальной датаграммы. По ней порядочный НАТ демон может узнать кому именно переслать это сообщение.

Подробности можешь помотреть в сорцах natd:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libalias/

;--------
;NK
 
Короче резюмирую:
Чекпойнт такие вещи делать не дает.
Нормальный НАТ (например кошачий) отрабатывает нормально...
 
Да, про заголовок в ответе icmp я не знал.
И про то, что только в Checkpoint такая странность есть не знал.
Спасибо, Люди
Теперь задумался над отличием time-exceeded и ttl-exceeded и над тем где бы найти патч. Подписка кончилась :(
 
что-то вы обманываете. у меня все это работает с чекпоинтом FW-1 . хотя честно признаюсь, что я в нем не ковыряюсь, он на аутсорсинге.
 
в птсек по слухам есть сертифицированные чекпоинтисты, пусть ответят.
 
я думаю, ключевое слово у ксивы - "подписка кончилась" :-)
Наверняка уже запатчили...
 
угу.
 
CheckPoint Firewall FP3
 1   <10 мс   <10 мс   <10 мс  192.168.0.x
 2   <10 мс   <10 мс   <10 мс  <cut>
 3    10 ms   <10 мс    10 ms  <cut>
 4    10 ms   <10 мс    10 ms  <cut>
 5    10 ms    20 ms    20 ms  <cut>
 6    30 ms   <10 мс    10 ms  cisco13.Moscow.gldn.net
 7   <10 мс   <10 мс    10 ms  cisco02.Moscow.gldn.net
 8    40 ms    10 ms    10 ms  cat01.Moscow.gldn.net
 9   <10 мс    10 ms    10 ms  mail.ru [194.67.57.51]
Страницы: 1
Читают тему