SUrov_IBM

Fox_m, приветствую! Если Вы не используете сервисы требующие поддержки IPv6, можно полностью исключить работу протокола со стороны клиентской ОС. Понимаю, в меня "полетят тапки" за предложение подобной "кастрации". В своей локальной среде, я бы именно так поступил, чтобы не ловить грабли IPv6 DNS. ОС Windows 10 (и выше): В ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters Создать DWORD (32-bit) параметр DisabledComponents Шестнадцатеричное значение ff После перезагрузить ОС. P.S. DisabledComponents можно распространять через групповую политику Active Directory, если потребуется.

Уважаемые форумчане, приветствую Вас. Если встретиться специалист по Panasonic, возможно подскажет. Суть: АТС KX-TDE600 "из коробки" поддерживает возможность импульсного набора для аналоговых extension (подключенных к ней ТА). Самое интересное в следующем - после набора номера и установления соединения (точно не знаю в пред-ответной или ответной стадии) АТС KX-TDE600 конвертировала полученный с аналогового ТА импульс в тон DTMF. Что позволяло набрать добавочный номер в DISA / IVR вызываемой (Б) стороны. Знаю точно, поскольку используемый ТА имел дисковый номеронабиратель и промежуточных конверторов в линии до АТС не использовалось. И собственно вопрос - как называлась данная волшебная функция, придуманная японским умом? Чтобы можно было понять, в каких моделях мини-АТС Panasonic она присутствовала. :)

Merk055, здравствуйте. При упоминании PON, почему-то сразу представляется PPPoE. Если используется PPPoE, сниженное MTU и соответственно MSS. Форумчанин Jffulcrum очень правильно это заметил! Попробуйте зарезать MSS "предельно низко" на "внешних" интерфейсах смотрящих в сторону двух операторов. Например таким образом: /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=*название_WAN интерфейса_1го_оператора* tcp-mss=1300-65535 log=no /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=*название_WAN интерфейса_1го_оператора* tcp-mss=1300-65535 log=no /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=*название_WAN интерфейса_2го_оператора* tcp-mss=1300-65535 log=no /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=*название_WAN интерфейса_2го_оператора* tcp-mss=1300-65535 log=no

AndrK189100, здравствуйте. Извиняюсь, что отвечаю не по теме QoS. Хотел уточнить, если со стороны сервера используется MS Windows 2022/2019/2016 Server, для работы RDP возможно использование UDP соединения (порт 3389) - RDP версия 8.1. В TCP соединении передаются клавиатура и мышь клиента, в нескольких UDP соединениях передаются медиа-данные от сервера. Опыта работы с Remmina у меня нет, поэтому не могу сказать, поддерживает данный RDP клиент UDP соединение? Если поддержка есть, то возможно канал занимается UDP соединениями поступающими от сервера к клиенту? Можно попробовать отключить поддержку UDP соединения на стороне сервера. Правда, это ухудшит получаемое с сервера качество изображения.

