Jump to content
Калькуляторы

Juniper MX80 & MS-MIC-16G

Всем доброго времени суток!

 

Недавно приобретен Juniper MX80 и сервисная карта MS-MIC-16G для предоствления доступа в интернет по средствам NAT.

Общую конфигурацию накидали и на первый взгляд все работает, но при ближайшем рассмотрении столкнулись с несколькими проблемами:

 

1. Не проходит от клиента за натом трассировка маршрута, выглядит это следующим образом:

 

tracert ya.ru
Трассировка маршрута к ya.ru [213.180.204.3]
с максимальным числом прыжков 30:
1 1 ms <1 мс <1 мс 10.10.20.1
2 * * * Превышен интервал ожидания для запроса.
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
5 * * * Превышен интервал ожидания для запроса.
6 * * * Превышен интервал ожидания для запроса.
7 * * * Превышен интервал ожидания для запроса.
8 * * * Превышен интервал ожидания для запроса.
9 * * * Превышен интервал ожидания для запроса.
10 13 ms 13 ms 13 ms www.yandex.ru [213.180.204.3]

 

В тот же момент ping проходит:

 

ping ya.ru
Обмен пакетами с ya.ru [93.158.134.3] по 32 байт:

Ответ от 93.158.134.3: число байт=32 время=13мс TTL=53
Ответ от 93.158.134.3: число байт=32 время=13мс TTL=53
Ответ от 93.158.134.3: число байт=32 время=13мс TTL=53
Ответ от 93.158.134.3: число байт=32 время=13мс TTL=57

Статистика Ping для 93.158.134.3:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 13мсек, Максимальное = 13 мсек, Среднее = 13 мсек

 

Хотя applications настроены:

 

applications
application dns-udp-10s {
   protocol udp;
   source-port 1-65535;
   destination-port 53;
   inactivity-timeout 10;
}
application https-1800s {
   protocol tcp;
   destination-port 443;
   inactivity-timeout 1800;
}
application icmp-30s {
   protocol icmp;
   inactivity-timeout 30;
}
application traceroute-30s {
   application-protocol traceroute;
   protocol udp;
   destination-port 33435-33450;
   ttl-threshold 30;
   inactivity-timeout 30;
}
application xmpp-1800s {
   protocol tcp;
   destination-port 5222-5223;
   inactivity-timeout 1800;
}
application smtp-ssl {
   protocol tcp;
   destination-port 465;
}
application pop3-ssl {
   protocol tcp;
   destination-port 995;
}
application-set ALG-SET-noEIM-noEIF {
   application junos-http;
   application junos-ftp;
   application junos-rtsp;
   application dns-udp-10s;
   application https-1800s;
   application icmp-30s;
   application xmpp-1800s;
   application traceroute-30s;
   application junos-ntp;
   application junos-telnet;
   application junos-rsh;
   application junos-ssh;
   application junos-pop3;
   application junos-smtp;
   application junos-imap;
   application junos-imaps;
   application pop3-ssl;
   application smtp-ssl;
   application junos-pptp;
   application junos-rpc-portmap-tcp;
   application junos-rpc-portmap-udp;
   application junos-tftp;
}
application-set ALG-SET-EIM-EIF {
   application junos-h323;
   application junos-sip;
}

 

Firewall-ы пробовали выключать вообще все которые есть.

 

==========

 

2. Никак не удается настроить проброс портов во внуторь за NAT.

Причем если делать проброс порт в порт (например 3389 в 3389)

или вообще bi-nat то все работает,

а (например 10500 в 3389) не получается

 

match-direction output;
term t1 {
   from {
       destination-address {
           ХХ.ХХ.ХХ.ХХ/32;
       }
       destination-port {
           range low 3000 high 10000;
       }
   }
   then {
       port-forwarding-mappings map1;
       translated {
           destination-prefix 10.10.20.30/32;
           translation-type {
               dnat-44;
           }
       }
   }
}

port-forwarding map1
destined-port 10000 translated-port 3389;

 

Прошу подсказать в какую сторону смотреть.

Share this post


Link to post
Share on other sites

1. Не проходит от клиента за натом трассировка маршрута, выглядит это следующим образом:

 

