SUrov_IBM

Ivanm38, здравствуйте. https://bgp.he.net/AS15169#_prefixes

Saab95, здравствуйте. Искажая таким образом восприятие, Вы ступаете по тем же «граблям», что в своё время делали те же заносчивые «Cisco-воды», мол - только это оборудование имеет право на значимость! Ну с CISCO то понятно, оно монстр, во многом определивший развитие сетей, а MIKROTIK’у этим не похвастаться, удел у него иной… и вишенка на торте - «RouterOS - сетевая операционная система на базе Linux». А так да, прикольная железка, своих денег стоит и много где может применяться. ;) Вот только мы про понимание и обучение сетевым технологиям говорим, а это значит понимание принципов работы протоколов IPv4/v6, а уж на каком оборудовании это реализовывать, зависит от задачи. CISCO, MIKROTIK, Windows, Linux, да хоть QNX… в принципе «фиолетово» для нормального сетевого инженера, если он читать умеет и коммутацию / маршрутизацию понимает. P.S. А то потом получаются, что дипломированные знатоки MIKROTIK, не могут подсказать, что под той же Windows, при использовании протокола PPP в сторону MIKROTIK, маршрут нужно строить не через адрес шлюза ибо маска /32, а через «самого себя». Однобокие какие-то сетевые специалисты получаются, когда только от одной железки с бубном пляшут! Уж простите. ;)

BSB, здравствуйте. Выскажу свои пять копеек и возможно, меня забросают тапками. Если происходит изучение сетей, учить нужно маршрутизации и пониманию модели TCP/IP (L1, L2, L3, L4), даже не громадину OSI («Интернета, которого не было»). Главное, чтобы человек понимал, что на L2 уровне коммутируется и что на L3 маршрутизируется (статика, динамика) и как на L4 уровень портов (TCP, UDP) уже взаимодействует. Тогда уже будет не важно, c каким оборудованием взаимодействовать (при наличии доступного описания оборудования), Cisco, Mikrotik,... и т. д., на физическом устройстве, PC "тазике" или вообще в виртуальной машине. ;)

Egorch, здравствуйте. В данном разделе форума, да и в принципе на форуме nag.ru, обитают люди, ориентированные на работу с общедоступными коммерческими решениями, иногда с любительскими проектами. Коммутатор П-380К, является оборудованием специального назначения. Конечно, это не отменяет того, что коммутатор - обычная АТС, скорей всего со свободным ПО типа "Звёздочки" (Asterisk) внутри, но это очень специфическое оборудование, главное - не документированное в общем доступе. Мало вероятно, что Вам кто-то сможет помочь на данном форуме, поскольку не сталкивались с данным оборудованием в "живую" и с его документацией. P.S. В прошлом году, уже поднималась тема про данный коммутатор, специалистов не нашлось, очень уж специфическая железка, большинству не интересная, да и просто так никто не даст подержать, всё же разработка для другой целевой аудитории.

Brucklin, здравствуйте. Если со стороны маршрутизатора настройки не менялись, мало вероятно, что вина в нём. Для верности, помимо SIP ALG, можете ещё отключить UPnP (правда не уверен, что UPnP связано с SIP). Кокой тип (способ) SIP "trunk" АТС, находящаяся за NAT, использует для связи с сервисом поставщика услуг IP-телефонии: "SIP Registrar" (регистрация на сервере поставщика услуг) или "Проброс SIP (порт 5060) и медиа-аудио (порты 10000-20000)" через NAT на IP адреса АТС во внутренней сети? Как предположение, если используется первый вариант - "SIP Registrar", проверьте чтобы время регистрации SIP аккаунта на сервере (со стороны АТС), соответствовало значению рекомендуемому поставщика услуг. Возможно, при настройке API на АТС, значение сбилось в большую сторону и сервер поставщика услуг "теряет" АТС, по истечении времени регистрации. P.S. Но как уже сказал выше уважаемые форумчане, лучше всего зеркалировать порт на коммутаторе и cнять трассировку вызова сниффером трафика, например Wireshark, чтобы потом можно было проанализировать состояние вызова. А иначе, всё получается "гадание на кофейной гуще". ;)