AlwaysWannNymon, здравствуйте. Я правильно понимаю Вашу схему: [АТС (1) IP 192.168.35.35] <=> [MIKROTIK (1)] <={VPN}=> [MIKROTIK (2)] <IP 172.28.63.62/30 ={VoIP VLAN}= IP 172.28.63.62/30> [IP маршрутизатор] <=> [АТС (2) IP 172.28.61.10] ? Важное замечание с точки зрения телефонии, а именно - каким способом АТС (2) IP 172.28.61.10 сконфигурирована на взаимодействие с АТС (1) IP 192.168.35.35: - 1 вариант: АТС (2) IP 172.28.61.10 ожидает "на себе" регистрацию SIP User Agent (IP телефон / IP АТС / Soft-фон) с использованием SIP REGISTER (регистрация по - номер, логин и пароль), но с явной "привязкой" к IP адресу 172.28.63.62? Данный способ применяется если между SIP UA и IP АТС предполагается NAT. - 2 вариант: АТС (2) IP 172.28.61.10 ожидает, что SIP User Agent SIP работает "без регистрации" (не посылая SIP REGISTER) и фактически располагается на IP адресе 172.28.63.62? Условно если бы IP телефон или IP АТС включались в VoIP VLAN без маршрутизатора. Если используется 1 вариант, на MIKROTIK (2) Вам необходимо настроить Source NAT (src-nat) для сети 192.168.35.0/xx (возможно для одного IP адреса 192.168.35.35, но некоторые IP АТС используют два и более IP адресов подсети (например для DSP процессоров)). При этом должна быть "полная" IP связанность [АТС (1) IP 192.168.35.35] и [MIKROTIK (2)] через VPN. /ip firewall nat add action=src-nat chain=srcnat src-address=192.168.35.0/24 to-addresses=172.28.63.62 Чтобы пакеты посылаемые [АТС (1) IP 192.168.35.35] пройдя VPN "закрывались" IP адресом 172.28.63.62 src-nat NAT трансляцией в направлении IP адреса 172.28.61.10 на [MIKROTIK (2)]. Так же, на [MIKROTIK (1)] и [MIKROTIK (2)] обязательно выключайте SIP ALG (/ip firewall service-port set sip disabled=yes), ибо этот помощник "сам себе на уме". При использовании 2 варианта (UA SIP работает "без регистрации") и данной схеме, всё будет гораздо неприятней, с применением "дополнительных костылей" в схеме. Примечание: Посылаемые в сторону АТС (2) IP 172.28.61.10 SIP запросы, можно "смотреть" внешним анализатором трафика на [MIKROTIK (2)]. Например Wireshark'ом, чтобы убедиться в корректности запросов и правильной настройки src-nat.

Qlement, здравствуйте. Как выше сказали коллеги по цеху - это платы расширения для АТС Nortel CS1000 (Meridian). Более точно обозначение плат указано на лицевой стороне (мордочке). АТС использовалась в крупных ведомственных организациях, бизнес центрах с единой телефонной структурой и в маленьком варианте, в манерных офисах. К АТС подключаются Digital телефонные аппараты производства Nortel (поддерживающие дополнительные услуги АОН / перевод / перехват / конференции) и обычные аналоговые (с минимальным набором функций). Всё это ограничено длинной прямых аналоговых линий от АТС до телефонов. Правда существовали и выносные модули, подключаемые по потоку (для расширения). К сожалению, как сказали выше, это уже прошедшее время - станция не масштабируется в отличии от IP телефонии и не поддерживает современные дополнительные услуги. Плюс требует определённых специфических знаний по настройки даже обычных функций, не каждый специалист бы взялся. P.S. Если смотреть с точки зрения продажи этого добра, самый простой путь "Авито", но возможно будет продаваться вечно и за копейки, к сожалению такая правда для этого оборудования.

Jffulcrum, здравствуйте. Спасибо большое, что ткнули носом! ;) >>Дык, откуда у него POE? - Cisco Catalyst 3750 Series Switches Data Sheet - Cisco Естественно - "Смотрю в книгу, вижу фигу"! Т.е. смотрю на описание WS-C3750-24PS-S и ломаю себе мозг...

