My_Second_Nickname, там выше в комментариях показал Andrey Barbolin как CID формируется, за что ему спасибо, и, таким образом, в поле CALLERID(num) у вас оказывается попросту пусто. Манго, всё же, видимо, поменяли формирование заголовка from.
Чуйка вела меня в правильном направлении, но не довела)
>И там используется та же конструкция с переводом (num) в (name).
У вас не num в name переводится, а наоборот. В поле num пишется значение name.
У меня на астере в CALLERID(num) корректно без всяких приключений пишется номер, хотя у меня, конечно, не манго и не зебра.
Если манго всё-таки что-то поменял, и в name стало попадать что-то кроме цифр, то в num это значение может просто не передаваться корректно, или не обрабатываться корректно в дальнейшем (хотя это не точно)
Поэтому я и предложил вам посмотреть значение этих полей до вашей обработки. Возможно, стоит смотреть и после.
My_Second_Nickname, вообще нет, я сам по стольку по скольку с астером знаком, и сам изначально не понял о чём речь.
RDNIS, на сколько я понял, тут ни при чём. Вам, я так понимаю, переадресовываются вызовы, и RDNIS - это номер, С которого происходит переадресация.
Что там с CID - из представленного неясно. Повышайте уровень логирования и смотрите ещё.
Попробуйте в самом начале обработки вывести в лог значение переменной Callerid num и name, чтобы посмотреть что в них содержится: ~
exten => 1001,1,Verbose(2,Callerid num is ${CALLERID(num)})
exten => 1001,n,Verbose(2,Callerid name is ${CALLERID(name)})
и дальше уже основную обработку
exten => 1001,n,Set(CALLERID(num)=${CALLERID(name)})
и т.д.
И делайте бэкапы, а то я ща насоветую...
Обратите внимание, опять же, что обработка у вас устанавливает значение CALLERID(num) в CALLERID(name) - зачем? Надо разбираться
MrFlatman, вы можете ручками настроить нужные шары, прописать к ним маршруты и пути непосредственно на каждой рабочей станции, причём на машинах с шарами придётся прописать статические адреса, скорее всего, при этом не придётся трогать сетевое оборудование вообще (без гарантии, но скорее всего; могут быть нюансы с arp, могут быть нюансы с ipsec, с фаерволом между подсетями, ещё с чем-то, о чём я не помню или не знаю - но едва ли это всё касается вашей сети). Но оно вам надо?
Akina,
>опять же VPN через NAT требует внешнего узла - а у соседа доступа в Инет не подвезли...
Ну дело то не в этом, между автором и соседом ната то нет. А вот что ничего кроме ICMP может не ходить - это да.
Akina, ну, во-первых, под локалкой он имеет в виду, очевидно, локалку провайдера, а сегментация у провайдера одному ему известна, и пинговаться всё вполне прекрасно может. TVCON , а, во-вторых, вполне допустима конфигурация, в которой шлюз находится не в вашей подсети, но, при этом, так или иначе должен быть указан маршрут до шлюза. Надо понимать, что шлюз - это просто указание на то, куда должен отправляться весь трафик, для которого маршрут не задан как-либо иначе. В вашей ситуации неправильно настроенная маршрутизация положит вашему соседу как доступ к провайдерской локалке, так и к интернету. В-третьих, вам придётся настроить фаервол на своём wan интерфейсе и что-то думать с nat. В-четвёртых, если провайдер спалит эти манипуляции - а он может - по головке не погладит. В-пятых, то, что пинги проходят - не означает, что на пути между вами и вашим соседом нет никакой фильтрации трафика или множества других подводных камней, о которых может быть известно только вашему провайдеру, так что в любом случае без каких-либо гарантий. Учитывая разные сегменты - всё же, скорее НЕ будет работать, чем будет.
В-шестых, лучше всего и правда поднимите vpn между вами и соседом, если уж так хотите этим заниматься, и если это вообще получится.
Адресная книга выглядит таким вот образом:
Имена компьютеров и групп произвольные, параметры подключения (кодек, блокировка ввода по-умолчанию, звук, и т.д.) могут быть сохранены как индивидуально для каждого компьютера, так и наследоваться от параметров группы; ID выдаются маршрутизатором - серверной частью, но могут быть сохранены и непосредственно ip - тогда маршрутизатор не нужен
Протокол свой, порты настраиваются
Для подключения без одноразового пароля на каждом клиенте должна быть задана пара логин/пароль; с одной стороны при массовой установке это неудобно, с другой стороны пара может быть задана через json при установке или импорте конфигурации.
shurshur, не знаю, меня более-менее устраивает то положение, в котором винда - для десктопа, серверная винда - для AD, для прочего - никсы. Больше меня не устраивает то, что майкрософт ломает то, что и так работало много лет - с вин11.
shurshur, клиентская винда просто не предназначена вообще в роли роутера существовать, так то; а там, hyper-v нетворк манагер, к примеру, вполне себе реализует уже программные вланы, в том числе с поддержкой транков, но только для проброса в vm.
Akina, ну, не вполне; аппаратная поддержка 802.11q - хорошо, но не обязательно
>на дебиане придётся мастерить два виртуальных интерфейса с адресами из показанных подсетей, привязанных к сетевой карте, и маршрутизировать между этими (и остальными) интерфейсами.
Ну да
>хотя вроде и пробудить может но не точно
Может, хотя автору стоит покопаться в настройках и проверить s power states и как wol с ними взаимодействует в конкретно его случае, в частности пробуждение/включение от pci(e) устройств
Про проводки - это либо что-то совсем старое, либо связано только со включением из холодного состояния (S5), и я просто не в курсе; из остальных режимов pci(e) точно может пробуждать без всяких лишних проводков, если это включено, конечно же
Для автора:
Тут, всё-таки, надо понимать, что у вас есть несколько уровней включения/пробуждения. Магический пакет - это замечательно, но компьютер ещё должен мочь пробуждаться от того устройства, на которое этот магический пакет приходит, а связана эта способность с интерфейсом, через которое это устройство подключается к компьютеру. Кроме того, надо учитывать power states. Обычно это всё очевидно из доступных настроек bios/uefi.
number09, я не знаю вашей ситуации, поэтому смоделирую ситуацию (на самом деле опишу свою), которая могла бы вызывать вашу потребность:
Есть группа файлов, принадлежащая к одному проекту и не подлежащая изменению, или подлежащая крайне редкому изменению после завершения проекта. При этом пользователи могут обращаться к завершённым проектам время от времени и случайно вносить изменения в файлы этого проекта, что крайне нежелательно.
Решение: переносить из плоскости чисто технической в административную - например, делать группу файлов уже завершённого проекта доступной только на чтение, без возможности записи; или делать архивную копию этой конкретной группы файлов после завершения этого конкретного проекта.
Подумайте в административном направлении, если не удаётся решить вашу задачу технически.
number09, ну тот же стандартный майкрософтовский VSS хранит до 512 теневых копий. Да, не совсем тем путём, что вам надо, но это разве мало? А если кто-то на каком-то этапе всё-таки испортит содержимое файла - вы будете вручную отсматривать все его 512 копий? Для предотвращения таких ситуаций обычно делается еженедельная/ежемесячная/ежегодная полная копия, и хранится N недель/месяцев/лет
Ну, начнём с того, что S/N накопителя - это одно (его вообще можно сменить без перепрошивки?), VolumeID - совсем другое, не имеющее никакого отношения к первому. Какая цель действа то?
Бред