Brucklin, здравствуйте. Если совсем кратко, в двух-проводной аналоговой линии, для передачи информации о номере вызывающего абонента, в общем существует два варианта: 1. "Русский АОН" - атавизм, пришедший из эпохи координатных АТС в СНГ. Сейчас, практически нигде не используется, возможно и встречается только в какой-то совершенно фантастической ситуации (провинциальный город, производственная площадка забытого в вечности завода и т.п. случаи). Характеризуется тем, что сначала "снимает трубку", а потом обменивается коротким акустическим сигналом. 2. Современный, повсеместно используемый вариант "Caller ID" - передаёт информацию о номере вызывающего абонента, без "снятия трубки" в интервале между вызывным напряжением. Важно - имеет несколько реализации и под-реализации стандарта (Bellcore, ETSI). Подключив ТА (телефон) к линии (любой радио-телефон или факс Panasonic), убедитесь какой тип определителя номеров установлен - "Русский АОН" или "Caller ID". Если "Русский АОН", то к сожалению практически не какие FXO порты его не поддерживают (возможно, за исключением российского производства). Существует конвертер "Русский АОН" => "Caller ID", но это "путь в никуда". Если "Caller ID", то нужно перебрать все возможные варианты настройки со стороны FXO порта вашего шлюза. Лучше уточнить у поставщика услуг телефонии, какой тип "Caller ID" он использует для данной линии. Возможно, Ваш шлюз такой тип не поддерживает, в отличии от "всеядного" ТА. Возможно (но к сожалению маловероятно) поставщик услуг сможет изменить тип "Caller ID", для Вашей линии, со своей стороны. ;)

Saab95, здравствуйте. Имеете в виду VxLan? Если да, то да, можно пробросить через публичный Интернет. VxLan, это Ethernet кадры упакованные в UDP, главное чтобы была маршрутизируемая IP связность. ;)

AlexZhukov, Да не за что, для это и есть форум. ;) Удачи!

AlexZhukov, OK, предположим плечо L2TP+IPSec с WINDOWS клиент работает. С маршрутизатора "Офис1", проверьте связь до IP 172.16.0.4 (сервера), обязательно указав SOURCE IP адрес 192.168.0.1 (адрес плеча L2TP сервера). И в противоположную сторону, от IP 172.16.0.4 (со стороны сервера), до IP 192.168.0.1 (адрес плеча L2TP сервера). Нужно убедиться, что сети 172.16.0.0/24 и 192.168.0.0/24 доступны друг-другу, через "IPSec Site-To-Site".

AlexZhukov, Про WINDOWS, если не ставится "маршрут по умолчанию (шлюз по умолчанию)" на L2TP соединение, то: L2TP – это PPP (маршрутизация точка-точка, маска сети /32). При использовании PPP интерфейса, маршрутизация строиться не через адрес сервера (192.168.0.1), а через IP адрес, который получил виртуальный адаптер L2TP (192.168.0.xxx). Поэтому статическая маршрутизация под Windows будет выглядеть так: route add 192.7.1.0 MASK 255.255.255.0 192.168.0.xxx METRIC 1 route add 172.16.0.0 MASK 255.255.255.0 192.168.0.xxx METRIC 1 После этого, с Windows ПК должны быть доступны IP адреса 192.7.1.yyy и 172.16.0.yyy. см. -

AlexZhukov, здравствуйте. Да, реализовать можно. Возможно, Вам поможет понимание - в VPN "IPSec Site-To-Site" ("чистый IPSec", что реализовано между "Офис1" - "Офис2") используется не классическая маршрутизация (route add маршрут -> gw), а маршрутизация до VPN IPSec Site (сторона IPSec) с указанием сети (или списка сетей), которые связывайся через VPN "IPSec Site-To-Site". Плечо за маршрутизатором "Офис1", где у Вас используется L2TP VPN (даже, если там используется IPSec), воспринимайте как обычную IP сеть /24, пристыкованную к маршрутизатору. Для этого плеча, чтобы клиент L2TP подключался к маршрутизатору "Офис1", Вам нужно будет настроить L2TP сервер и IPSec для протокола L2TP, но не запутайтесь, VPN "IPSec Site-To-Site" между офисами с одного плеча маршрутизатора "Офис1" и L2TP over IPSec с плеча для клиента - это резаные VPN соединения! ;)