Уважаемые знатоки, приветствую Вас. Прошу подсказки: Столкнулся с коммутатором Cisco Catalyst WS-C3750-24TS-S, захотел запитать по PoE 802.3af несколько устройств, но не тут то было - медные порты FastEthernet 1-24 питание не обеспечивают, хотя сами по себе исправны и прекрасно работают. ̶-̶ ̶В̶о̶з̶м̶о̶ж̶н̶о̶ WS-C3750-24TS-S не поддерживает PoE ̶8̶0̶2̶.̶3̶a̶f̶ ̶и̶л̶и̶ ̶т̶р̶е̶б̶у̶е̶т̶с̶я̶ ̶д̶о̶п̶о̶л̶н̶и̶т̶е̶л̶ь̶н̶а̶я̶ ̶п̶р̶и̶б̶л̶у̶д̶а̶ ̶в̶ ̶в̶и̶д̶е̶ ̶о̶т̶д̶е̶л̶ь̶н̶о̶г̶о̶ ̶п̶и̶т̶а̶н̶и̶я̶,̶ ̶к̶а̶к̶ ̶у̶ ̶8̶8̶1̶ ̶к̶о̶ш̶к̶и̶ ̶н̶а̶п̶р̶и̶м̶е̶р̶,̶ ̶п̶л̶а̶т̶а̶ ̶р̶а̶с̶ш̶и̶р̶е̶н̶и̶я̶ ̶к̶а̶к̶а̶я̶-̶о̶т̶ ̶в̶о̶ ̶в̶н̶у̶т̶р̶ь̶?̶ ̶-̶ ̶В̶о̶з̶м̶о̶ж̶н̶о̶ ̶I̶O̶S̶ ̶с̶т̶а̶р̶ы̶й̶ ̶и̶л̶и̶ ̶т̶р̶е̶б̶у̶е̶т̶с̶я̶ ̶д̶о̶п̶о̶л̶н̶и̶т̶е̶л̶ь̶н̶а̶я̶ ̶л̶и̶ц̶е̶н̶з̶и̶я̶ ̶н̶а̶ ̶а̶к̶т̶и̶в̶а̶ц̶и̶ю̶ ̶P̶o̶E̶ ̶8̶0̶2̶.̶3̶a̶f̶?̶ ̶-̶ ̶И̶л̶и̶ ̶в̶ ̶к̶о̶н̶ф̶и̶г̶у̶р̶а̶ц̶и̶и̶ ̶т̶р̶е̶б̶у̶е̶т̶с̶я̶ ̶п̶р̶и̶н̶у̶д̶и̶т̶е̶л̶ь̶н̶о̶ ̶в̶к̶л̶ю̶ч̶и̶т̶ь̶ ̶и̶м̶е̶н̶н̶о̶ ̶8̶0̶2̶.̶3̶a̶f̶,̶ ̶а̶ ̶т̶о̶ ̶о̶н̶о̶ ̶е̶щ̶ё̶ ̶p̶r̶e̶s̶t̶a̶n̶d̶a̶r̶d̶ ̶P̶o̶E̶ ̶о̶т̶ ̶C̶i̶s̶c̶o̶ ̶в̶р̶о̶д̶е̶ ̶к̶а̶к̶ ̶п̶о̶д̶д̶е̶р̶ж̶и̶в̶а̶е̶т̶.̶.̶.̶ System image file is "flash:c3750-advipservicesk9-mz.122-25.SEE.bin" Прошу по возможности не закидать тапками и направить на путь истинный. ;)

Проблема в том, что хотелось запускать GRE туннель по феншую (штатными средствами), т.е. из /etc/rc.conf. При построении туннеля через скрипт в /usr/local/etc/rc.d/ - всё прекрасно работает. Заметил, если tunnel inet находятся в одной подсети (например 172.0.255.1 --> 172.0.255.5 /29), интерфейс GRE работает (статус RUNNING). Порыскав на просторах Интернет, похоже нашёл описание своей проблемы - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138407 >>If the system did not install default route before the gre interface initialization, setting up tunnel properties will not trigger RUNNING flag on interface. В моём случае, действительно отсутствует "default route" в момент запуска интерфейса GRE из /etc/rc.conf. Правда указание defaultrouter="xxx. xxx. xxx. xxx " или статического маршрута до tunnel inet IP destination в /etc/rc.conf ситуации не изменило. Кроме варианта обновления системы до stable версии 10 или использования скрипта автоматического запуска интерфейса, решения не нашёл. Задачи обновляться не стоит, GRE туннель запускается через скрипт в /usr/local/etc/rc.d/. Просто хотелось разобраться, что я делаю не так. Для себя тему считаю закрытой.