В ОС Шиндоуз для traceroute используется протокол ICMP. Если перенастроить соответствующим образом application, то возможно трейс пойдет.

Share this post


Link to post
Share on other sites

Действительно не проходит трассировка только с OC Windows...

 

Если перенастроить соответствующим образом application, то возможно трейс пойдет.

 

Я уже перепробовал различные варинаты, остановился на рекомендуемом джунипером:

 

show applications application icmp-30s
application-protocol icmp;
inactive: protocol icmp;
inactive: icmp-type time-exceeded;
inactive: inactivity-timeout 30;

 

Все равно не работает.

 

И подскажите правильно ли я понимаю, сексию application надо вешать в правило натирования?

 

match-direction input;
term t1 {
   from {
       source-address {
           10.10.20.0/24;
       }
       application-sets ALG-SET-noEIM-noEIF;
   }
   then {
       translated {
           source-pool np1;
           translation-type {
               napt-44;
           }
           address-pooling paired;

Share this post


Link to post
Share on other sites

Я уже перепробовал различные варинаты, остановился на рекомендуемом джунипером:

 

Сам я подобное не настраивал и мануалы, соответственно, не читал, поэтому могу только провести теоретическое изыскание методом экстраполяции имеющихся данных на поставленную задачу.

 

Итак, у нас есть рабочий UDP traceroute, который, очевидно, обеспечивается правилом

application traceroute-30s {
   application-protocol traceroute;
   protocol udp;
   destination-port 33435-33450;
   ttl-threshold 30;
   inactivity-timeout 30;
}

Раз он работает, то правило, вероятно, привязано туда, куда нужно.

 

Основываясь на этих фактах, я бы добавил правило

application traceroute-icmp-30s {
   application-protocol traceroute;
   protocol icmp;
   ttl-threshold 30;
   inactivity-timeout 30;
}

и поставил бы его в application-set'е выше любых других правил, связанных с icmp и traceroute.

 

Вы пробовали такой вариант?

 

ЗЫ: поскольку изыскание теоретичское, то успех, естесственно, не гарантирован.

Edited by agr

Share this post


Link to post
Share on other sites

ЗЫ: поскольку изыскание теоретичское, то успех, естесственно, не гарантирован.

 

 

вы не учитываете одного фактора , это может быть баг :)

Share this post


Link to post
Share on other sites

вы не учитываете одного фактора , это может быть баг :)

 

Почему не учитываю? Как раз в причины возможного провала логически блистательно выстроенного плана и заложено предположение о наличии форс-мажорных факторов, и баги в их числе:)

Share this post


Link to post
Share on other sites

Версия софта какая ? и снимите дамп трафика на клиенте

 

Model: mx80-48t
JUNOS Base OS boot [13.2R2.4]
JUNOS Base OS Software Suite [13.2R2.4]
JUNOS Kernel Software Suite [13.2R2.4]
JUNOS Packet Forwarding Engine Support (MX80) [13.2R2.4]
JUNOS Online Documentation [13.2R2.4]
JUNOS Services Application Level Gateways [13.2R2.4]
JUNOS Services Jflow Container package [13.2R2.4]
JUNOS Services Stateful Firewall [13.2R2.4]
JUNOS Services NAT [13.2R2.4]
JUNOS Routing Software Suite [13.2R2.4]

 

Итак, у нас есть рабочий UDP traceroute, который, очевидно, обеспечивается правилом

Кстати юдипишный traceroute работает и без каких бы то нибыло application's

 

и поставил бы его в application-set'е выше любых других правил, связанных с icmp и traceroute.

Вы пробовали такой вариант?

 

Попробовал, не помогло.

Edited by phantom_vk

Share this post


Link to post
Share on other sites

orlik (05 сентября 2014 - 20:16) писал:

Версия софта какая ? и снимите дамп трафика на клиенте

 

 

Model: mx80-48t

JUNOS Base OS boot [13.2R2.4]

 

 

отлично , теперь на клиентском компьютере снимите дамп трафика , как вы делаете трейсроут , и проверьте возвращаются ли вам пакеты и правильные ли это пакеты ...

 