Morgot999, здравствуйте. Можно попробовать записать на USB FLASH "Hiren's BootCD" (https://mirror.macomnet.net/pub/hirensbootcd/HBCD_PE_x64.iso), для записи использовав "Rufus". И загрузившись уже с "Hiren's BootCD", повторить "SpeedTest", если конечно распознается сетевой адаптер. В любом случае, если грешите на скорость от оператора, нужно напрямую подключать к Ethernet от оператора "эталонным" (который проверено определяет скорость при тесте в другом месте) компьютером, минуя маршрутизаторы и прочее активное оборудование (например Ethernet_over_Power и т.п.) и производить тестирование. ;)

Уважаемые знатоки, здравствуйте. Существует следующая работающая схема (упрощённая): [АТС Panasonic KX-NS1000]={H.323}=>[«Автоответчик»] На АТС поступает вызов, адресуемый внутреннему Extension. Далее, через безусловную переадресацию, вызов направляется на «Автоответчик». Всё хорошо – «Автоответчик» воспроизводит голосовое сообщение, после чего "кладёт трубку", сообщая АТС "Release Cause 16 (Normal call clearing)". И вот тут, АТС такая – «А давай-ка, я начну громко генерировать "Busy tone" ("Ти-Ти-Ти") в голосовом канале, в сторону вызывающего абонента, секунд так на 20 и только потом, пропищавшись, порву соединение». ;) Собственно, вопрос к знатокам Panasonic – можно ли поколдовать чем-то на АТС, чтобы при получении Cause 16 в сигнализации от «Автоответчика», АТС не генерировала "Busy tone" ожидая вечности, а разорвала соединение? Из особенностей: - «Автоответчик» генерирует сообщение в голосовом канале в пред-ответном состоянии. - «Автоответчик» сам не генерирует "Busy tone", специально проверял RTP, это "Ти-Ти-Ти" рождается в недрах АТС. - Если вместо АТС, к «Автоответчику» подключить H.323 терминал, реакция на Cause 16 нормальная, зависящая от терминала, будет он "Busy tone" генерировать или просто разорвёт соединение, "уйдя в тишину" (зависит от настройки терминала). - Если собрать схему [H.323 терминал]= {H.323}=>[АТС Panasonic KX-NS1000]={H.323}=>[«Автоответчик»], Cause 16 в сигнализации пролетает через АТС нормально, возможно она и пытается делать "Ти-Ти-Ти", но соединение уже разорвано. А вот, во всех остальных случаях – системные ТА АТС, DISА, SIP..., АТС будет сообщать "Ти-Ти-Ти - там трубку положили", пока не отвалиться только по ей известному таймеру.

Уважаемые знатоки, здравствуйте. Возможно, кто-то сталкивался с данной задачкой: Имеется Mikrotik CHR, использующий приобретённую лицензию, которая верифицируется на сервере лицензий производителя Mikrotik, через публичный Интернет. Всё хорошо, но вопрос в том, что для данного Mikrotik не предусмотрен полный доступ в публичный Интернет (0.0.0.0/0 не предполагается). Собственно вопрос – возможно, у Вас есть список IP адресов сервера лицензирования Mikrotik, расположенного в Интернет? Просьба, сильно "тапком по голове" за лень не бить, сниффером пользоваться умею, просто если у кого-то есть список IP адресов сервера лицензирования, прошу поделиться. ;)

St_re, здравствуйте. В моём случае, это не публичный MTA, поэтому со SPAM’ерами взаимодействия не предвидеться. Задачка, на самом деле очень простая – корпоративный MTA (для меня, не подконтрольный) не может осуществить доставку сообщений для определённого домена (такого домена попросту не существует). Поэтому, корпоративный MTA будет направлять все сообщения адресованные данному домену, на мой "маленький MTA заглушку", который в свою очередь, будет отвечать отправителю, чтобы он внимательней смотрел, куда отсылает письмо, а не «на деревню дедушке». Благодарю Вас за подсказку! Попробую посмотреть в направление vacation, насколько я понял, его не сложно увязать с sendmail. Может что-то и выйдет толковое. Просто буду честным, из меня скрипт-писец, тот ещё. ;)