Уважаемые знатоки, приветствую Вас. Имеется устаревшая ОС FreeBSD RELEASE 9.2, kernel amd64. Пытаюсь штатным образом настроить автоматический старт GRE-тоннеля через /etc/rc.conf: cloned_interfaces="gre0" ifconfig_gre0="inet xxx. xxx. xxx.22 xxx. xxx. xxx.21 netmask 255.255.255.252 tunnel 172.0.255.1 172.31.255.241 mtu 1436 up" Тоннель корректно создаётся, но "не поднимается" пока не применить: #Ifconfig gre0 up Ограничений в IPFIREWALL нет, в ядре установлено "IPFIREWALL_DEFAULT_TO_ACCEPT". Поддержка сетевых карточек (emX) так же прописана в ядре, чтобы "стартовать первыми" (были проблемы не связанные с GRE). При этом, если создать простенький скрипт в /usr/local/etc/rc.d/start_gre0.sh: #!/bin/sh /sbin/ifconfig gre0 create /sbin/ifconfig gre0 tunnel 172.0.255.1 172.31.255.241 mtu 1436 /sbin/ifconfig gre0 inet xxx. xxx. xxx.22 xxx. xxx. xxx.21 netmask 255.255.255.252 И стартовать GRE-тоннель через него, а не через /etc/rc.conf - тоннель прекрасно работает. Вроде всё так банально должно быть, а вот не выходит "каменный цветок". Скорей всего по невнимательности упускаю какую-то мелкую деталь. На обновляться продуктивный RELEASE задача не стоит, можно обойтись скриптом. Просто хочется сделать красиво и понять в чём могла быть загвоздка. Возможно кто-то поделиться заведомо рабочим сегментом /etc/rc.conf для старта GRE-тоннеля. ;)

>>С сертификатами не придется возиться это плюс. Да вовсе не обязательно, можно использовать "Static key" без сертификатов. Правда думал OpenVPN использует "Static key" только в L3 режиме (TUN), но благодаря форумчанину "Edo", спустя двадцать лет узнал, что "Static key" так же применим к L2 (TAP)

>>Вот выдержки из моего учебника по которому нас учили, пример сети, адресации и настройки. Так у Вас в учебнике Serial интерфейсы, всё как любили и любят кошка-воды середины 90х и 2000х годов, когда IP сети строились через телефонную сеть на основе потоков G.703. Я сам такое обожаю, но время уже немножко другое. ;) Если Вы задаёте статическую маршрутизацию без всяких изысков PBR, VRF, танцев с бубном вокруг proxy-arp и масок /31, Вам хватает в качестве следующей точки перехода IP адреса, в сторону которого вы направляете трафик.

При простой статической маршрутизации (если Вы задаёте IP адреса), даже если используется PPP соединение, но IP адрес перехода известен, не могу понять, зачем использовать PPP интерфейс? IP адрес никуда не убежит, даже если будет не доступен. В простой схеме, могу представить только случай с PPPoE в сторону оператора, когда адрес шлюза меняется.

Jffulcrum, здравствуйте. >>Иногда в маршрутизации приходится указывать вместо GW - выходной интерфейс, когда адрес шлюза к destination находится за пределами адресации на интерфейсе - гирлянда из роутеров. Понятно, что допускается применение интерфейса вместо явного IP адреса следующего перехода. Просто мне кажется, начинается подобная статическая маршрутизация при хитровыдуманных схемах VRF lite с переходом в Global (GRT) или наоборот чтобы "проскочить" GRT. У автора вроде простая "классическая" IP маршрутизация в пределах одной роутинговой таблицы. Поэтому и не понятно, зачем использовать "привязку" к интерфейсу? ;)

65465132152, здравствуйте. >>Пинги идут вроде работает видео пока но вылетают ошибки на одном клиенте. И видео с того устройства часто пропадает. Притом что уровень сигнала сотового оператора высокий. Если на iRZ модеме присутствует выделенный (белый) статический IP адрес, попробуйте настроить простой IP GRE туннель между "центром" и модемом, отказавшись от OpenVPN хотя бы для теста. Если выделенного IP нет, можно попробовать PPP VPN, т.е. PPTP или L2TP. В анонсе модемов iRZ вроде заявлена поддержка L2TP клиента. Настроив альтернативный туннель VPN, Вы поймёте проблема в OpenVPN или в самой IP связи на объекте. Если альтернативно всё нормально и захотите вернуться к OpenVPN, потом будите его препарировать. ;) Не совсем понятно, что Вы имеете в виду: >>А в микротике оказыватся адрес выходного интерфейса микротика на пути к адресату назначения. Логика настройки статического маршрута в MikroTik и CISCO кроме синтаксиса не отличается: MikroTik: add dst-address=xxx.xxx.xxx.0/24 gateway=yyy.yyy.yyy.yyy Cisco: ip route xxx.xxx.xxx.0 255.255.255.0 yyy.yyy.yyy.yyy