P.S. если лень , то обновляйтесь сразу 13.2 не лучший вариант

Share this post


Link to post
Share on other sites

P.S. если лень , то обновляйтесь сразу 13.2 не лучший вариант

 

С вендорами всегда так, сначала мозг потрахают, а потом... ну обновляйтесь, это просто баг :)

PS: шутка... а в каждой шутке, есть доля шутки

Share this post


Link to post
Share on other sites

отлично , теперь на клиентском компьютере снимите дамп трафика , как вы делаете трейсроут , и проверьте возвращаются ли вам пакеты и правильные ли это пакеты ...

 

Снял flow на джунипере

run show services stateful-firewall flows
Interface: ms-0/2/0, Service set: sst1
Flow                                                State    Dir       Frm count
ICMP       10.10.20.10       ->     81.19.70.3       Forward  I               2 -> FreeBSD ping 
ICMP        81.19.70.3       ->     Внешний IP       Forward  O               2 -> FreeBSD ping

ICMP       10.10.20.30       ->  213.180.193.3       Forward  I               9 -> Windows XP tracert (не работает)
ICMP     213.180.193.3       ->     Внешний IP       Forward  O               9 -> Windows XP tracert (не работает)

 

P.S. если лень , то обновляйтесь сразу 13.2 не лучший вариант

А подскажите на какую версию обновится?

И может ли еще по этой же причине не правильно работать port-forwarding?

Edited by phantom_vk

Share this post


Link to post
Share on other sites

выложил дамп с клиента. это на MS-MPC.

http://rghost.ru/57910951

 

C:\Users\Артем>tracert ya.ru

 

Трассировка маршрута к ya.ru [93.158.134.3]

с максимальным числом прыжков 30:

 

1 <1 мс <1 мс <1 мс 192.168.72.235

2 * * * Превышен интервал ожидания для запроса.

3 * * * Превышен интервал ожидания для запроса.

4 * * * Превышен интервал ожидания для запроса.

5 2 ms 1 ms 2 ms www.yandex.ru [93.158.134.3]

 

Трассировка завершена.

 

C:\Users\Артем>

Share this post


Link to post
Share on other sites

Если посмотрите в исходное сообщение (которое вложено в icmp ttl expired) то увидите что MX поменял его код с type 8 на type 0 . Пожтому винда и не воспринимает ти сообщения. Обновляйтесь :)

 

Если посмотрите в исходное сообщение (которое вложено в icmp ttl expired) то увидите что MX поменял его код с type 8 на type 0 . Поэтому винда и не воспринимает ти сообщения. Обновляйтесь :)

Screen_Shot_2014_09_08_at_20_52_31.png

Share this post


Link to post
Share on other sites

Вот еще от меня

rghost.ru/57921843

Ну сами посмотрите , у вас аналогично, только что в обратном сообщении type 2. Это вообще экзотика какая-то :) обращайтесь в тех поддержку J пусть они это чинят.

Share this post


Link to post
Share on other sites

коммент JTAC относительно ICMP

 

Please make sure that your firewall filter does not drop ICMP packets in the destination

port range of 33434 to 33600. If it accepts them, then we would recommend you to upgrade

to 13.3R3.6 Junos version.

Share this post


Link to post
Share on other sites

Хочу поделится радостью, после обновления прошивки на 13.3R3.6 трассеровка из винды пошла, но вот порт форвардинг так пока и не работает.

Share this post


Link to post
Share on other sites

Адово говно ваш жунипер. Чем больше узнаю тем больше понимаю. =((

 

А какая альтернатива, при использовании в качестве бордера?

Share this post


Link to post
Share on other sites

Адово говно ваш жунипер. Чем больше узнаю тем больше понимаю. =((

 

А какая альтернатива, при использовании в качестве бордера?

я хз, я не пров.. ынтырпрайз... вот в ынтыпрайзе жунипер ГОВНО. полное.

Я тут очереди попытался настроить на SRX, был удивлен.

Share this post


Link to post
Share on other sites

Хочу поделится радостью, после обновления прошивки на 13.3R3.6 трассеровка из винды пошла, но вот порт форвардинг так пока и не работает.

 

А что именно не работает ?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.