Перейти к содержимому
Калькуляторы

evgeniy_s

Новичок
  • Публикации

    7
  • Зарегистрирован

  • Посещение

Все публикации пользователя evgeniy_s


  1. Добрый день! Пожалуйста, подскажите! Отваливается линк на eth1, вместе с ним и l2tp из этого порта и прочее... Виноват или кабель, или коммутатор на том конце. Помогает физическое передергивание кабеля в порту. Как организовать сие действо автоматически в случае падения линка?
  2. Интересная идея... Вообще не связывался пока, надеюсь, повезет найти совместимый *wrt. Вообще - вопрос навеян тем, что в общем, в прямом направлении (из LAN в серый WAN) все равно обмен идет, т.е НАТ нормально маскарадит как в инет так и в серую сеть. Только маршрут до серого шлюза прописать прошлось. Отсюда и смутные предположения, что и в обратном направлении работать будет!
  3. Здравствуйте господа! Вот есть обычный стандартный роутер TPLINK, они абсолютно однотипны как в проводном так и в беспроводном исполнении. Речь будет о казахстанском Билайне, насколько я слышал, аналог Корбины (могу ошибаться). Про то, как настраивать проброс портов через NAT я не посмел бы тут спрашивать) ввиду крайней избитости темы. У меня другая проблема! Роутер висит WAN-портом в серой сети билайна (10.Х.Х.Х), и L2tp интерфейсом в белой. Мне надо понять, как пробросить порты ИЗ СЕРОЙ СЕТИ, при активном l2tp. Мне половину трафика надо гонять по серой... Дома у меня Микротик, там это влегкую. Но ставить Микротик в каждую из удаленных точек - несколько накладно)
  4. Здравствуйте! Продолжаю настраивать микротик.) Ситуация. На компе входящий-исходящий UDP-порт, допустим 30000, разумеется, при прохождении через маскарад его номер меняется по выбору самого маскарада. По правилам, когда получатель отправляет ответ на маскарад-порт, NAT его обратно пробрасывает на исходный (30000) порт. Если по данному направлению собеседники молчат, маршрут живет какое-то время, потом удаляется. Исследования показали, что "обычные" DLINK-TPLINK допускают молчание до 3-4 минут стабильно, дольше не проверял. В дефолтовом маскараде Микротика время жизни молчащего маршрута - около 20 сек, м.б меньше. Где настроить? Мне надо, чтобы маршрут жил не менее 90 сек, да и вообще, знать хочу где это настраивается
  5. Снова о пробросе портов

    Спасибо, получилось!
  6. Снова о пробросе портов

    [admin@MikroTik] /ip firewall nat> print Flags: X - disabled, I - invalid, D - dynamic 0 chain=srcnat action=masquerade log=no log-prefix="" 1 chain=dstnat action=netmap to-addresses=192.168.1.22 to-ports=23199 protocol=tcp in-interface=l2tp-out1 dst-port=23199 log=no log-prefix="" 2 chain=dstnat action=netmap to-addresses=192.168.1.22 to-ports=23199 protocol=tcp in-interface=ether1 dst-port=23199 log=no log-prefix="" eth2 = 1.100/24 eth3-5 SLAVE Это логи сейчас... 192.168.1.100 - - [12/Aug/2015:23:19:58 +0600] "GET /cloudcore/card/card.php HTTP/1.1" 200 60083 192.168.1.100 - - [12/Aug/2015:23:20:02 +0600] "GET /polosa.jpg HTTP/1.1" 200 12964 192.168.1.100 - - [12/Aug/2015:23:20:13 +0600] "GET /cloudcore/stat/payment.php?acc=07025452&limit=100 HTTP/1.1" 200 5720 192.168.1.100 - - [12/Aug/2015:23:21:39 +0600] "GET /cloudcore/card/card.php HTTP/1.1" 200 59993 192.168.1.100 - - [13/Aug/2015:00:51:14 +0600] "GET /cloudcore/system/core.php HTTP/1.1" 200 3880 Это на TPLINKe 5.34.35.110 - - [12/Aug/2015:09:52:15 +0600] "POST /cloudcore/access.php HTTP/1.1" 200 395 5.34.35.110 - - [12/Aug/2015:09:52:19 +0600] "GET /cloudcore/access.php?idc=1 HTTP/1.1" 302 92 5.34.35.110 - - [12/Aug/2015:09:52:20 +0600] "GET /cloudcore/card/card.php HTTP/1.1" 200 60083 5.34.35.110 - - [12/Aug/2015:09:52:24 +0600] "GET /cloudcore/card/card.php?lzone=27 HTTP/1.1" 200 59821 5.34.35.110 - - [12/Aug/2015:09:52:35 +0600] "GET /cloudcore/card/card.php?lzone=clear HTTP/1.1" 200 59993
  7. Здравствуйте! Владею RB750. Ситуация следующая. По многочисленным однотиповым инструкциям настроил dstnat, в режиме как dstnat, так и netmap. Все живет, но проблема - серверные логи отображают клиента как шлюз микротика, а его реальный wan адрес - не прилетает! Что делать?? Мне обязательно надо чтобы в заголовках прилетающих пакетов содержался реальный адрес отправителя, а не "обратный маскарадинг"!